photo credit: beccaplusmolly – cc 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?
Posted on: Wed, 09 Jul 2014 03:00:40 +0000
Trending Topics
Recently Viewed Topics
© 2015