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

Customizer Improvements in 4.7

WordPress 4.7 has been the most active release on record for the customize component, with four major feature projects merging and shipping with 4.7 and over 90 tickets closed as fixed. This post summarizes the highlights of the user and developer-facing changes.

4.7 Customizer Feature Projects

Create pages within live preview during site setup

Add new pages while building menus and setting a static front page; outline your site directly in the customizer.

This project began with the ability to create posts and pages direction from the available menu items panel in the customizer, as originally proposed near the end of the 4.6 cycle:

https://make.wordpress.org/core/2016/06/16/feature-proposal-content-authorship-in-menus-with-live-preview/

Subsequent changes also added the ability to create new pages when assigning the front page and posts page in the Static Front Page section. Because this is now built into the core dropdown-pages customizer control, themes and plugins can also allow users to create new pages for their options instead of relying on existing content. The homepage sections in Twenty Seventeen include this new allow_addition parameter. Here’s how to register a dropdown-pages control supporting new pages:

$wp_customize->add_control( 'featured_page', array(
	'label'          => __( 'Featured Page', 'mytextdomain' ),
	'section'        => 'theme_options',
	'type'           => 'dropdown-pages',
	'allow_addition' => true, // This allows users to add new pages from this dropdown-pages control.
) );

Additionally, a proposal for term statuses was developed as a first step toward expanding the menus functionality to work for creating and previewing taxonomy terms in a future release (see #37915).

Improvements to the Sliding Panels UI

Customizer navigation is now faster, smoother, and more accessible.

This project tackled a series of tickets focused on improving the usability of the “sliding panels” UI in the customizer controls pane. The first step was to refactor the section and panel markup so that sections and panels are not logically nested. This is the biggest internal change to the UI and has a dedicated post going into the details:

https://make.wordpress.org/core/2016/09/28/changes-to-customizer-sliding-panelssections-in-wordpress-4-7/

This primary change resolved numerous problems with sections and panels not opening and closing properly, and eliminated situations where navigation to leave a section could become hidden. The next step was making section and panel headers “sticky” so that navigation is easier to access within long sections (such as for a menu); see #34343.

Finally, hover and focus styling for navigation in the customizer has been updated to use the blue-border approach found elsewhere in core, including for the device-preview buttons in the customizer, in #29158. This completes a refresh of the customizer controls pane’s UI design that began in WordPress 4.3 with #31336. The core UI now uses the following consistent UI patterns in the customizer:

  • White background colors are used only to indicate navigation and actionable items (such as inputs)
  • The general #eee background color provides visual contrast against the white elements
  • 1px #ddd borders separate navigational elements from background margins and from each other
  • 15px of spacing is provided between elements where visual separation is desired
  • 4px borders are used on one side of a navigation element to show hover or focus, with a color of #0073aa
  • Customizer text uses color: #555d66, with #0073aa for hover and focus states on navigation elements

Plugins and themes should follow these conventions in any custom customizer UI that they introduce, and inherit core styles wherever possible.

Any custom sections and panels, as well as customizations to the core objects in plugins and themes, should be tested extensively to ensure that they continue functioning as intended with all of these changes in 4.7. It’s particularly important to ensure that things like the use of color match the core conventions so that the user experience is seamless between functionality added by plugins and core.

Customize Changesets (formerly Transactions)

Browse your site and switch themes more seamlessly within the customizer, as your changes automatically persist in the background.

This project rewrote the internals of the customizer preview mechanism to make changes persistent. Each change made to a setting in the customizer is saved to a changeset (a new customize_changeset post type), facilitating future features such as scheduled changes, revisions, or saving and sharing drafted changes. Changesets also open the door to using the customizer to preview Ajax requests, headless sites, and REST API calls for mobile apps. In 4.7, changesets enable switching themes in the customizer without needing to decide between publishing or losing your customizations, as they’re automatically persisted in the background.

For more details on changesets, check out the two dedicated posts:

https://make.wordpress.org/core/2016/10/12/customize-changesets-formerly-transactions-merge-proposal/

https://make.wordpress.org/core/2016/10/12/customize-changesets-technical-design-decisions/

Custom CSS

Fine-tune your site and take your theme customizations to the next level with custom css in the customizer.

#35395 introduced a user-oriented custom CSS option in the customizer. Now that the base functionality is in place, it will be further enhanced in #38707 in future releases. Read the feature proposal for details on the implementation and why it’s important for core:

https://make.wordpress.org/core/2016/10/11/feature-proposal-better-theme-customizations-via-custom-css-with-live-previews/

There’s also a dedicated post that walks through the process of migrating existing custom CSS options in themes and plugins to the core functionality – be sure to follow those steps if your plugin or theme does custom CSS:

https://make.wordpress.org/core/2016/11/26/extending-the-custom-css-editor/

Other Changes with Dedicated Posts

4.7 features several other features deserving special attention. Read the posts for visible edit shortcuts (which expand the functionality of customizer partials), video headers (which extend the custom header feature), and starter content for more information:

https://make.wordpress.org/core/2016/11/10/visible-edit-shortcuts-in-the-customizer-preview/

https://make.wordpress.org/core/2016/11/26/video-headers-in-4-7/

https://make.wordpress.org/core/2016/11/30/starter-content-for-themes-in-4-7/

Additional User-facing Changes

With over 90 tickets fixed in the customize component in 4.7, we can’t cover everything here. But, here are a few more highlights:

Improved Custom Background Properties UI

#22058 introduces a more comprehensive and more usable custom background properties UI when a custom background is set up. There are now presets to control all of the detailed options at once, and the individual options are presented in a more visual way. Background size and vertical position are also now available as standalone options when using a custom preset.

Theme developers should update their add_theme_support() calls for custom-background to specify the default size, vertical position, and preset to reflect their default background image CSS. Perhaps the most significant improvement here is the ability for users to easily set up fixed full-screen backgrounds – and the ability for themes to make that behavior default if desired.

And even more…

4.7 also:

  • Loads the frontend preview iframe more naturally, eliminating a lot of weirdness with JS running in an unexpected location and ensuring that JS-based routing will work (#30028)
  • Allows the search results page to be previewed, and any forms that use the GET method in general can now be submitted whereas previously they would do nothing when submitted (#20714)
  • Hides edit post links in the customizer by default. Plugins, such as Customize Posts, can restore the links if they make post editing available in the customizer (#38648), although the visible edit shortcuts should generally be used instead.
  • Shows a cursor: not-allowed for mouse users when hovering over external links in the preview, as these can’t be previewed
  • Officially removes support for the customizer in Internet Explorer 8, preventing users of this outdated browser from accessing the customizer at all (#38021)

Additional Developer-oriented Changes

Hue-only Color Picker

#38263 adds a hue-only mode to the Iris color picker, wpColorPicker, and WP_Customize_Color_Control. Built for Twenty Seventeen’s custom colors functionality, the hue-only mode allows users to select a hue and saves the hue degree as a number between 0 and 359. To add a hue-color control:

$wp_customize->add_control( new WP_Customize_Color_Control( $wp_customize, 'colorscheme_hue', array(
	'mode' => 'hue',
	'section' => 'colors',
) ) );

As demonstrated in Twenty Seventeen’s custom colors strategy, the hue-selection strategy opens up a whole new world of possibilities for custom color options in themes. Rather than introducing numerous text and background color options and requiring users to adjust them to ensure that adequate color contrast is provided, themes can consolidate their color options into one or more hue pickers. Then, the corresponding use of hsl colors in CSS allows themes to define color patterns where users customize color hues without impacting the lightness of a color option, thereby preserving the designer’s use of proper contrast between text and background colors, and any use of color lightness for visual hierarchy. Check out the implementation in Twenty Seventeen for inspiration (including instant live preview).

Fix Sections that .cannot-expand

When creating custom customizer sections that, for example, display an external link but don’t actually expand to show section contents, the cannot-expand class can be added to the section title container to prevent JS events and CSS hover/focus styles from being applied. Be sure to also remove the tabindex="0" from the container if you copy the core code since your custom section shouldn’t be focusable if it can’t expand (and any contained links or buttons would be keyboard-focusable automatically). See #37980 for details.

Allow Plugins to do Comprehensive Late Validation of Settings

To account for custom subclasses of WP_Customize_Setting that don’t apply the customize_validate_{{$setting_id}} filter, this filter now will be applied when WP_Customize_Manager::validate_setting_values() is called. This ensures that plugins can add custom validation for every setting. For more, see #37638.

Credits

Huge thanks to the 61 people (and counting) receiving props for the 120+ customize component commits in 4.7 (as of RC2): @westonruter, @celloexpressions, @afercia, @sirbrillig, @ryankienstra, @helen, @ocean90, @melchoyce, @bradyvercher, @folletto, @johnbillion, @delawski, @karmatosed, @georgestephanis, @dlh, @curdin, @valendesigns, @mattwiebe, @michaelarestad, @joemcgill, @sstoqnov, @lgedeon, @mihai2u, @coreymcollins, @stubgo, @utkarshpatel, @desrosj, @odysseygate, @johnregan3, @aaroncampbell, @mapk, @iseulde, @mrahmadawais, @vishalkakadiya, @sayedwp, @hugobaeta, @jonathanbardo, @jorbin, @tristangemus, @deltafactory, @kkoppenhaver, @seancjones, @Presskopp, @Mista-Flo, @nikeo, @adamsilverstein, @lukecavanagh, @coffee2code, @peterwilsoncc, @presskopp, @pento, @Kelderic, @sebastian.pisula, @mckernanin, @FolioVision, @MikeHansenMe, @welcher, @cdog, @grapplerulrich, @iamfriendly, @flixos90.

 

#4-7, #customize, #dev-notes

Visible Edit Shortcuts in the Customizer Preview

#27403 added visible edit shortcuts to the customizer preview, making it easier to see which elements of your site are editable in the customizer and how to edit them. Here’s a demo with Twenty Fifteen (note that the ability to toggle icons off has since been removed):

Implementation: Selective Refresh Partials

Visible edit shortcuts are an extension of the existing “shift-click-to-edit” functionality built into customizer partials. Partials are sections of the front end of the site, in the customizer preview, that are associated with customizer settings. When settings change, their associated partials are selectively refreshed via an Ajax call without reloading the entire preview. Partials are to the customizer preview what controls are to the customizer editing pane: a visual representation of a setting.

Buttons are now injected into partials within the preview to expose this relationship visually and to users of all input modes. However, the role of the customizer preview is to provide an accurate representation of the frontend of the site as it’ll appear once changes are published. Accordingly, visible edit shortcuts pose a challenge as they have the potential to significantly hamper the preview-ability of the preview.

To balance between discoverability and providing an accurate preview, the initial core iteration showed a flash of the buttons when the preview first loads, then hid them. To show the shortcuts, or to toggle them on and off, you could click/tap anywhere in the preview (except on a link or button). Keyboard users had a screen-reader-text button (visible on focus) to toggle the shortcuts on and off. This functionality was removed in [39131] and icons are currently persistently visible when customizing but hidden when the controls are collapsed, and supplemental usability testing validated this decision.

Background & Prior Implementations

Shift-click to edit an element in the customizer preview was first implemented with the widget customizer project in WordPress 3.9. Visual approaches to exposing this functionality were explored, but left for a future release. Selective refresh was also first proposed, and put on hold pending development of the concept.

The first core implementation of selective refresh came with menu management in the customizer in WordPress 4.3. Menus include shift-click-to-edit on a per-menu-item bases, further demonstrating the powerful potential of associating portions of the customizer preview with their associated settings and controls.

WordPress.com currently supports a similar feature with visible edit icons in the customizer. This approach serves as the inspiration for the final UI being introduced in core, with additional UX adjustments and a complete rewrite of the implementation to make it compatible with as many themes as possible.

Adding Theme Support

Theme support for this feature is all about supporting selective refresh, which was added in WordPress 4.5. In some cases, a small amount of additional CSS will be required to ensure that the shortcuts are positioned properly. Edit shortcuts will be enabled by default for all themes, but are contingent on themes supporting selective refresh.

Selective Refresh for Widgets

See the post from WordPress 4.5 for adding support for selective refresh for widgets. In most cases, add_theme_support( 'customize-selective-refresh-widgets' ) is the only requirement:

https://make.wordpress.org/core/2016/03/22/implementing-selective-refresh-support-for-widgets/

Selective Refresh for Menus

Menus support selective refresh out of the box unless: a custom nav menu walker is used, the echo argument is false, or wp_nav_menu isn’t used. In those cases, you’ll need to add support directly. Some themes may still be missing full support for selective refresh of menus, which has been enabled by default since WordPress 4.3.  Reference the post for details, but note that it predates the core implementation of an API for selective refresh:

https://make.wordpress.org/core/2015/07/29/fast-previewing-changes-to-menus-in-the-customizer/

Selective Refresh for Custom Options

Custom logo (since 4.5) and header video (since 4.7) support selective refresh automatically if you use the core features via add_theme_support. Other core options such as the site title and tagline or header images can support selective refresh if you register partials for them and set their settings’ transport argument to postMessage. Here’s an example from Twenty Fifteen:

$wp_customize->get_setting( 'blogname' )->transport        = 'postMessage';
$wp_customize->get_setting( 'blogdescription' )->transport = 'postMessage';

$wp_customize->selective_refresh->add_partial( 'blogname', array(
	'selector' => '.site-title a',
	'render_callback' => 'twentyfifteen_customize_partial_blogname',
) );
$wp_customize->selective_refresh->add_partial( 'blogdescription', array(
	'selector' => '.site-description',
	'render_callback' => 'twentyfifteen_customize_partial_blogdescription',
) );

Where the render callbacks call bloginfo( 'name' ); and bloginfo( 'description' ); For more details on adding support for selective refresh for custom theme options, reference the official customizer documentation.

Support in Default Themes

Twenty Eleven through Sixteen support selective refresh as of WordPress 4.5, and also support edit icons for most of their features as a result. Twenty Fourteen and Sixteen require a few very minor positioning tweaks to ensure that all of the icons are visible. This is typical of what most themes could expect needing to add.

Twenty Seventeen will be a great showcase for this new functionality, as the first theme to ship natively with selective refresh support and with visible edit shortcuts. A few additional adjustments in this new theme will ensure that every option can be previewed with selective refresh and provides visible edit shortcuts where appropriate.

Limitations & Future Iterations

The biggest limitation of the current approach is that implementation is entirely dependent on themes supporting it. However, unlike with many other theme-supported features, there is no add_theme_support for visible edit shortcuts. Where themes are already using selective refresh, shortcuts will be available out of the box in WordPress 4.7. To add theme support for edit shortcuts, themes need to add theme support for selective refresh, another newer customizer feature that allows the customizer preview to update granularly. Selective refresh provides superior user experience to the default refresh behavior because the preview context is not lost when changes are made.

Edit shortcuts currently rely on the presence of selective refresh partials for every setting that needs an icon. Some settings may be previewed exclusively with JavaScript via postMessage. Icons also aren’t needed for every option; for example, layout or color options are broader than a specific area of the site, so they aren’t associated with a particular edit icon in the preview. In the future, a structured JavaScript API for partials in the customizer preview could facilitate adding icons to JS-previewed settings that don’t use selective refresh.

Visible edit shortcuts are also the first step toward exploring the potential to edit elements of a site directly within the customizer preview. For this to be fully investigated, it’s imperative that a majority of themes and customizer option support selective refresh so that areas of the preview are associated with the appropriate customizer settings and so that context-disrupting full page reloads can be minimized.

Contributors & Call for Help

@sirbrillig led development of the feature for core based on the equivalent feature on WordPress.com. Core props went to @sirbrillig, @mattwiebe, @celloexpressions, @melchoyce, @westonruter, and @afercia. Thanks to everyone who has contributed so far!

Now, your help is needed! Here’s what you can do to make this feature shine in WordPress 4.7:

  • Theme authors: add support for selective refresh to your themes. Start with widgets and make sure it’s working for menus, then make sure you’re using the core custom logo feature. Then, add selective refresh to the site title and tagline, header images, and any custom options with associated regions on the frontend.
  • Theme authors: adjust icon positioning in your theme’s CSS. You can add styles to.customize-partial-icon button to adjust all icons, and scope that to a specific container or even .customize-partial-icon-setting_id to adjust a particular edit icon. Note: these were updated with [39136].
  • Everyone: test edit shortcuts with your current theme with WordPress 4.7 Beta 1 (or newer). Most themes should be able to support them on widgets, menus, and logos with minimal effort. Contact your theme’s developer with any bugs or missing edit icon support, refer them to this post, and ask them to add support for visible edit shortcuts.
  • Everyone: test as many themes as possible and look for anywhere the shortcuts don’t display as expected, or at all. Contact the theme author with your findings, refer them to this post, and ask them to improve support for visible edit shortcuts in their themes.

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

Customize Update 2016-10-23

This is the weekly update post for the customize component. It includes a summary of this week’s meeting, recent commits, and next week’s meeting agenda.

4.7 Feature Proposals & Merges

Three proposal posts have been published and approved since our last update:

https://make.wordpress.org/core/2016/10/12/customize-changesets-formerly-transactions-merge-proposal/

https://make.wordpress.org/core/2016/10/12/customize-changesets-technical-design-decisions/

https://make.wordpress.org/core/2016/10/11/feature-proposal-better-theme-customizations-via-custom-css-with-live-previews/

All five of the major customize feature projects proposed for WordPress 4.7 have been successfully merged (in order):

Work continues on follow up tickets for many of these projects. Please test everything in the customizer and report any bugs to trac. We still have a few pending enhancements that need to be completed by this Wednesday, 10/26, 4.7 beta 1, sorted by priority:

  1. #27403 Improve UI for linking areas of Customizer preview to corresponding controls (desktop and mobile) – has-patch, needs testing and adjustments
  2. #38263 Color picker: add a hue-only mode – has-patch, needed for Twenty Seventeen
  3. #28536 Add browser history and deep linking for navigation in Customizer preview – needs-patch punted
  4. #38164 Customize: assign static front page and posts page to new pages – has-patch
  5. #37964 Allow customizer controls to be encapsulated by accepting pre-instantiated settings – has-patch, needs adjustments
  6. #22058 Improve custom background properties UI – has-patch
  7. #29158 Customizer UI Design lacks contrast for visual hierarchy and does not match wp-admin – has-commit, has-patch for revisions

Weekly Customize Meetings

Our past two weekly meetings have focused on preparing our projects for commit. We’ll continue our weekly 4.7 meetings into beta and RC pending the volume of customize tickets remaining in the milestone. For this week’s meeting, our priority will be ensuring that the 7 remaining customize enhancements for 4.7, listed above, are committed before beta 1.

Our weekly update posts will continue on a reduced schedule now that the bulk of 4.7 development is complete, and we’ll also continue posting dev notes for changes in 4.7.

Recent Customize Commits

Here are the customize-related commits for the past two weeks:

  • [38765]: Customize: Ensure `customize_validate_{$setting->id}` filters apply on input post_values for WP_Customize_Setting subclasses that neglect to apply the filter themselves.
  • [38766]: Customize: Improve message displayed in widgets panel when there are no widget areas currently displayed in the preview.
  • [38767]: Customize: Show Pages section first and pre-expanded in list of available menu items.
  • [38794]: Customize: Move Pages below Custom Links in available nav menu items panel.
  • [38807]: Customize: Skip triggering initial click on pages section for available nav menu items if already open.
  • [38810]: Customize: Implement customized state persistence with changesets. 
  • [38811]: Customize: Split out link `click.preview` and form `submit.preview` event handlers…
  • [38813]: Customize: Introduce a new experience for discovering, installing, and previewing themes in the customizer.
  • [38829]: Customize: Introduce custom CSS for extending theme styles.
  • [38830]: Customize: Fix unit tests when `twentyfifteeen` is `WP_DEFAULT_THEME` instead of twentyfifteen.
  • [38831]: Customize: Improve the labeling of background and header images in the list mode of the media library.
  • [38837]: Twenty Seventeen: Fix a PHP warning on fresh installs.
  • [38850]: Tests: Prevent Twenty Seventeen from interfering with Customizer tests.
  • [38851]: Tests: Prevent Twenty Seventeen from interfering with Customizer ajax tests.
  • [38853]: Customize: Add sticky headers for panels and sections.
  • [38862]: Customize: Revert part of [38859] which caused sections to get deactivated in the customizer.
  • [38867]: Twenty Seventeen: Add theme support for customize selective refresh.
  • [38881]: Customize: Keep previously uploaded header images in place.

Big thanks to those who contributed to patches committed this week: @johnregan3, @celloexpressions, @folletto, @westonruter, @deltafactory, @coreymcollins, @desrosj, @pento, @delawski, @davidakennedy, @afercia, @karmatosed, @ryankienstra, @valendesigns, @utkarshpatel, @stubgo, @lgedeon, @ocean90, @mihai2u, @dlh, @aaroncampbell, @jonathanbardo, @jorbin.

We’re always looking for more contributors; check out the open customize tickets and swing by #core-customize in Slack to get involved. Tickets in the Future Release milestone will be considered first for 4.8 if they have a patch.

#4-7, #customize

Feature Proposal: Better theme customizations via custom CSS with live previews

When people ask “why WordPress?”, some of the most common answers center around flexibility for users of all kinds, whether they’re building their sites primarily through code or UI. Let’s take the story of a user who does a little of both – we’ll call her Becky.

Becky is a pretty savvy user. She knows that you’re supposed to make child themes instead of hacking on a theme directly, because updates can wipe out your changes. She found that out the hard way when she first started using WordPress – she hardly knew what CSS or PHP were, but she knew there was a theme editor in the admin and that she could make tweaks to colors or remove the author byline pretty easily without having to figure out this FTP stuff. Later on, most colors could be changed with the customizer so having a child theme just to remove an author byline seemed like overkill, but it was certainly better than having it reappear every time her site updated, especially with auto updates turned on.

After a couple years with the same theme on her personal site, Becky felt it was time to change things up. She was pleasantly surprised to find some new features that made getting a theme set up a lot easier, especially when live previewing them. Still, though, that pesky author byline remained, and since her last child theme copied a template to get rid of the byline, she would have to set up a whole new one to do it again. Then Becky found an “Edit CSS” option and realized she could hide things using CSS without having to go through the entire child theme process. Now, it turns out that those CSS tweaks didn’t come with live previewing, and that functionality was provided by a certain plugin, but Becky got what she needed to get done a lot faster than she would have otherwise, and ended up with the site she wanted.

This isn’t one specific story, but it is a combination of user stories many have heard, witnessed, or even personally experienced. You could replace Becky with @helen and it would be 100% accurate. The theme editor is a dangerous but useful entry point to more deeply customizing your site – rather than outright removing it and cutting off that introduction not just to WordPress code but to the concept of web development at large, why not provide a far safer and more user-friendly alternative? This post will explain why custom CSS with live previewing is valuable for WordPress and propose an implementation for inclusion in 4.7.

Proposed solution: Custom CSS with live preview

When bridging the gap between advanced user and beginning developer, desired changes are typically visual tweaks, such as changing a font size or hiding something, that are theme-specific. These sorts of changes should not require that users take risks editing live files that might white screen their sites or jump immediately into developer-facing tasks such as using FTP. Therefore, the scope of this feature has been defined as a custom CSS editor that leverages the customizer for a user-friendly live preview experience. This live preview allows for users to try various tweaks to a theme before saving and setting their changes live.

There are hundreds of thousands (if not millions) of users making use of custom CSS plugins or other themes/plugins that have custom CSS capabilities, and the frequent suggestion of CSS fixes in support forums justify a core need for this functionality. When plugins and themes interact in unexpected ways, CSS snippets are often an efficient solution to fixing the particular problem on particular sites.

The CSS editor takes inspiration from the many plugins offering similar solutions, but with an updated approach that offers instant live previewing in the customizer. The proposal for 4.7 looks like this:

custom-css-proposal-demo

Notably, previewing CSS in the customizer allows the site to be navigated and previewed on different sized devices by leveraging existing core features, allowing users to visualize the impact of their changes across their site. Error messages are shown for common syntax mistakes to help users ensure that their CSS is formatted properly before saving.

In future releases, the interface can be iterated on to further improve usability. The long-term design vision provides functionality such as revisions, syntax highlighting, and in-preview selector helpers, and can be implemented iteratively over time (click through for the full version):

customizer-css-i2

CSS would be stored in a custom post type (without admin UI), with a post stored for each theme. The editor would be used to supplement and override theme styles rather than editing them directly, as users have long been advised that directly editing files may lead to lost changes during updates. Instead, custom CSS safely stays available through updating and switching themes, starting fresh for each new theme. Projects such as customize changesets (#30937) and revisions for customizer settings (#31089) would bring future enhancements to this feature and further leverage the opportunities that come with storing the data in post objects.

This is proposed as core functionality rather than remaining as plugin territory because it is designed as the first step toward a next generation of the existing theme editor in core, with a more refined feature set and safer, more user-oriented focus. The theme editor is not proposed to be removed at this time, though with the introduction of this feature it likely makes sense to introduce more friction before accessing the editor (#31779).

Documentation

To improve the user experience further, it is critical that a link to documentation and resources for learning CSS be included with useful help text. This could initially be the “CSS” codex page but would ideally live on a user or developer handbook of some sort eventually (perhaps the theme developer handbook?). This help text must be much more succinct than the help tab on the existing theme editor, conveying what CSS is, where to learn about specific rules, and explaining that it’s specific to each theme in only a few lines.

Help is needed to create a resource for using custom CSS in WordPress, and locate it on WordPress.org. There are some related resources on make/training and WordPress.com has a good introductory page that they may be willing to contribute. Translated versions will eventually be needed as well. If anyone is interested in improving this aspect of the feature, which will presumably live on WordPress.org, please comment on this post.

Security, Capabilities, and Multisite

While the proposal includes basic validation, it is not possible to fully sanitize CSS. For this reason, a new meta capability will be introduced for managing css, unfiltered_css. By default, this is mapped to the unfiltered_html capability.

Site administrators on multisite networks do not have the unfiltered_html capability by default. A plugin that remaps unfiltered_css to a different capability can be created to provide this access on multisite, where custom CSS is especially useful given the need to restrict the number of themes and child themes in the network. This is an area of potential evolution over time.

Related Customize API Improvements

There are a couple of customizer API improvements introduced as part of the implementation of custom CSS in the customizer. A new “Code Editor” customizer control (WP_Customize_Code_Editor_Control) is used for the CSS editor and can also be utilized in plugins and elsewhere in the future. It currently handles line numbers and basic code styling, and will eventually add enhancements such as syntax highlighting.

Additionally, the WP_Customize_Section class has a new “description_hidden” parameter, which locates the section description in the section header behind the help icon toggle (“?”), functioning in the same manner as the customizer panel descriptions.

Contributors

@johnregan3 is leading development of this project, based on initial work by myself (@celloexpressions). @folletto is leading design efforts, with a focus on the long-term growth of the feature for maximum usability.

The implementation takes inspiration from many of the numerous plugins and services that implement custom CSS, specifically including:

  • Simple Custom CSS (@johnregan3)
  • Modular Custom CSS (@celloexpressions)
  • WordPress.com Custom CSS in the design upgrade (Automattic)
  • Jetpack (Automattic)

Testing, Feedback, and Next Steps

Your help is needed in giving feedback on this proposal and testing the feature! To test, please apply the patch either via Trac or the PR (helpful reminder: grunt patch handles both) and try some custom CSS in the customizer using various themes.

Pending approval of this proposal, the next steps will be to finalize and commit the patch on #35395. Code review is ongoing in the GitHub PR linked on the ticket. Feedback on the feature in general and the specific implementation is encouraged via the comments on this post, with any more technical implementation discussion happening on the Trac ticket or GitHub PR.

#4-7, #css, #customize, #proposal, #themes

Customize Update 2016-10-09

This is the weekly update post for the customize component. It includes a summary of this week’s meeting, recent commits, and next week’s meeting agenda.

4.7 Feature Proposals

The feature proposal for themes was published last week; the deadline for feedback/review is this Wednesday, October 12th:

https://make.wordpress.org/core/2016/10/03/feature-proposal-a-new-experience-for-discovering-installing-and-previewing-themes-in-the-customizer/

Look for feature proposals for custom CSS and customize changesets (formerly “transactions”) this week.

Weekly Customize Meeting Summary

On Monday we held our weekly 4.7 customize component meeting in #core-customize on Slack [logs]. Participants: @celloexpressions, @braad, @aaroncampbell, @abdulwahab, @westonruter, @karmatosed, @folletto. This summary also contains a few notes on action since the meeting.

4.7 Projects

  • Customize changesets (transactions) – #30937 – @westonruter
  • Create pages within live preview during site setup – #37914#37915, #38002#38164 – @celloexpressions
    • @boonebgorges published a proposal for term statuses; however, this will likely happen in a future release, along with #37914 and #37915 (pending a final punt decision from Boone).
    • The design team decided to punt providing a path to edit newly-created pages, #38002.
    • The remaining item for 4.7 is #38164 – extending this functionality to creating new pages for static front pages. A design approach was agreed upon in the design chat, and the code can be lifted from the Customize Posts plugin to build this out.
  • A new experience for themes in the customizer – #37661 –@celloexpressions
    • The feature proposal was published, and there are currently no comments. See also the make/flow post and make/design post, which have some feedback.
    • Additional design issues and usability adjustments have been completed and frozen pending a couple of minor tweaks and major bugs.
    • The deadline for feedback from other teams is October 12th, leaving a week for final code review and commit. We’re awaiting feedback from security, docs, polyglots, flow (if any beyond what was provided on the post), and most notably accessibility with the latest patch.
  • Code-editing gateways, via CSS – #35395 – @johnregan3
    • @johnregan3 has prepared a new patch to incorporate the design by @folletto as well as the dev-feedback from last week’s chat. A few minor adjustments are needed, then this will be ready for final review and commit.
    • The feature proposal post is in review and should be published within the next day or two.
  • Customizer browser history#28536 – @westonruter
    • Parts of this are blocked by changesets, which is higher priority for now. Changesets also offer improvements here natively.
    • If it’s okay with @helen, we’s like to pursue this in the week before beta, after the major feature deadline, since it’s a smaller feature.
  • Improving sliding panels UI – #34391, #34343, #29158 – @delawski
    • An initial commit is in trunk, dev note published, and only a few minor bugs have come up so far.
    • @delawski shared a patch for #34343 that needs testing. We discussed pursuing #35186 as an alternative in the future, but that it would cause compatibility issues since the default section markup would (probably) change.
    • @folletto propsed a design for the remaining elements of #29158, which @celloexpressions will create a new patch for next week.
  • Twenty Seventeen – a few related projects are targeting 4.7 with significant customize changes
    • #27403: Improve UI for linking areas of Customizer preview to corresponding controls (desktop and mobile)
    • #37974: Add multi-panel feature to pages through add_theme_support
    • #38172: Enable Video Headers in Custom Headers

Additional Tickets Needing Attention

  • Customizer notifications – #35210 – needs UX feedback and a patch
    • @delawski will try to work on this in time for 4.7.
    • This ticket is holding up some of the other tickets on the 4.7 milestone, such as #22037 and #29932, as well as aspects of changesets (transactions).

Ticket Scrub

We ensured that all 4.7 customize non-bugs have owners or were punted. See these remaining open tickets by owner here.

Recent Customize Commits

Here are the customize-related commits for the past week:

  • [38709] Customize: Improve the widgets and menu items search
  • [38742] Customize: Add workaround for Safari bug causing preview frame to be unscrollable via mousewheel after a refresh.

Big thanks to those who contributed to patches committed this week: @ryankienstra, @melchoyce, @afercia, @westonruter, @tristangemus.

We’re always looking for more contributors; check out the open customize tickets and swing by #core-customize in Slack to get involved. Fun fact: we’re 5 commits away from the 1000th commit that references customize.

Agenda for 2016-10-10 Meeting

Our next regularly-scheduled meeting is Monday, October 10, 2016, 17:00 UTC. Agenda:

4.7 Projects

Additional Tickets Needing Attention

  • #37335: Standardized API for themes to add info/links to the customizer
    • If the theme review team wants this solution in core for 4.7, we need a decision on their end in the next week. Otherwise, the ticket can be closed as maybelater. Their current recommendation is to use a custom section (that cannot expand). cc @greenshady

Ticket Scrub

We’ll see you next week!

#4-7, #customize

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

This is the feature merge proposal for the new themes experience in the customizer introduced with #37661. Here’s an overview of the current proposed UI:

Customizer themes design and user flow mockup

Customizer themes design and user flow mockup by @folletto.

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.

Walkthrough of the latest patch on #37661.

Walkthrough of the latest patch on #37661.

Background & History

The customizer originated as a tool for previewing and customizing themes and as such, was closely integrated into the theme browsing experience in wp-admin when it was introduced in WordPress 3.4. The theme browser and installer were rewritten in WordPress 3.8 and 3.9, respectively, offering a fast JavaScript-based way to explore, install, and switch themes.

Eventually, as the customizer’s role grew to that of a framework for live-previewing any change to a site, it became apparent that it would benefit from a more direct way to switch themes, without entering the wp-admin context. The Customizer Theme Switcher plugin was created, and after some refinement, merged into WordPress 4.2. However, while it initially included external links to install themes in the admin, these were eventually removed due to the jarring experience of unexpectedly leaving the customizer.

Currently, there is no indication that additional themes can be installed when viewing available themes in the customizer. For new users, it may take quite a bit of time to discover the ability to install themes, via wp-admin, or they may give up on WordPress before making this discovery. This is a usability dead-end where a user’s flow is disrupted in the process of discovering, installing, previewing, and activating themes, both on initial site setup and when considering a redesign.

When the theme switcher plugin was developed, the team made preliminary plans for a theme installation interface as a second phase of the project. Specifically, it would leave the “preview” context of the customizer but retain the same identity in the user experience. @folletto helped develop this initial concept in early 2015.

Technical Constraints & Requirements

There have been several technical limitations preventing theme installation in the customizer from being addressed previously. Most notably, such an interface requires “shiny” ajax-based theme installation, updates, and deletion, so that the user flow can persistently stay in the customizer themes interface rather than jumping to separate “installing” views. This is now possible with phase 2 of “Shiny Updates” in WordPress 4.6. Additionally, expansions of the customizer JavaScript and JS-templated controls APIs to better support dynamically-registered controls were needed to support theme installation within the customizer framework, and these were fully fleshed out for the customizer menus interface introduced in WordPress 4.3. With these technical constraints eliminated, theme installation in the customizer is now possible without additional significant improvements to the underlying themes or customizer APIs.

The customizer must currently be completely reloaded from PHP to preview a different theme. To perform a theme switch without a reload, theme-defined settings, sections, and controls would need to be updated dynamically with JavaScript. While the customizer internals have been working toward making this possible for some time, significant work remains to make inline theme switches possible. Therefore, changes to this part of the theme-switching workflow are out of scope for the current project, which focuses on the user-facing flow.

The biggest usability block that this limitation causes is that unsaved changes are lost when the theme is switched. Unsaved changes are currently handled by prompting users with an are-you-sure notice in the browser before making the switch. Unfortunately, limitations in JavaScript require the loading indicator to be hidden after the user decides to stay on the page or to continue to the new theme, causing confusion. In the new interface, this is further mitigated by displaying a warning that there are unsaved changes, with an inline button to save and publish them, at the top of the interface. With customize changesets (transactions) (#)30937, a “save draft” option could also become possible in the future, allowing changes to be saved (potentially automatically) without being published between theme previews.

Previewing Themes

One of the biggest challenges with theme installation in wp-admin, and opportunities in the customizer, is previewing themes. Currently, a customizer-like frame displays a preview hosted on WordPress.org, with limited content. Rather than opening this potentially-disorienting similar but different interface, the proposed flow de-emphasizes the distinction between installed and available themes. The primary action for available themes is now “Install & Preview”, which installs the theme and live previews it in one step.

Users can now see any theme on their site with their content and play with its options in the customizer in one click. If they decide it’s the wrong theme for their site, the themes panel can be quickly reopened and another theme selected and previewed with no harm done. A secondary action allows themes to be installed without instantly previewing, so that the installed themes tab can become a personal theme library of sorts, where users can save themes that they might want to try on their site. Installed themes being a filter along with the available theme headings unifies the previously-disorienting separation of themes and add-new themes on separate screens, with confusingly-separate search and header (add new/upload theme) functionality.

Proposed Themes Interface

Due to the tight integration with the existing system, with the existing theme control and section as well as internal elements in the customizer manager and theme details template requiring moderate modifications, this project was implemented as a patch and cannot be reasonably converted into a plugin and back. The patch has been available on trac for six+ weeks, with iterations continuing to improve and polish the new experience.

The technical implementation continues adapting the concepts present in the backbone.js-based themes experience in wp-admin to leverage the customizer API. With the themes experience natively built on the customizer framework, it should be much easier for developers to improve and maintain the core experience in the future as well as extending the core experience in a structured way.

A few highlights of the proposed details:

  • Installed themes are no longer loaded every time the customizer is opened, resulting in potentially significant performance improvements by only calling wp_prepare_themes_for_js() when needed. This also allows themes in the customizer to be fully disabled with remove_panel( 'themes' ).
  • The themes experience is unchanged on the top level of the customizer, but selecting the change theme button now opens a panel that fills the entire screen, as the preview is not relevant when considering a theme change.
  • The UI diverges somewhat from what is found in the theme installer in wp-admin (which will remain), particularly around the filters.
  • The theme details view is unified between installed and available themes; clicking on a screenshot opens the details view to match the admin UI.
  • Primary buttons are used where clicking them takes you away from the current page (ie, for previews); secondary buttons are used elsewhere.
  • The loading strategy attempts to balance performance with wait time by loading theme data from Ajax in large batches (100 themes) and following up by rendering screenshots as they become visible (as the existing interface does).

Usability Testing

Four usability tests have been conducted so far. The full test screencasts are available on Make/Design, alongside key takeaways. These tests expose a lot of largely-known issues with themes and the customizer in general, but did not reveal any significant issues with the proposed new theme browser. Because the tests were conducted in-person with a limited set of volunteers, additional testing with a broader user base would be ideal.

There has been design feedback since the user testing was conducted, resulting in some significant changes. @karmatosed has volunteered to coordinate additional testing in the next week to verify that the changes haven’t introduced usability regressions, and to test with a broader audience. Check out the call for user testing on make/design to help out here.

A visual record on a phone of the revised design has been posted on make/flow.

Extensibility

Because the new interface is built entirely on the customizer API, third-party plugins should now be able to integrate much more easily. This means that other theme marketplaces (including commercial themes) could realistically be browsed (and maybe even installed) from within WordPress, while leveraging the core UI exactly.

The presentational flexibility is available via the customizer API (with custom theme sections for other theme sources, and theme controls for individual themes), but there are likely some gaps in the ability to do this seamlessly in the internals. If anyone is interested in building this sort of functionality, please evaluate whether any additional hooks are needed so that they can launch alongside the new feature.

Review and Approval

In addition to a general core approval of this proposal, the following sign-offs are required before the feature could be approved for merge, based on the applicable elements of this list:

  • Flow (and mobile) review (see also an initial post)
  • Docs review
  • Security audit
  • Polyglots/i18n review
  • Design/UX review – tentative approval has been provided from @karmatosed and @folletto (with additional input from others in last week’s design meeting) with an expectation that minor adjustments will continue to be required. General design feedback is still welcome, but major changes are unlikely to be feasible at this point.
  • Accessibility review – @afercia completed an initial review, with the issues fixed in a subsequent patch. A comprehensive final review would be a good idea as well, since there have been significant design changes.
  • Code review – to be handled by @westonruter once the patch is otherwise deemed “ready” based on review from other teams.

To test, update to latest trunk and apply the latest patch on #37661. On your test site, open the customizer and “change” the theme. Try out the various filters, browse themes, and install and preview them. Also test the inline update and deletion functionality.

To meet the feature merge deadline for 4.7 (10/19), reviews from various teams and any corresponding iterations need to be completed by October 12th, leaving a week for final code review and commit. General feedback and specific reviews and action items should be provided as comments on this post.


Update: this feature was merged in 4.9.

#4-7, #4-9, #customize, #proposal, #shiny-updates, #theme-switcher, #themes

Customize Update 2016-10-02

This is the weekly update post for the customize component. It includes a summary of this week’s meeting, recent commits, and next week’s meeting agenda.

Weekly Customize Meeting Summary

On Monday we held our weekly 4.7 customize component meeting in #core-customize on Slack [logs]. Participants: @celloexpressions, @voldemortensen, @westonruter, @karmatosed, @folletto, @aaroncampbell. This summary also contains a few notes on action since the meeting.

4.7 Projects

  • Customize changesets (transactions) – #30937 – @westonruter
    • @westonruter has completed an initial patch, merging previous work with major updates
    • Transactions are now known as “changesets”, with a customize_changeset post type and customize_changeset_uuid query param.
    • @aaroncampbell is interested in helping here.
    • Please apply the patch from the GitHub pull request and test for any regressions and that it fixes the myriad of issues that it is supposed to fix: grunt patch:https://github.com/xwp/wordpress-develop/pull/161
    • Latest patch improves theme preview experience so that pending changes made during a theme preview aren’t lost when switching to another theme (see #36485).
  • Create pages within live preview during site setup – #37914#37915, #37916, #38002, #38013, #38164 – @celloexpressions
    • #38164 has been created for creating pages from the static front page section. This functionality can be extracted from the customize posts plugin, but we need design ideas here.
    • We still need UX feedback on providing a path to edit newly-created pages, #38002.
    • @westonruter punted #37916 to a future release.
  • A new experience for themes in the customizer – #37661 –@celloexpressions
    • There was a special meeting to iterate on the design approach, and @folletto and @karmatosed agreed on a new design that was implemented in a revised patch at the end of the week.
    • A feature proposal is ready to be published on make/core pending final review.
    • The revised mobile flow was posted in a visual record on make/flow.
    • The deadline for feedback from other teams is October 12th, leaving a week for final code review and commit.
  • Code-editing gateways, via CSS – #35395 – @johnregan3
    • This was discussed at length during the core dev chat. The consensus was that the feature is appropriate for core as proposed (pending approval of the formal proposal).
    • For security, because there is limited-to-no ability to actually sanitize CSS, a new meta capability, unfiltered_css, will be introduced. By default, this will map to unfiltered_html, but plugins can change this as needed, for example on multisite, where site admins don’t have unfiltered_html and custom CSS is particularly useful.
    • Neither CSSTidy nor CodeMirror will be used for now, as CSSTidy doesn’t actually provide CSS sanitization, and CodeMirror is a nice-to-have for syntax highlighting. There will be some primitive validation that provides user feedback for common syntax errors.
    • @folletto has volunteered to assist with the design/UX aspects here, taking inspiration from the similar feature on WordPress.com.
    • We’re schedule to post a feature proposal next week, and need to complete an updated patch soon to make 4.7.
  • Customizer browser history#28536 – @westonruter
    • Parts of this might be blocked by changesets (transactions), which is higher priority for now.
    • If it’s okay with @helen, we may want to pursue this in the week before beta, after the major feature deadline, since it’s a smaller feature.
    • During customizer themes user testing, this came up as expected behavior.
  • Improving sliding panels UI – #34391, #34343, #29158 – @delawski
    • An initial commit is in trunk, dev note published, and only a few minor bugs have come up so far.
    • #34343 is now in progress. @folletto pointed out that we might want to do #35186 instead, or in addition at some point.
    • #29158 needs design ideas for the back arrows and close button focus styles, with the possibility of eliminating the autofocusing of (pending accessibility feedback).
  • Twenty Seventeen
    • Tracking a couple of possible customizer-heavy features.

Additional Tickets Needing Attention

  • Customizer notifications – #35210 – needs UX feedback and a patch
    • @westonruter will work on this after changesets (transactions) unless anyone else is willing to work on turning the latest proposal into a patch.
    • This ticket is holding up some of the other tickets on the 4.7 milestone, such as #22037 and #29932, as well as aspects of changesets (transactions).

Ticket Scrub

  • #21627: Filter for custom-background CSS selector
    • Needs unit tests, looks like @peterwilsoncc is the best person to own this.
  • #30738: JS content templates for base WP_Customize_Control
    • Not critical for 4.7, but there is code in customize posts that could be adapted for this.
  • #33085: Customizer: controls description inside labels are not real labels nor descriptions
    • This is fixed with the code for #30738.
  • #37269: Introduce removed event for wp.customize.Values collection
    • Punted pending a (good-first) patch.
  • #36582: Export main query from Customizer preview
    • Punted, as it can be implemented in plugins such as customize posts for now.
  • #22857: ‘Header Image’ state isn’t removed from images previously used as header image
    • This may be more appropriate under the media component based on the direction it’s taking.
  • #38080: Focusing a customizer control from the preview should show the controls on mobile
    • Patch should be too difficults, this is a follow up to another change in 4.7, although there is no UI exposed for this functionality on mobile currently.

Recent Customize Commits

Here are the customize-related commits for the past week:

  • [38648]: Customize: Re-architect and harden panel/section UI logic.
  • [38649]: Customize: Opt to disable IE8 support via conditional comments instead of unreliable feature detection.
  • [38668]: Customize: Fix focusing on controls for widgets and nav menu items after [38648].

Big thanks to those who contributed to patches committed this week: @westonruter, @delawski, @celloexpressions, @ryankienstra.

We’re always looking for more contributors; check out the open customize tickets and swing by #core-customize in Slack to get involved. Fun fact: we’re 7 commits away from the 1000th commit that references customize.

Agenda for 2016-10-03 Meeting

Our next regularly-scheduled meeting is Monday, October 3rd, 17:00 UTC. Agenda:

4.7 Projects

Additional Tickets Needing Attention

  • Customizer notifications – #35210 – needs UX feedback and a patch
  • Customizer UI Contrast/Focus Styles – #29158 – needs UI ideas for focus styles on back buttons

Ticket Scrub

  • 4.7 Customize non-bugs without owners. We’ll assign these all to an owner or punt to a future release. Beta 1 is three weeks away.
  • We’ll pick a different query to triage each week. For example, bugs awaiting review (need verification).

We’ll see you next week!

#4-7, #customize

Customize Update 2016-09-22

This is the weekly update post for the customize component. It includes a summary of this week’s meeting, recent commits, and next week’s meeting agenda.

Weekly Customize Meeting Summary

On Monday we held our weekly 4.7 customize component meeting in #core-customize on Slack [logs]. Participants: @celloexpressions, @ataylorme, @westonruter, @johnregan3. This summary also contains a few notes on action since the meeting.

4.7 Projects

  • Create pages within live preview during site setup – #37914#37915, #37916, #38002, #38013 – @celloexpressions
    • @boone shared a proposal later in the week for term status; a make/core proposal is likely the next step
    • @westonruter committed adding new pages to the static front page options, and making them contextual in #38013.
    • We need a new ticket following up on #38013 for enabling pages to be created within the static front page UI. @westonrtuer has initial code for this in the Customize Posts plugin.
    • We still need UX feedback on providing a path to edit newly-created pages, #38002.
  • A new experience for themes in the customizer – #37661 –@celloexpressions
    • We’re primarily pending feedback at this point. Could use some assistance from the shiny updates team to add shiny theme uploads as well.
    • There is another updated patch as of today with some minor bug fixes, based on testing from @rabmalin.
    • Usability testing started today; see the results on Make/Design.
    • A feature proposal post will be published next week.
  • Code-editing gateways, via CSS – #35395 – @johnregan3
    • We still need information from anyone familiar with the CSSTidy library. It seems that the version included in Jetpack is an up-to-date fork, as the original project was last updated in 2007. If anyone from Automattic can provide input here that would be appreciated.
    • We also need to ensure that the license, GPL 2.1 or later is compatible with core.
    • The CodeMirror library is also proposed to be bundled with core for this project; we would like core committer/lead developer approval for bundling both of these soon so that we can proceed. CSSTidy is a requirement, CodeMirror is a usability enhancement (syntax highlighting).
    • We’re planning to post the feature proposal the week after next.
  • Customizer browser history#28536 – @westonruter
    • Feature proposal post will be published in three weeks, as this shouldn’t need signficant work to polish up.
  • Customize transactions#30937 – @westonruter
    • @westonruter is working to sit down and focus on this this week, and will evaluate whether it’s still feasible for 4.7.
  • Improving sliding panels UI – #34391, #34343, #29158 – @delawski
    • @westonruter is planning to commit #34391 on Friday, after a final review from @celloexpressions. (#37661 will need a refresh, to be handled tomorrow night).
    • @delawski is also preparing a make/core post to be published in the next few days.
    • #34343 is pending #34391.
    • #29158 needs design ideas for the back arrows and close button focus styles, ticket updated accordingly.
  • Twenty Seventeen
    • @davidakennedry shared a mockup for video headers in #core-themes. This would require someone digging deep into #36581 and #32861 before work can begin on adding support for videos, and insert from URL may not be feasible.

Additional Tickets Needing Attention

  • Customizer notifications – #35210 – needs UX feedback and a patch
    • @westonruter will work on this after transactions unless anyone else is willing to work on turning the latest proposal into a patch.
    • This ticket is holding up some of the other tickets on the 4.7 milestone, such as #22037 and #29932, as well as aspects of transactions.
  • Remove customizer support for IE8 – #38021

Ticket Scrub

We reviewed tickets with no replies. Many were authored by component maintainers, and as such required only a +1 on the ticket.

  • #36581: Customizer Header Image Control should extend the cropped image control
    • Pending someone volunteering to work on this.
  • #36589: Don’t use localhost in Tests_Image_Header tests
  • #36688: Exit button in customiser only lower third active
    • Not reproducible, needs reporter feedback.
  • #36733: Use a custom customizer section for add-widgets and add-menu-items panels, making this UI pattern reusable in plugins
    • Could use more discussion, but it would be nice to make this code accessible to plugins.
  • #37275: Facilitate creating controls that manipulate settings with object values
    • Low priority, commented accordingly.
  • #37281: Allow non-error notifications to be set for Customizer settings from PHP
    • This might be useful for Twenty Seventeen, depending on the custom color strategy.
  • #37727: Allow for customize control notifications to have extensible templates
  • #37964: Allow customizer controls to be encapsulated by accepting pre-instantiated settings
    • The patch needs to be reviewed.
  • #38077: Facilitating embedding customizer controls outside of sections
    • This will be more useful long-term, but isn’t a priority for 4.7.
  • #38091: Shortcut to collapse current control/section/panel is triggered when it shouldn’t be
    • Could use more opinions on whether this should be in 4.6.2.
  • #38093: WP_Customize_Color_Control – there is no option for transparent color
    • Commented but couldn’t find a duplicate ticket as mentioned in the meeting, does anyone else recall this issue?

Recent Customize Commits

Here are the customize-related commits for the past week:

  • [38618]: Customize: Ensure nav menu items lacking a label use the title from the original object.
  • [38624]: Customize: Let static_front_page section be contextually active based on whether there are any pages (including pages added in menus).
  • [38627]: Customize: Remove IE8 access to customizer to discontinue support.
  • [38628]: Customize: Add wp-util as a dependency for customize-controls.
  • [38642]: Accessibility: Fix the Customizer available menu items toggles focus for Safari and VoiceOver.

Big thanks to those who contributed to patches committed this week: @ryankienstra, @westonruter, @afercia, @ocean90.

We’re always looking for more contributors; check out the open customize tickets and swing by #core-customize in Slack to get involved. Fun fact: we’re 10 commits away from the 1000th commit that references customize.

Agenda for 2016-09-26 Meeting

Our next regularly-scheduled meeting is next Monday, September 26, 2016, 17:00 UTC. Agenda:

4.7 Projects

Additional Tickets Needing Attention

  • Customizer notifications – #35210 – needs UX feedback and a patch
  • Customizer UI Contrast/Focus Styles – #29158 – needs UI ideas for focus styles on back buttons

Ticket Scrub

  • 4.7 Customize tickets sorted by date modified. We’ll discuss everything with no activity in the last week to make sure we’re still on track.
  • We’ll pick a different query to triage each week. For example, bugs awaiting review (need verification).

We’ll see you next week!

#4-7, #customize

Customize Update – 2016-09-15

This is the weekly update post for the customize component. It includes a summary of this week’s meeting, recent commits, and next week’s meeting agenda.

Weekly Customize Meeting Summary

On Monday we held our weekly 4.7 customize component meeting in #core-customize on Slack [logs]. Participants: @celloexpressions, @aaroncampbell, @westonruter, @boone, @adamsilverstein, @afercia, @johnregan3, @ipstenu. This summary also contains a few notes on action since the meeting.

4.7 Projects

  • Create pages within live preview during site setup – #37914#37915, #37916, #38002, #38013 – @celloexpressions
    • @boone joined us for an extensive discussion on how to preview terms in the customizer.
      • When this changes, there is potential for issues based on things that plugins might do, so it would be better to make this sort of change once, as opposed to using a temporary solution, because there could be wasted effort in educating plugin developers twice.
      • We decided that it’s worth exploring a term status API, and if that ends up being something more involved than is feasible for 4.7, potentially going with shadow-draft taxonomies for drafted terms. @boone will post findings on #37915. @aaroncampbell volunteered to help research required API changes here.
    • We’re now tracking the ability to assign auto-drafted pages as a static front page, or to create pages from there, under this project. @westonruter has prototyped how this could work in #38013.
    • We need UX feedback on providing a path to edit newly-created pages, #38002. This was discussed in the design meeting as well but there isn’t an agreed solution yet.
  • A new experience for themes in the customizer – #37661 –@celloexpressions
    • @afercia tested the patch and provided detailed design and accessibility feedback. I evaluated how to approach each item and a few things could use design feedback.
    • I ran an informal user test last week and posted the (generally positive) results on the ticket. @karmatosed is hopefully still interested in coordinating some more formal tests and we need to start that process in the next week.
    • This was also discussed during the design meeting, and could use more eyes and feedback in general. If anyone has thoughts on any of the proposed UI, please share them on the ticket.
  • Code-editing gateways, via CSS – #35395 – @johnregan3
    • We need information from anyone familiar with the CSSTidy library. It seems that the version included in Jetpack is an up-to-date fork, as the original project was last updated in 2007. If anyone from Automattic can provide input here that would be appreciated.
    • We also need to ensure that the license, GPL 2.1 or later is compatible with core.
    • The CodeMirror library is also proposed to be bundled with core for this project; we would like core commiter/lead developer approval for bundling both of these soon so that we can proceed. CSSTidy is a requirement, CodeMirror is a usability enhancement (syntax highlighting).
    • Once we have approval for bundling libraries and a finalized patch, we’ll post a feature proposal here on make/core.
  • Customizer browser history#28536 – @westonruter
    • No updates
  • Customize transactions#30937 – @westonruter
    • No updates
  • Improving sliding panels UI – #34391, #34343, #29158 – @delawski
    • We’re now tracking three tickets with this project, as they combine to provide a single user-facing group of changes for 4.7.
    • I have been testing the patch on #34391 and evaluating potential compatibility concerns. @ipstenu scanned the plugins repo and @djrmom scanned the themes repo for extends WP_Customize_Seection|Panel. Most instances were in themes and plugins bundling copies of the Redux and Kirki frameworks. Both libraries are most likely compatible with the changes, and the authors will test them with the patch to verify. The remaining instances were all in feature plugins for plugins and I checked each of the 16 themes with custom sections manually. All of these themes should be compatiible with the changes, so we should be okay to proceed with the potentially-breaking changes required.
    • @delawski will evaluate how extensively the patch on #37661 will need to be refactored to be compatible with the changes. Unless that’s a significant issue, we should be ready to commit #34391 in the next week.
    • @helen committed a first pass for #29158. We now need UI feedback to come up with better focus states for customizer back buttons.
    • The design team approved the UX proposed in #34343 in this week’s design meeting.
  • Twenty Seventeen
    • There are a few potential customize-related projects. It’s all tentative, but the customize team should be prepared to spend some time at a minimum reviewing and finalizing patches/commits, and where there’s interest, helping to scope, design, and develop these features.
    • Video headers will start as a theme feature, with the possibility of becoming a core add_theme_support (under the customize component) or (maybe) moving to a media ticket for per-post featured media. If it’s in core we may need to refactor header images, but ideally we’d keep it separate, due to the complexity of that feature.
    • A multi-content page feature of some sort will exist in the theme, and may require a core API, which may be in the customizer. This is being discussed in #37974. See also this pull request.
    • Visible edit links (#27403) are desired, but this will take some major UX work. @westonruter suggested that it could be a theme-specific feature, where the theme has to provide styling for them. Ideally, though, it should work for all themes with selective refresh partials providing support for specific features.

Additional Tickets Needing Attention

  • Improve custom background properties UI – #22058 – needs additional feedback and clarification on the latest proposal and patch.
    • Discussed in the design meeting, and we’re generally on the same page on the preferred direction here.
  • Customizer notifications – #35210 – needs UX feedback and a patch
    • Discussed during the design meeting. Next step is for @westonruter to make a patch to facilitate the next round of feedback.
    • This ticket is holding up some of the other tickets on the 4.7 milestone, such as #22037 and #29932, as well as transactions.
  • Remove customizer support for IE8 – #38021
    • If anyone has objections, bring them up ASAP. All links to the customizer will be hidden in IE8 with this change.

Ticket Scrub

We reviewed the bugs in the Future Release milestone that have a patch.

  • #36908: Customizer menus and widgets “search” usability and visual improvements
    • Has a recent patch, assigned to @afercia for review and commit.
  • #21492: Theme customizer > Static front page: missing error message when front page and posts pages are similar
    • Patch needs to be reworked to leverage the notifications API added in 4.6. It would also be better to disable the option for the selected page in the other dropdown.
  • #23225: Customizer is Incompatible with jQuery UI Tabs
    • This is pending customizer transactions and #30028 (loading the customizer preview with natural URL), and the patch on the ticket doesn’t fix the issue.
  • #37032: Guard against infinite reload when setting change causes premature selective refresh
    • Needs testing. If anyone’s interested, please try out the patch and leave feedback on the ticket!
  • #34344: Expanded section margin-top glitches when other section is deactivated
    • This is fixed by the 4.7 project that includes #34391, along with another bug. We’ll revisit the ticket after the commit to verify that it’s fixed as intended.
  • #32577: Customizer QUnit tests not cleaning up
  • #36191: Support responsive images in WP_Customize_Media_Control
    • Work here is being led by the media component. We’ll leave it in future release until they’re ready to revisit it.
    • Note that this ticket is for images in the customizer controls pane. Responsive images on the frontend for images selected in the customizer are a separate topic.
  • #33267: Customizer Theme details: too many events
    • We’ll revisit after work on #37661 is complete, as there are major changes there.
  • #33085: Customizer: controls description inside labels are not real labels nor descriptions
    • The patch here is quite large; @westonruter noted an adjustment that needs to be made and moved the ticket to 4.7. We should get this fixed.
  • #25156: get_custom_header() should return false when there is no header
    • Decided to close the ticket as maybelater due to lack of movement/interest in fixing.

Recent Customize Commits

Here are the customize-related commits for the past week:

  • [38602]: Customizer: Better hover/focus state for section titles and available widgets.
  • [38587]: Customize: Implement previewing of form submissions which use the GET method.
  • [38584]: Menus: Prevent non-published posts/pages from being returned in search results for available items, to match behavior in the customizer.

Big thanks to those who contributed to patches committed this week: @welcher, @westonruter, @celloexpressions, @folletto, @hugobaeta.

We’re always looking for more contributors; check out the open customize tickets and swing by #core-customize in Slack to get involved. Fun fact: we’re 15 commits away from the 1000th commit that references customize.

Agenda for 2016-09-19 Meeting

Our next regularly-scheduled meeting is next Monday, September 19, 2016, 17:00 UTC. Agenda:

4.7 Projects

Additional Tickets Needing Attention

  • Customizer notifications – #35210 – needs UX feedback and a patch
  • Customizer UI Contrast/Focus Styles – #29158 – needs UI ideas for focus styles on back buttons.

Ticket Scrub

  • Customize tickets without replies. Reply to tickets before the meeting to make the list shorter 🙂
  • We’ll pick a different query to triage each week. For example, bugs awaiting review (need verification).

We’ll see you next week!

#4-7, #customize