A New Way to Search, Preview, and Install Themes in the Customizer Removed From WordPress 4.7

Astute testers may have noticed a new feature in WordPress 4.7 beta 1 that enabled users to search, preview, and install themes from within the customizer. This feature was part of five feature projects related to the customizer that were approved for merge last month. Its goal is to unify the theme browsing and customizing experience.

Customizer Theme Browser Flow
Customizer Theme Browser Flow

It was removed in WordPress 4.7 beta 2. Helen Hou-Sandí, WordPress 4.7 release lead, reverted the change after collecting feedback. Some of the reasons for reverting the feature include:

  • Displaying on mobile devices is broken.
  • Inability to close the feature/filter accordion.
  • Checkmarks are overlayed on top of the search form.
  • The full-screen plus reload experience isn’t polished.

According to Hou-Sandí, there is not enough time left in the development cycle to polish the design and make it sufficient for WordPress 4.7. Nick Halsey, who helps maintain the Customizer component, expressed displeasure with the decision.

“Abruptly deciding to pull something without allowing any opportunity to improve things or even bring it up in a weekly dev chat is ridiculous,” Halsey said.

“Had I been asked to provide patches for outstanding bugs (one of which never even received a ticket), I would have gladly done so sooner – this was my highest priority for core for the past 4 months.”

Halsey goes on to say that the revert is disrespectful and insulting to him and that he is unlikely to further contribute to the project until it is back in trunk. Samuel Sidler, Apollo Team Lead at Automattic, responded to Halsey supporting Hou-Sandí’s decision.

“Making a decision to pull a highly visible feature is hard, but, as you know, it’s ultimately one that the release lead should make as it’s their release and they have the best overall view,” Sidler said.

Weston Ruter, who also helps maintain the Customizer component, asked if the revert could be reversed if patches to outstanding issues were created.

“No – if this were a matter of problems that have defined solutions already then the course of action would not have been a revert,” Hou-Sandí responded. “I know that it would feel better to have something more than ‘my gut and the guts of others say no’, but if there was more definition to the problems then we may not have been in a position where reverting from this release was the only sane thing to do.”

The feature has been punted and the milestone was changed from WordPress 4.7 to a Future Release.

A Window Into How WordPress Development Works

The quotes I published above are only part of the story. I highly encourage you to start with this post and read every response in full. It’s a great opportunity to see a WordPress release lead in action and how and why certain decisions in WordPress development are made. Those interested in the feature’s progress can follow along by monitoring this ticket.

10 Comments


  1. Thanks for highlighting this, Jeff. There has been very little visibility for this feature in general, and additional ideas for moving the project forward are valuable. The real reasons for reverting are somewhat ambiguous but tied more to the overall user experience as opposed to the four bullet points you list (which are all minor and easily fixable).

    In terms of process I think the discussion on the ticket highlights the problems with inconsistencies in the development process. When decisions are seen as sudden or authoritative, contributors have the potential to be demotivated. And that’s something we should work to avoid as a project, by being transparent when establishing processes and making decisions.

    Part of the bigger picture here is that this feature has been on the roadmap for almost two years, but no one has been able to work on it previously. I finally sat down and made a concerted effort to put together something functional, and spent two months requesting feedback, testing, and iterating. I ran, recorded, and published (on make.wordpress.org/design) eight user tests, as well as publishing a record of the mobile flow for review. Even though these are written requirements for feature projects to be merged, this was the only feature to take these steps in 4.7. In all, I volunteered hundreds of hours to this project over the past four months. I followed written processes as much as possible and the feature was approved for merge (and merged), before the recent revert. Knowing that my personal availability (particularly during traditional work hours) will be limited after 4.7, I am unlikely to be able to push this feature forward significantly in the future, so hopefully newer contributors are interested in taking the lead here moving forward.

    Report


  2. With all necessary respect for both “sides” here, in my opinion the reverting of this feature was the right decision.

    Also, stuffing the Customizer with even more features in this tiny little area is a thing that should be debated more in general.

    When the theme search isn’t working any good on WordPress.org at all, why should this even land in the Customizer. Just makes no sense.

    For years, it is not possible to search for specific Child Themes for example. If you want ALL Child Themes in the repo for, let’s say, Twenty Sixteen, you won’t find them. You only will find those, that have the term “Child Theme” somewhere in their (child) theme description field. But a lot of authors forget that or whatever.

    Please please, fix the search and filtering of themes first, and then discuss any features to bring theme search/filtering to more places into WordPress core.

    And if fixing the filter function is not possible or not wanted then please give a full text search that would be worth this name!

    Report


    1. My thoughts exactly. Searching on WordPress.org is a massive PITA and we need better filtration options. Sticking that interface into the Customizer (which in my opinion is already overloaded) isn’t a good idea.

      Report


  3. I applaud and thank anyone who contributes their hard work—whether it’s a Lead’s decision, patch or community feedback. That said, I’ve personally thought the ability to switch themes in the Customizer is a “hmm, okay” concept. An acre of real estate is being neglected in `wrap > theme-browser` via `themes.php` respectfully. There’s a convenience factor jamming mucho into El Custo, but this orphans pre-existing screens/components which could better escalate on-boarding, e.g. capturing intent (switching themes) only via themes.php first, then contextually scale upon that acquisition inside Custo’s guts. It can get a bit squishy & schizoid once you’re inside Custo, so maintaining focus on 1 theme should be the only task. Just my silly opinion :) P.S. I also applaud people who can stomach long-winded Trac tickets …my eyes go dry and brain implodes.

    Report


    1. Excellent point. I hadn’t considered that side of it but it makes so much more sense.

      Report


      1. I’m sure there’s lots of discussion on this buried in Trac/Slack, but plugin-install.php partially does this :D

        Report


  4. Frankly, I doubt many will miss this feature…

    Report


  5. There are two issues here. One is whether the feature should have been pulled. I can’t comment on that. The other is the “it’s their release” comment…. it may be the release lead’s call but that does not excuse them from communicating to the people who are primarily working on that feature about what’s going on, what decision is being made and what the next steps are. If there were deeper concerns, those should have prevented it from being in b1 too.

    Being a lead means more than being technical. Team communication is key.

    Report


    1. I completely agree with this.

      While I do agree that it’s the right decision to pull a feature that obviously hasn’t been properly tested before merge, the fact that it was included in b1 is a symptom of poor management/communication.
      This needs to be acknowledged so it can be prevented in future releases. Learning from these mistakes will only improve WordPress in the long run.

      Report


  6. IMHO Customizer is for just that – current theme customization. Theme selection needs to be better, but it needs to be somewhere else. There also needs to be a refactoring of the way themes are organized and tagged on wordpress.org, to enable whatever the next version theme selection vehicle will do.

    Report

Comments are closed.