A Response to the WordPress Customizer Expansion: Removal

With the proposal and subsequent announcement of plans to bring the menu system into the WordPress Customizer in core starting in version 4.3, the community responded swiftly and in overwhelming majority numbers against this trajectory. Between the WP Tavern article and the make.wordpress.org post, I’ve never seen such a swift response, despite the long history of WP drama when major moves have been proposed.

I don’t know if Twitter was just on point that day or what, but putting the menu in Customizer set people off.

The trend of Customizer is an answer to the user interfaces of services like Squarespace. WordPress is definitely losing some current users to Squarespace over usability for inexperienced publishers like shop owners who just want a site, so Customizer allows for previewing changes before setting anything in stone. This we don’t have any problem with because there is the way we’ve always done it and Customizer, so old school users don’t need to use Customizer, but they can if they want to.

what the plan is

The current track for the Customizer menu plugin is to merge with core in 4.3, which means it has to meet all of WordPress’s own standards for accessibility, internationalization, mobile, and a slew of other things that are now being rushed. What else is being rushed? Anything that affects businesses that offer training for WordPress or products that tap into Customizer and possibly the menu. Links to the menu in the admin toolbar will now direct to Customizer instead of the menu page, but the menu page and link under Appearance does not (yet) have a timetable to go away.

the problem we have now

The first point people made is that menus aren’t design. They are content. Look in the database, menus are found in the posts tables. As such, they aren’t subject to the same design edits as other items in Customizer, such as the background or custom header image/logo. Those items, I 100% support a Customizer or similar interface to preview changes.

I don’t personally use anything in Customizer because I develop locally and push only working items live, but 99.5% of people with sites don’t. I use the Appearance menu items directly. The only thing I’ve used Customizer for are the parallax background images in some Genesis framework themes.

the training point

Let’s think about medium to enterprise businesses for a second. Also consider businesses like WP101 who make a living off of training people to use WordPress. I used to work for a company with over 5,000 employees. More often than not, manuals were printed, as well as PDF, and if the item was important enough, each department would get 1-8 hours of training in a conference room with refreshments and some level of representation from senior management. Let’s say this company runs WordPress for all internal planning, communication (other than email), and their outward-facing public website assembly is WordPress that takes over 100 people to maintain.

Now the both the links to menus and widgets in the admin toolbar go to Customizer. If they stumbled across this because the edit widgets, they were advised by the help desk to go to the Appearance menu. Now a new set of people who create or modify content that affects menus are introduced to Customizer. Management decides to re-train everyone. How much does this cost? How many tickets to help desk did this create? Things to consider when you change entire areas of the dashboard, not just adding features people may or may not take advantage of.

the plugin point

Another point is to use a plugin to test these items until ready for mass consumption, the way we developers all loved MP6. I’m still logging into old client sites who call with recent issues who still have MP6 active. Very few developers interacting in comments even knew there was a Customizer menu plugin. Regardless of whether we feel that menus should be in Customizer, it has not reached any sort of adoption among users. It has about 3,000 downloads (though the sidebar shows 5000+ active installs, so there’s that discrepancy) and has 2 5-star reviews and 1 3-star review. Compared to the stats for MP6, it’s pretty sparse with over 141,000 downloads and 93 5-star reviews. This for a plugin that went into core in 3.8 with much applause.

Why are they not waiting for more people to test? Where is the democracy happening when core adopts items with such a small portion of the influential base even aware of it? I guarantee if this will drop in 4.3,  over 80% of end users will have no idea about it and it’s not just a cosmetic change like MP6 was. Where is the democracy when they ask the community about it and almost all of the reactions are either 100% negative based on the above principles or because it’s being rushed and they do it anyway?

taking matters into our own hands

My Twitter friend and fellow theme developer, Andy Wilkerson, was really getting into the conversation after the comments on those items linked first started forming a theme. We immediately came to the same conclusion: unhook Customizer with a plugin. I read some convoluted series of functions to use a couple of days earlier, but it was wonky, so we set out to do it efficiently.

What we came up with is Customizer Remove All Parts (WP repo — github). Simply put, it removes all traces of Customizer ever being in the admin. It’s gone from the Appearance menu, the Themes page, the admin toolbar, everywhere. Anything that was having its link hijacked to go to Customizer has had that filter removed. This is the nuclear option, as there are no settings whatsoever. Use it if you don’t want your clients or team to have any access or knowledge of Customizer.

 

We are currently in development of a fork that allows you to selectively remove everything based on user role and more detailed settings. This is how we feel Customizer should work in core. There should be some way to turn it off in the dashboard, no different than your ability to turn off the admin toolbar. Maybe this will get rolled into core in 4.5…