photo credit: shutoff
WordPress 4.3 will introduce menu management via the customizer, providing live previews on the frontend for adding, deleting, and ordering menu items. Although users still have the option to manage menus using the admin interface, developers who are not keen on the feature are searching for an easy way to disable the customizer and remove its links throughout WordPress.
In certain scenarios involving client work, the customizer can be more trouble than it’s worth and may not be a beneficial addition to a custom-tailored WordPress admin.
Gabe Shackle, an application developer and UI engineer at Risdall, created a ticket on WordPress trac last week, requesting a filter to disable the customizer. His patch offers developers an easy way to enable the ‘no-customizer-support’ class within the body tag.
By setting the filter value to false, the Customizer is essentially hidden from the admin and the links that were currently pointing at the Customizer (widgets, themes, etc…) are reverted to their previous dashboard destinations.
Currently, developers who want to disable the customizer have to employ a combination of different methods in order to effectively remove everything that the customizer introduces into the admin.
“This filter makes this process into a simple boolean filter so that developers who do not want or need the Customizer can easily remove it,” Shackle said.
WordPress lead developer Dion Hulse replied to the ticket to say that although he doesn’t use the customizer much himself, he doesn’t think that WordPress users would benefit from an easy way to turn it off.
Personally as much as I don’t use the customizer a lot of the time, I think offering a filter to disable it is probably not in the best interests of WordPress users.
The customizer, as much as some dislike it, is a major component of the future of WordPress UX – whether that is a good or bad thing remains to be seen by some – but like it or hate it, it’s here.
Hulse suggested, as an alternative, that a better way to disable it would be to remove the
customize capability from the roles.
Shackle further explained that he was attempting to follow the precedent of the admin bar, which he considers to be a similar type of UX component.
“The Admin Bar can be disabled not only by a filter but by a global variable, core function, and user profile setting,” he said. “The Customizer has none of these options.”
Nick Halsey, the developer of the Menu Customizer plugin that is being merged into 4.3, replied based on assumptions about why Shackle might request a filter to disable the feature:
I have yet to see a valid reason for something like this. In most cases, concerns about not wanting users to have access to the Customizer stem from the fact that you’re not giving them the appropriate capabilities. And the customize capability can be used to turn off the Customizer if you really must.
While you can remove the customize meta capability (or re-map it or whatever), doing so simply because you don’t want to train users or don’t want to use the Customizer is doing yourself and your users an enormous disservice. As dd32 mentioned, the Customizer will only continue to grow in importance within WordPress. Additionally, user testing has shown that the Customizer experience is generally easier for users to grasp than the admin, which largely stems from the value of having live-previewing available. We’re putting a significant amount of time into the Customizer every release to continue improving it, conducting frequent user tests along the way to optimize usability.
Halsey promptly closed the ticket following this exchange. I followed up with Shackle to find out why the proposed alternative to remove the
customize capability is inadequate for his purposes.
“Mostly I was hoping that the Customizer could be treated more like the admin bar, which has 3+ methods for disabling it,” Shackle said. “Having a clearly labeled filter is, in my opinion, more legible than modifying user capabilities. A PHP developer with virtually no WordPress knowledge could most likely understand much quicker what’s happening with a filter named ‘enable_customizer_support’ rather than ‘map_meta_cap’.”
Obviously, not all tickets and patches will be considered valid by the maintainers of WordPress core components, but Shackle was disappointed by the defensive response to the discussion.
“Honestly, had the reply simply been something along the lines of ‘You should just use the
customize capability to achieve the same effect’ I really wouldn’t have had any issue,” he said.
“Unfortunately, it seems any approach other than ‘Customizer for all things!’ means I get to be told multiple times how much of a disservice I’m doing my clients and what a lazy developer I am for not just re-training my clients how to manage their sites’ appearance.
“It feels like the Customizer team themselves have an all-or-nothing approach to the project and that anyone who questions this is wrong, regardless of their reasoning,” Shackle said.
This exchange demonstrates that since core contributors view the customizer as a major part of the future of WordPress, this is one feature where there will be little willingness to support efforts to make it more modular. Disabling support for the customizer will continue to require use of ‘map_meta_cap,’ the same method the creators of the Customizer Remove All Parts plugin have employed.