A New Themes Experience in the Customizer

WordPress 4.9 introduces a new experience for discovering, installing, and previewing themes in the customizer. Building on efforts during WordPress 4.7 development, this project prioritizes user flow, extensibility, and performance improvements.

A theme is the most fundamental aspect of customizing a site. This project seeks to unify the theme-browsing and theme-customization experiences by introducing a comprehensive theme browser and installer directly in the customizer.

The new flow seamlessly integrates theme management into the customization experience by bringing a new theme browsing framework into the customization interface along with the ability to install and live-preview a theme in a single click.

Screencast demonstrating the new themes experience in the customizer. Open the theme browser, search and browse installed and WordPress.org themes, and then install and preview in a single click.

The new theme browser is designed for extensibility. Third-party theme directories are encouraged to integrate with the core experience via plugins. Because the new browser is built on the core customize API, extending it is similar to extending any other part of the customization experience. As with every aspect of the customizer, this project approaches extensibiity modularly and in terms of both user and developer experience. The end of this post includes a technical overview of the new API.

Since WordPress 4.2, the customizer has loaded information about every installed theme every time the customizer loaded. In 4.9, theme data will only be loaded when a user visits the themes panel. The resulting performance improvement on every customizer load may be substantial on sites with a large number of installed themes, particularly on multisite networks.

For more information on the history and goals of this project, check out the original feature proposal from last year:

Feature Proposal: A New Experience for Discovering, Installing, and Previewing Themes in the Customizer

Theme Browsing Improvements

The changes since the previous merge proposal center around the experience of browsing themes. The customize sidebar now serves as the global index of theme sources (installed, WordPress.org, upload, and any additional sources added by plugins). In the customize preview area, a filter bar controls navigation within each of those sections.

Installed themes feature an instant search filter and a count of the results. WordPress.org themes also feature a search bar, in addition to the feature filter found in wp-admin and on WordPress.org. Rather than mimicking the existing WordPress.org and wp-admin theme browsers, the customizer features a simplified filter-oriented approach. The popular, favorites, and (randomized) featured sections are excluded in favor of a single, filter-driven section that defaults to showing the latest themes.

Over time, the customization team hopes to work with the theme review and meta teams to broadly evaluate the process of finding a theme. This future project will be driven by research into other product discovery experiences, as well as the experiences that third-party plugins build within the customizer for browsing themes from other sources. Ultimately, the goal is to bring an improved and unified theme browsing experience to WordPress.org, wp-admin, and the customizer, complete with new tags and other taxonomies. For now, the WordPress.org theme browser within the customizer is a starting point for a user-driven theme discovery experience.

Customize Themes API

The remainder of this post is dedicated to the technical implementation of the new themes experience, with three objectives: providing an example implementation of the customize API, documenting the feature to assist in future iterations, and introducing the API for extending the experience.

Customize Object Structure

The context for the themes experience is contained with a custom customize panel object, WP_Customize_Themes_Panel in PHP and wp.customize.ThemesPanel in JS. This panel is responsible for:

  • The overall theme browser UI layout
  • Installing themes (via wp.updates)
  • Loading theme previews
  • Updating installed themes from WordPress.org (via wp.updates)
  • Deleting installed themes (via wp.updates)

The custom themes panel object joins WP_Customize_Widgets_Panel and WP_Customize_Menus_Panel as core examples of the intended use for panels – as contexts for distinct features, rather than as generic containers for sections. It should generally not be necessary to modify the core panel object when extending the themes experience.

Theme browsing is done within custom customize section objects, which are instances of WP_Customize_Themes_Section in PHP and wp.customize.ThemesSection in JS. In 4.9, core provides two sections for browsing themes: Installed Themes and WordPress.org Themes. An additional section to Upload Themes will be added in a future release. Themes Sections handle the following:

  • Searching and filtering
  • Loading themes (from wp_prepare_themes_for_js() and WordPress.org), as theme control objects
  • Rendering screenshots for theme controls as they become visible (rather than loading all screenshots as soon as the theme data is loaded, for improved performance)
  • Opening and navigating the theme details modal

The themes section was initially introduced in WordPress 4.2. In 4.9, it has been completely reworked, most notably with the addition of built-in support for loading theme data from WordPress.org.

Each theme within the browser is represented with a customize control object, instances of WP_Customize_Theme_Control in PHP and wp.customize.ThemeControl in JS. Theme controls:

  • Display information about a single theme
  • Provide contextual buttons to install, preview, or install and preview themes depending on whether the theme is already installed
  • Contain an internal filter (and sorting) method in JS, which can be used for searching and filtering all theme controls within a section

While the theme control object was also initially introduced in WordPress 4.2, its 4.9 update completely refactors the control to use JS templates for rendering. This facilitates the updated themes section’s ability to quickly load data for large numbers of themes within a fully JS-driven experience. Hundreds of individual theme controls are dynamically created and deleted as users navigate the theme browsing interface, leveraging the customize API’s ability to scale by building on functionality initially introduced in WordPress 4.3 for the menus interface.

Extending the Core Experience

The modular structure of the customize API allows any aspect of the new themes experience to be modified or extended. In most cases, extensions will modify the themes section object, or create custom themes section instances or subclasses.

There are two types of WP_Customize_Themes_Sections: those that load all themes at once and search/filter theme locally (like the core installed section), and those that search and filter themes remotely, replacing every theme control object each time a search or filter changes. This distinction is managed with the filter_type parameter. When this set to local, all themes are assumed to be loaded from Ajax when the section is first loaded, and subsequent searching/filtering is applied to the loaded collection of themes within the section. This is how the core “Installed” section behaves – third-party sources with limited numbers of themes may consider leveraging this implementation. When filter_type is set to remote, searching and filtering always triggers a new remote query via Ajax. The core “WordPress.org” section uses this approach, as it has over 5000 themes to search.

With this parameter, it is theoretically possible to create a plugin that adds an instance of WP_Customize_Themes_Section that browses themes from a third-party source (using a custom action parameter). The customize_load_themes filter facilitates loading themes from third-party sources (or modifying the results of the core sections) within an Ajax call triggered by a themes section. In practice, it may be desirable to create a custom themes section object (subclassing WP_Customize_Themes_Section) to further customize the experience of browsing third-party themes within the customizer.

Additional Information & Next Steps

Most of the work for 4.9 was completed in #37661, with several follow up tickets to polish the feature. In addition to iterating on the WordPress.org theme browsing experience, there are a few improvements that are already planned for future releases:

  • #40278 – Introduce theme uploading in the customizer
  • #42046 – Clarify active and previewed themes
  • #42140 – Improve plurality of the themes count string

Here is the complete design flow for the new theme browser within the customizer, courtesy of @folletto:

Mockups of the user flow through the customize themes experience in 4.9, with additional elements for future releases

Please test the new themes experience in the 4.9 betas and share any feedback or bugs that you find on trac and in the comments.

#4-9, #customize, #dev-notes, #themes