We have two separate needs and experiences for the WordPress back-end. Site owners and users need a different suite of tools and interfaces from what we developers/implementers need. Let’s talk about splitting the back-end interfaces to serve both needs.
Imagine for a moment, you log into the WordPress back-end and all of these tools are available to you as the developer. Tools like setup, configuration, database monitoring, performance, database cleanups, and more. Everything you need to setup and tune a WordPress website is at your fingertips. Imagine the power of having all the tools you need in a developer-centric environment.
In my past article, Developers, We’ve Made the WordPress Back-end Complex and Disconnected, you and I discussed the back-end experience of the site owner. Site owners need a simple, branded means to manage their content. They want to add, edit, and delete content. They aren’t interested in adjusting their site’s setup, as that’s what they paid you to do. Right?
Okay, how do we split the back-end interface to serve both needs?
Introducing Developer Mode
For this developer-centric suite of tools, we need a new mode. Let’s call it “Developer Mode.” When the website is in this mode, the back-end has a different interface. This interface provides everything we need.
Settings and options pages are setup tools. Right? Think about it. You configure a website for your client using the built-in and plugin/theme pages. If you need a custom post type or a series of custom fields, you can code these yourself or install a plugin that provides an interface for you to configure those features. Right? Many of the themes and plugins you use are packaged with setup interfaces. Genesis, ACF, security, user roles, and even WordPress out-of-the-box have these pages. These make it convenient for you and I to do our work for our clients.
Okay, then let’s move those pages to our new Developer Mode.
Picture this in your mind. You turn on this new mode through say the wp-config.php file. When you do, all of these settings and options pages are loaded for you. But when you are not in this mode, these pages are not loaded.
What are the Benefits?
Well I’m glad you asked me that question. Let’s talk about a few benefits off the top of my head.
Benefit: Back-end Loads Faster
For the site owner, the back-end will now load faster as there are less files to be loaded. That will make your client very happy.
Benefit: Less Complexity for Clients
Your clients don’t need all these tools. It’s confusing and too complex. We are giving them the means to break their site. All your client needs is to manage his/her content. They want to see it as it will appear on the front-end. They don’t care about all of the setup and configuration tools that we needed to setup the site.
With this new mode though, all of the things we need are disabled and not even loaded. The entire back-end can be re-imagined to improve their experience, driving it for ease-of-use and a branded interface for a true WYSIWYG environment (more on this idea in a later article).
Your client will love you for this benefit.
Benefit: Drive Suite of Developer Tools
By separating the back-end into site owner/user/client and developer interfaces, innovative product developers will be empowered to create a new suite of tools for us. Oh, just imagine being able to easily setup, configure, monitor, tune, and test each website. Did you get goosebumps? I did.
We have our own space with all the stuff we need to do our jobs. Then when you ship it, turn it off.
Benefit: Competitive Advantage
All of the benefits above will generate a competitive advantage for those who deliver such an experience. Clients will be happier. You get more tools to make that website perfect for your client. Okay, that just made them even happier. They get a better experience which is designed just for them. It’s a win win for everyone.
What Does It Take to Implement a Developer Mode?
You will be so surprised at how easy the solution is. We add a new constant into the wp-config.php file, e.g.
define( 'DEVELOPER_MODE', false );
Plugin, theme, and custom site builders use this new constant to turn on and off any features which are developer/implementer-centric. These features include settings page, setup meta boxes, and developer-centric tools. WordPress core could also roll this into the codebase and disable features when this constant is off (although that’s a longer term solution due to new feature adoption).
That’s it. Simple.
You could do this right now, yourself, in your projects without any plugin or theme authors having to change their products. You just unregister the feature’s callbacks when this mode is disabled.
Then in time all products and core can integrate this mode into their codebase. It’s a simple solution that packs a lot of benefits for all involved.
Wrap it Up
What do you think? Do you see the benefits for your clients and you? Imagine not having to explain to them what these settings pages are. Or even better, imagine not having to go back in and fix when they break their site. Ah, I like that idea.
Let’s implement a Developer Mode.
