After reading Justin Tadlock’s post (on WPTavern) on some of the work the WordPress.org Theme Review Team is doing on curbing obtrusive user notices, got me to thinking that I definitely have opinions on these and some other related aspects of the WordPress Admin (settings, etc.).  Thought it would be worth of some commentary. Recently, I’ve been getting more involved in the WordPress.org Teams and I feel a lot more comfortable than in the past that there are actually well intentioned people that have interests in finding solutions for common issues that have arisen just through the course of usership of the software we all know and (most) love.

As part of the WordPress Theme Review Team’s plan to curb obtrusive admin notices, the team pushed version 1.0 of its Admin Notices package to the public. The new package provides a standard API for theme authors to display admin notices.

Long story short, the packages have API support that makes maintaining these messages in a more uniform fashion adoptable.  The article has much more detailed information on this particular endeavor and is definitely worth the read.

Notices and Settings Everywhere:  I’m a huge proponent of WordPress (obviously).  You just can’t find web software where having so much flexibility to solve very particular issues ends up in the hands of Users and Developers in a manner that they can actually administrate solving issues within their reach.  If I’ve ever had one issue, it’s that for a User (and even for a Developer), you end up with notifications…and settings everywhere. Very happy to see this getting some focus on Notifications.

On to Settings:  This is the area I think becomes confusing from a User perspective.  As Developers, we generally know that there can (and are) multiple settings panels in different locations, but sometimes, it seems like you end up searching for some dark corner where there are settings related to whatever feature you’re either working on troubleshooting or developing for.

A great example of this is with themes.  You might have some of the Theme Options in the Customizer, there may be other settings in a dedicated Theme Options Panel.

Then there’s CSS.  There are many, many places custom css can be integrated.  There may be a box in the Customizer, there may be something in Theme Options or there may be something by way of a plugin that provides to manage and maintain custom css.  Then there’s the flat stylesheets. That’s a lot of places you can conceivably have the same thing…a lot of dark corners. This now extends to functions, filters and snippets as well as there are similar panels for easier management and plugins to support this.

Now, most Developers have their own way of integrating things like custom css, functions and filters and keep the same structure, so that’s a good thing.  It’s easier to decipher and there are definitely some protocols to follow (some better than others), but if a single protocol is followed, this becomes much easier.

It becomes difficult as a Designer or Developer when you’re inheriting a site that’s already been worked on by either the User or another Developer, even if you’re just building a module.  All of the sudden, you’re following your protocol on top of whatever is already there. There’s often not time on the project for proper equalization. Sometimes you’re caught in the middle on custom component development as there may be one of these blocks in some dark corner causing conflicts, so you either find it or weave around it.

The settings are just all over the place in most cases, theme settings here, plugin settings there on one of many custom panels, often settings in plugins (multiple) or themes addressing control of the same exact things.  There’s a lot of room for overlap.

The Challenge:  So the challenge is that obviously WordPress is Open Source Software.  It’s a blank canvas for development. Not totally blank as there are some controls as to the plugins that go into the WordPress Plugin Repo, but you can’t really tell someone on their own (purely Premium or Individual outside of WordPress.org assets) that they can’t do a certain thing and although there are sort of accepted “ways” of doing things, it becomes obvious that some Developers roll out control panels and settings where they know how to do it from past experience.

It’d be really great to have an outline that’s much more specific of the appropriate places for certain types of controls and code.  I do know the WordPress.org Teams work very hard at issues like this, so it’s very likely somewhere that this has been discussed and may even be attended to.  It’s a challenge to keep track of all Team’s progress, so lately, have had focus on the Docs Team as I’m a participant there, but this is definitely on my list of things to bring up and potentially find if there is already a movement.