How to Split WordPress Back-end for Owners/Users and Developers

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.

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.