When widgets were added to the customizer in 3.9, WordPress users were generally surprised and delighted. Live previews are so beneficial to the editing experience that contributors are starting to pursue an expansion of the role of the customizer into all aspects of WordPress.
Nick Halsey has been working extensively with the customizer as part of his Google Summer of Code project and recently published an update detailing the planned improvements for the upcoming 4.0 release. The Appearance trac component has now been renamed to Customize. Halsey’s clarifications of the terminology reveal where the project is heading in terms of prioritizing the customizer:
We’re shifting toward using ‘Customizer’ rather than ‘Theme Customizer’, as it isn’t necessarily theme-specific (though most of its uses currently are)…’Customize’ could refer to anything. That’s the point; it could be used to customize any part of a site. The Customizer can be used for anything, and we’d like to encourage more experimentation with different uses of the Customizer.
WordPress 4.0 will include a number of UI changes to the customizer along with a new Panels API that enables developers to group controls into sections.
The proposed customizer changes for 4.0 provide support for a wider array of controls and parameters to help developers extend it for more varied uses beyond themes. Contextual controls are also on the list of proposed changes, which allow the controls to be visible or hidden based on the page the user is viewing.
Is WordPress putting all its eggs in one basket with the customizer?
Improvements to the customizer are expanding on all fronts. WordPress developers will soon be able to use it in many more ways after this iteration is complete. But are we putting a lot of effort into rapidly expanding a feature that may not be able to evolve as the web changes?
Matt Wiebe, design Engineer at Automattic, recently wrote a piece, enumerating some of the most critical issues in evolving the customizer as it currently stands. His article highlights the difficulty of using the customizer on mobile devices, performance issues, a confusing UI and the fundamental limitations of its architecture:
It’s also a JS-driven app wrapped around a PHP-only public API, which is I guess about what you’d expect from an early WP foray into something JS-driven. But this fundamental PHP dependency makes it basically impossible to account for a seamless switching of state while changing a previewed theme: a full page reload has to happen.
Wiebe believes that some of the smaller issues he outlined can be addressed with core changes, but the underlying architectural issues may be impossible to address in a backwards-compatible manner. He is hopeful that eventually the customizer could make use of the upcoming WP API, though that would require a massive overhaul:
Also, looking forward, the Customizer itself should be a client app of WP-API. Everything related to site appearance should be an API call away, rather than the tightly coupled thing that is the Customizer. This will open the door for, say, a native Customizer on Android or iOS or some other platform that doesn’t exist yet but will be important.
The WP API is slated for inclusion in WordPress 4.1 which should arrive later this year. Meanwhile, development with the current customizer architecture charges forward.
Halsey briefly mentions a few of these issues in the conclusion of his proposal under the “future work” section. He cites tickets that recognize the customizer is not intuitive on mobile and needs some help in terms of performance. Customizer-related tickets tagged for a future release address a few of the issues that can be improved with core changes.
It’s easy to nitpick problems with a relatively new feature in WordPress that hasn’t had time to develop. Many contributors have put a great deal of hard work into all of the upcoming improvements to the customizer. But the question here is whether or not this feature, with its current architecture, is a dead end until it is completely refactored to be able to provide users on all devices a better and more seamless editing experience. Are we sweeping too many concerns under the rug for future work? Or will the customizer be able to evolve and find a path forward through the roadblocks?
My main concern in regards to WordPress architecture is the little amount of attention paid to backward compatibility. Yes there are great strides being made in the evolution of WordPress. But I have witnessed so many plugins fall into disuse because of compatibility issues. With every new version that rewrites core files, the dependability of WordPress suffers in the eyes of developers. If you are not a fortune 500 company with 6 figure programmers at your beck and call, you had better not depend on WordPress beyond it’s basic shell, no matter what your vision for your WordPress site. Add-on capabilities are transient at best.
I am reminded of the IBM PC in it’s heyday. As long as they maintained a bus architecture that supported third party participation and development, it remained at the top of the market. But when they went to a proprietary architecture, they fell into disuse. Not saying that WordPress isn’t king. But the next thing that comes along that will adhere to a dependable (or at least predictable) standard and at least pays lip-service to backward compatibility for their plugin developers; that will be the day that WordPress will be displaced as the forerunner in this arena.
There have been many upgrades as of late. But the trend has been towards lateral moves that supports WordPress.com as the next great cash cow; not forward moves that establish WordPress as the current and future king of content management interfaces. There will always be the next great thing. How the current or the next remains in that position is entirely dependent on its’ third-party developers. Lately, it has been very discouraging to be counted in that number.