WordPress 4.9 introduces a new experience for discovering, installing, and previewing themes in the customizer Tool built into WordPress core that hooks into most modern themes. You can use it to preview and modify many of your site’s appearance settings.. 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.
The new theme browser is designed for extensibility. Third-party theme directories are encouraged to integrate with the core Core is the set of software required to run WordPress. The Core Development Team builds WordPress. experience via plugins. Because the new browser is built on the core customize API An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways., 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 Used to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site 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 A sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme. now serves as the global index of theme sources (installed, WordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/, upload, and any additional sources added by plugins). In the customize preview area, a filter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. 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 super 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 Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. 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 The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher and wp.customize.ThemesPanel
in JS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors.. This panel is responsible for:
- The overall theme browser UI User interface 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_Section
s: 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 A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party 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:
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
You must be logged in to post a comment.