The Customizer in WordPress has gotten quite a lot of critique lately mostly concerning a misunderstanding about the proposed removal of the current Menu interface under Appearance in favor of just having Menu management in the Customizer interface. This proposal was rejected by the WordPress Core team which made many of us very pleased. The new Menu interface is still going into WordPress in a very fast track manner. Almost as the massive negative feedback has given them more energy to push it through. We will see if it actually gets into 4.3 or not my bet is on yes. In this post I have tried to find out everything I can about the origins of the Customizer.
The new Menu management is developed as a plugins first approach which was introduced back in mid 2013. This new way of adding features to WordPress Core is really good and I was pleased that the WordPress Core team went with that development procedure. Ryan McCue (@rmcure) and the WP-API project he initiated and have spearheaded despite not being part of core is an excellent demonstration of how Core should always be developed for any major changes. My cynical side would have thought that REST API support in WordPress Core would have come from a conversion of the current XML-RPC implementation. Ryan should be praised for not taking that approach and for taking the matter as seriously as he has and his ability to get Core leadership on board and the rest of the team (Rachel Baker, Joe Hoyle, Daniel Bachhuber).
My approach regarding these posts concerning the Customizer is to first try to figure out and explain where it all stems from, why this approach was bad and how it has impacted and will continue to impact the development of WordPress as a project. I will also try to show the detrimental adhoc nature of WordPress Core development.
Customizer – The origin story
The Gandalf incarnation
So what does the Customizer really have to do with my appraisal of Ryans et als work with the WP-API? Well the Customizer is from my perspective the exact opposite of how one would go about handling such big pervasive changes. There was a plugin approach used for the Customizer development, one could find it under the trac ticket #19910, it remained a plugin for 25 days. More on that later. I cannot find any public discussions on design or approaches on how to best implement a standardized interface for theme manipulation and related settings. There are mentions of themes and customizing in an old post from a in person Core Meetup back in late 2012. Other concrete stuff is scope discussions for 3.4
High-level, the features would likely include: a theme-setup wizard that would incorporate an option for configuring all the appearance-related stuff before activating a new theme (speaking of, Twenty Twelve is targeted for 3.4), and then specific improvements around menus, widgets, backgrounds, headers, easier static front page process, multisite appearance management, etc.
Tracing forward we have the “This Is Not a Feature List” post on January 11, 2012 where we find the following list:
Framework for configure and activate (theme + associated custom header, background, menus, widgets) – Koop, Ocean
- live preview of theme changes
- activate without configure
- drag and drop sidebars/widget areas from old theme to new theme
- configure a new theme, with preview, and then push that theme live
- easier static front page process
Next update regarding this whole ordeal comes on February 3, 2012 with Team Gandalf Update. No updates at all between the first mention on January 11th and this update, even though the post claims they are halfway through their first iteration. There was no post to mark the start of it in the first place except the “This is not a feature list” post. This is the origin of the whole Customizer feature. No screenshots, no updates, no various design suggestions, no public debate regarding anything except for some code implementation issues on the trac tickets. And it was all developed under the very explanatory name of “Team Gandalf”. Why they didnt name themselves The Theme Editor Editors or something fun but explanatory we can only guess (or ask them but I’ve got much more to write about).
First iteration ended on February 10, still no elaboration on the design choices. The trac tickets is still lack luster without any screenshots or design ideas. There are discussions on code implementation. In 15 days the Customizer plugin gets merged into core with the message “Introduce new theme customizer to replace theme preview. Rough first pass.”. A whooping 25 days from first introduction of the plugin and the ideas getting merged into core.
Yesterday marked the halfway point of our second cycle. We’re moving along at a steady clip. The main goal for the coming week is to tie up any loose ends and begin integrating the plugin into core. Until then, follow our progress at #19910 and in the plugin repo.
In the original ticket Appearance Improvements: An Overview #19909 we can find a pretty lofty goal.
The main target for the 3.4 appearance improvements will create a UI that allows users to simultaneously customize and preview their theme. Our initial target will be the theme switching process (in an a la carte fashion), which will then hopefully expand to more uses in the WordPress admin.
So essentially the whole Customizer interface stems from an idea of listing themes and choosing one to preview even though the original goals were much greater. Theme selection using the Customizer works very good for the most part.
The earliest display of what the Customizer will look like that I can find is a tweet by Mark Williams. Next up is a “How to leverage the Theme Customizer in your own themes” post by Otto on May 3, 2012. I cannot find a single screenshot on the make blog or in the trac tickets. If they exist I would gladly add them to the post.
The last few weeks we have had lots of discussions in the community about changes to the Theme repository with the requirement of using the theme customizer. If you check the comments on the various posts regarding the Customizer in the past on what was wpdevel.wordpress.com you clearly see that people either didn’t know about it or didn’t cared enough to comment. I think just adding a mockup, like the one I made in like 5 minutes, would have helped greatly in getting people on board the Customizer train. Just such a simple thing would have increased the feedback greatly I think. And adding some mockups for how it would be used for modifying theme design etc would most likely have resulting in a “NO” response from the parts of the community that have any understanding of front end editing such as all the Drag and drop theme developers and users.
The lack of community feedback during the development of the Theme Previewer is most likely the main culprit for why the Customizer was rarely used by themes in the past and also why some are reluctant to use it now. People are coming aboard the train but very few actually seem to glad to be on the train. I’ll be covering various themes, plugins that make use of the Customizer and comparing them to other competing services.
It is 3 years since the Customizer made it into core without community feedback, I cannot help but wonder if they had taken a more integrated and open approach similar to how Ryan et al has done and continues to do with the WP API we might have had a totally different experience.
The good thing about the latest developments of the Customizer and other parts of the core development is that its starting to get more public. The posts relating changes to Core has improved in quality and also most things relating to anything visual actually contains screenshots or GIF animations of how things will look and work. Personally I would really like to see more posts about the steps leading up to the visual implementation of features not just the end result or what you might call the Release Candidate. The bart of all is that the Core ignored the vocal opposition, failed to address major questions that came to light given these changes. The WordPress Core team have not seen such a backlash since the introduction of the infamous capital_P_dangit() function back in 2010. Justin Tadlock wrote the following regarding that change:
Listen to your community
I’ve only seen a handful of people that agree this function should be in WordPress. It has been met with harsh opposition. The people arguing to remove this function are people we need in the community. They’re plugin developers, theme developers, contributors to core code, and evangelists for the WordPress platform. These are the people that continue making WordPress better.
Don’t alienate them.
Are these people only a vocal minority of WordPress users? Certainly. However, these people speak for a larger amount of users. For users without the knowledge of mailing lists. For users without the understanding of how Trac works. They are the people that interact with the majority every day. They are the voice of the majority.
Don’t let their voices go unheard.
We can now deduce that the Customizer looks the way it does because it all started with the single feature of previewing and selecting a theme. The constraints regarding that single feature is what have led us to a Customizer that looks like the current one. Why the feature of selecting a theme should dictate how the Customizer looks and behaves for all other theme and design related controls and behaviors is something that has not been properly argued by the Core team. There is not a single mockup and so forth showing that this is the best way going forward. They wanted something and added it, with a total disregard for the future or the endusers and completly ignoring the community backlash.