Customize Changesets (formerly Transactions) Merge Proposal

This is a merge proposal and overview of Customize Changesets (#30937), a project formerly known and proposed as Customizer Transactions back in January 2015. The customizer is WordPress’s framework for doing live previews of any change on your site. One of the biggest problems the customizer faces right now is that changes are ephemeral. If you navigate away, you lose what you are working on. Additionally, you can not share proposed changes with others, nor can you take the changes you are working on and save to continue working later.

Imagine a WordPress user named Tina. Tina is building a website for her daughter’s band. The band has been getting more and more popular, and Tina wants to experiment with some new widgets in the sidebar but also wants to be able to share the proposed solutions with her husband Matthew. Right now, Tina and Matthew would need to be in the same room to collaborate. Or Tina would need to take screenshots, but that kind of defeats the purpose of live preview. If only there was a way to make customizer changes persistent without publishing them.

Introducing Customize Changesets

Customize changesets make changes in the customizer persistent, like autosave drafts. Users can make changes to one theme and switch to another in the customizer without losing the changes upon switching. A customizer session can be bookmarked to come back to later or this URL can be shared with someone else to review and make additional changes (the URLs expire after a week without changes). The new APIs make possible many new user-facing features in future releases and feature plugins, including saving long-lived drafts, submitting changesets as pending for review, scheduling changes, seeing the previewed state on the frontend without being in an iframe, sharing preview URLs with others who do not have customizer access, and others.

Customize changesets allow each change you make in the customizer for a given live preview session to be persistent in the database. A unique identifier (a UUID like f67efbbf-c663-4271-ab1c-95ce1d447979) for each live preview session is generated and as soon as a change is made, the change setting value is sent in an Ajax request to be written into a custom post type whose post_name is the UUID for the customizer session. Once the changes have been written into the changeset post, then any request to WordPress (including to the REST API) can be made with a customize_changeset_uuid query param with the desired UUID and this will result in the customizer being bootstrapped and the changes from that changeset being applied for preview in the response. The unique UUID means that customizer sessions can be sent to other users and also that they can be used as query parameters on the front end.

Design and Technical Decisions

For the initial core merge, no UI changes are being proposed. The feature will only be exposed as the new query parameter on the URL. Adding a UI to this feature will happen in a future release. As such, the proposal for customize changesets is similar to the proposal for including the REST API infrastructure: it provides a foundation for new core features in future releases and a platform for plugins to add new features. Nevertheless, while the customize changesets patch doesn’t introduce any new features it does fix several long-standing issues related to incompatibilities between JavaScript running on the site’s frontend when previewed in the customizer. Under the hood, the customize changesets patch touches on many of the lowest level pieces of the customizer. Please check out the Customize Changesets Technical Design Decisions to see what is happening under the hood.

Testing

Please test! If you use any plugins that extend the customizer, please ensure that there aren’t any regressions. The patch is intended to be fully backwards compatible and users shouldn’t notice any difference in normal use. Two things to look for when testing is as soon as you make a change, you should see a customize_uuid query param added to the URL. You should be able to reload and find your changes persist (note the AYS dialog is retained because there is no UI yet for listing changesets). Also, when you navigate around the preview it should feel much more natural like normal browsing as opposed to having a fade effect. Otherwise, previewing settings that require refresh should still work as normal, as will settings that preview with JavaScript and selective refresh.

The patch is in a GitHub pull request and you can apply the patch via:

grunt patch:https://github.com/xwp/wordpress-develop/pull/161

If you’re using the Git repo from develop.git.wordpress.org then you can check out the branch directly via:

git remote add -f xwp https://github.com/xwp/wordpress-develop.git && git checkout xwp/trac-30937

I’d appreciate code review feedback directly on the pull request. For any revisions to the patch, please open a pull request to that trac-30937 branch if possible.

The Future

In future releases we can explore new UIs to take advantage of the new capabilities that changesets provide. New UIs can provide a way to schedule changes, the ability to undo the last change, show an audit log (revision history) for changes, collaborative editing of a customizer changeset, and so on. Future feature projects will explore many of these and feature plugins will start to prototype them.

Thanks to @jorbin who contributed to this proposal post.

#4-7, #customize, #feature-projects, #proposal

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

Changes to Customizer Sliding Panels/Sections in WordPress 4.7

Several updates to the customizer’s sliding panels/sections implementation are going to be introduced in WordPress 4.7. The changes are now available in trunk, so you can test them with existing themes and plugins. It is worth noting that all instances of custom sections and panels in the WordPress.org plugin and theme repositories were checked by @celloexpressions. No conflicts were found, but still testing is advised.

tl;dr – The Solution

The root “panel” of the customizer (the links to the panels and panel-less sections) is now logically independent in the DOM from the panels and sections it links to, and likewise the links to sections within a panel are disconnected in the DOM from the container elements for the sections they link to. By keeping these separate, no margin-top hacks are needed anymore: the panel/section to be shown simply needs to be positioned to the top of the customizer pane. This also means accessibility hacks which set the root of the customizer to visibility:hidden but a nested child element to visibility:visible are not needed anymore (see #33258). To maintain the accessibility benefit that came “for free“ with the previous nested hierarchical unordered list, aria-owns property has been implemented to relate the panel/section links with the panel/section containers they link to.

For more context, please refer to the original ticket: #34391.

The patch should also fix related issues: #34344, #35947.

Flat Panels/Sections Structure

So far panels and sections markup was nested inside one huge ul list inside the customizer pane.

<div id="customize-theme-controls">
  <ul>
    <li id="accordion-section-foo" class="accordion-section control-section...">
      <h3 class="accordion-section-title">...</h3>
      <ul class="accordion-section-content...">
        <li class="customize-section-description-container">...</li>
        <li class="customize-control customize-control-text">...</li>
        ...
      </ul>
    </li>
    <li id="accordion-panel-bar" class="accordion-section control-section control-panel...">
      <h3 class="accordion-section-title">...</h3>
      <ul class="accordion-sub-container control-panel-content">
        <li class="panel-meta accordion-section...">...</li>
        <li id="accordion-section-baz" class="accordion-section control-section control-subsection">...</li>
      </ul>
    </li>
  </ul>
</div>

With #34391 being merged each panel/section content element is detached from the root “panel” and appended to the parent container #customize-theme-controls right after the root list.

<div id="customize-theme-controls">
  <ul class="customize-pane-parent">
    <li id="accordion-section-foo" class="accordion-section control-section..." aria-owns="sub-accordion-section-foo">
      <h3 class="accordion-section-title">...</h3>
    </li>
    <li id="accordion-panel-bar" class="accordion-section control-section control-panel..." aria-owns="sub-accordion-panel-bar">
      <h3 class="accordion-section-title">...</h3>
    </li>
  </ul>
  <ul id="sub-accordion-section-foo" class="customize-pane-child accordion-section-content accordion-section control-section...">
    <li class="customize-section-description-container">...</li>
    <li class="customize-control customize-control-text">...</li>
    ...
  </ul>
  <ul id="sub-accordion-panel-bar" class="customize-pane-child accordion-sub-container control-panel-content accordion-section control-section control-panel...">
    <li class="panel-meta accordion-section...">...</li>
    <li id="accordion-section-baz" class="accordion-section control-section control-subsection" aria-owns="sub-accordion-section-baz">
      ...
    </li>
  </ul>
  <ul id="sub-accordion-section-baz" ...>
    ...
  </ul>
</div>

A few additional notes:

  • New getContent() method of the Container class has been introduced.
    • It is responsible for the actual detachment of the content element (usually ul).
    • It should be overridden in the custom sections and panels if it makes more sense to not detach the content element from the parent and keep it nested.
    • It should also be overridden if custom expanding logic is used (e.g. ‘New Menu’ section in the Core).
  • New Container class properties are now available:
    • headContainer is a jQuery object containing the parent element (usually the li). So far the same object was kept in the container property.
    • contentContainer is a jQuery object containing the child element (usually the ul).
    • container is now a jQuery object with two members: headContainer and contentContainer. This way the backwards-compatibility is improved, as any jQuery methods working on a set of elements like find() or on() should still work with the container as before.
  • CSS classes that were possessed by the parent element are copied to the child container, which also is a way to improve the backwards-compatibility.
  • In order to keep logical relationship between the parent and the child elements (which no longer can be determined naturally from the HTML structure), the parent element has new aria-owns property. It lists all children elements of the container.
  • _recalculateTopMargin() method was dropped completely, as it is no longer relevant.

I highly encourage developers who have done any JS/CSS-heavy work with the customizer’s panels/sections to review the changes introduced by #34391 and test them with themes and plugins.

Transitioning translateX() Instead of left

Along the update to the inner structure of the panels/sections, the user experience of sliding panels has been improved. Now instead of transitioning left position of the container, translateX() is used. It makes the animation smoother and more performant.

  • A busy class has been introduced. It is added to the panels/sections that are going through CSS transition at a given moment.
  • The busy class is added and removed in the Container‘s new method: _animateChangeExpanded( completeCallback ). The method takes care of detecting if transitions are supported by the browser, initiating the transition and listening for normalised transitionend event. It takes one parameter, completeCallback, which is called when the transition is complete.

I hope that working with customizer’s sections and panels will be easier and more reliable with the new structure. If you find any bug related to the update, feel free to add a comment here or directly in the Trac ticket: #34391.

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

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

Customize Update – 2016-09-08

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: @paaljoachim, @celloexpressions, @westonruter, @johnregan3, @clorith, @melchoyce. This summary also contains a few notes on action since the meeting.

4.7 Projects

  • Create page-based nav menus without leaving live preview – #37914#37915, #37916@celloexpressions
    • These follow up tickets are largely pending feedback from the Taxonomy component. We need to work with @boone to come up with master plan for previewing terms, and determine whether we can realistically add term-creating support in menus in 4.7.
    • @boone has this on his list for later this week.
    • We need one more follow up ticket to provide users with a path to adding content to newly-created pages; currently there is another usability dead end here (see #38002).
  • A new experience for themes in the customizer – #37661 –@celloexpressions
    • I added shiny updates and deletion, as well as refining the UI for users that can’t install themes this weekend, and posted a new patch. Also explored reviews, and we’ll need API support from .org if we want to load them inline in the future.
    • Only major development task remaining is shiny theme upload.
    • We discussed whether it might make sense to delete/uninstall themes if a user previews them and then moves on. Need to explore user expectations here as part of the testing and feedback processes, as this would be a change from the current core behavior.
    • @karmatosed had some trouble getting the style changes from the patch, once that’s resolved we’ll start the user testing and design iteration process.
    • @aaroncampbell is interested in helping out here. For everyone interested, please start looking at/testing the patch and reporting issues or ideas on the ticket or in #core-customize.
  • Code-editing gateways, via CSS – #35395 – @johnregan3
    • @johnregan3 brought up in the ticket, based on input from @joyously that it might make sense to allow theme-independent styles. We reached a consensus that theme-specific styles are more important for core for now, and plugins can add additional global CSS options. We can revisit this for core in the future.
    • @johnregan3 has created a code editor control leveraging the CodeMirror library that’s also used by Jetpack. The Custom CSS setting now saves to a post, and he’s working on updating the post when the customizer is saved. He shared an initial patch for review later this week.
  • Customizer browser history#28536 – @westonruter
    • No updates
  • Customize transactions#30937 – @westonruter
    • No updates
  • Refactoring sliding panels UI – #34391 – @delawski
    • @delawski has posted an updated patch for review. We’d like to get a first patch in soon so there’s plenty of time to test compatibility with third-party custom sections.
    • #34343 is related to improving the sliding panel experience, and @delawski is working on that next for 4.7.

Not every project needs to have an update every week; the primary purpose of our meetings is to make sure that no one gets stuck and to provide group feedback/decisions as needed. With about a month and a half before the merge deadline for 4.7, all of our 4.7-targeted projects are still on track for that milestone.

Future Release Project Updates

  • Customize Posts
    • @westonrtuer brought up an issue with adding a post parent control that let to an implementation of the dropdown-pages control that leverages Select2. This improvement could be implemented in the core control in 4.7. There is a feature plugin called Customize Object Selector that replaces the dropdown-pages control with this scalable multi-select control for the page on front and page for posts controls.
    • @clorith pointed out that accessibility concerns had previously stalled implementations of Select2 in core. We pinged @afercia to have the accessibility team review whether there are still issues with the newest version of Select2. Unfortunately, it has significant accessibility problems and the maintainers haven’t shown interest in resolving the.
    • We also discussed that work on Customize Posts has developed most of what’s needed to use JS templates for the base WP_Customize_Control UI. This will be implemented in #30738 for 4.7, along with support for setting values that are objects.

Additional Tickets Needing Attention

  • Improving contrast and UI consistency in the customizer – #29158needs-testing
    • @clorith really likes it and @westonruter thinks it looks nice but doesn’t have strong feelings. With no objections from the customize component, we’re waiting for the design team to approve or suggest additional revisions.
    • Discussed during the design meeting, and pending patch testing we’ll get the initial pieces in and continue iterating.
  • Improve custom background properties UI – #22058 – needs additional feedback on the latest proposal, and a patch. Also needs design decisions.
  • Appropriate means for themes to add top-level promotional links – #37335– needs input from theme review team
    • They discussed in their meeting last week, and it’s now pending additional investigation of alternative approaches for theme developers. We’ll follow up with the theme review team in a few weeks.
    • In the meantime, the theme review team is no longer allowing links to be added by injecting markup into the DOM with JS.
  • Customizer notifications – #35210 – needs UX feedback and a patch
    • @westonrtuer added clarifications to the ticket, and @afercia provided accessibility feedback there as well. We should be able to implement the accessibility changes, so we’re currently waiting for design feedback again.

Ticket Scrub

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

  • #34747: Provide more flexibility for “You are customizing” text
    • This is pending the direction of the sticky-headers discussion, but we’re not all convinced that it should be able to be customized on the top level (it can already be changed in sections and panels).
  • #18584: Nav menus need more hooks for extensibility (on admin page & in customizer)
    • #30738 will introduce functionality that will help enable saving custom menu item fields. Once that’s in place, we can revisit how the API would work for plugin developers and determine whether there’s still time to get it in for 4.7.
  • #36175: Simplify the Customizer Image Control action buttons
    • We need to come up with an accessible solution and make sure the experience is consistent across the various media controls.
    • @melchoyce doesn’t want to continue owning the ticket for now but will take a look again later in the 4.7 cycle.
  • #31334: Customizer JS API should handle container removal from document
    • I had forgotten about this ticket and commented about this issue on #30741 recently.
    • We discussed the potential issues with using jQuery.remove(), and could potentially use jQuery.detatch() instead. However, menus and widget currently use remove() in core, so we should standardize the behavior and incorporate it into the API.
  • #32296: Allow the customizer to be made wider
    • I suggested that we likely won’t make a major change here until we make major changes to the customizer UI in general. However, there is a patch that makes the customizer proportionally wider on large desktop screens, and that could easily happen for 4.7 if others are okay with this approach in the interim.
  • #33064: Customizer: form inputs need a way to have hidden labels
    • I’m somewhat uncomfortable with adding a new class variable for this, and doing that means we also need to update all children of WP_Customize_Control to support it in core. However, this is an important feature to support in the API, so we’d like to get it in for 4.7.
  • #21627: Filter for custom-background CSS selector
    • This ticket seems to have been forgotten about, but adds a lot of flexibility to the custom background feature and would be nice for 4.7 alongside #22058. Moved to the 4.7 milestone.

Recent Customize Commits

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

  • [38513]: Customize: Fix php warning due to WP_Customize_Manager::prepare_setting_validity_for_js() incorrectly assuming that WP_Error will only ever have arrays in its $error_data.
  • [38520]: Accessibility: Improve the Customizer and Theme Installer initial focus.
  • [38577]: Customize: Prevent widget previewing logic from building invalid jQuery selectors when sidebars are registered without a class name in before_widget.

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

We’re always looking for more contributors; check out the open customize tickets and swing by #core-customize in Slack to get involved.

Agenda for 2016-09-12 Meeting

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

4.7 Projects

Additional Tickets Needing Attention

  • Improving contrast and UI consistency in the customizer – #29158 – needs-testing
  • Improve custom background properties UI – #22058 – needs additional feedback on the latest proposal, and a patch
  • Customizer notfications – #35210 – needs UX feedback and a patch

Ticket Scrub

  • Identify tickets ready for commit consideration, and 4.7 milestoning from future release bugs with a patch.
  • 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-01

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.

Customize 4.7 Kickoff Meeting Summary

On Monday we held the customize component kickoff meeting in #core-customize on Slack [logs].

Potential 4.7 Projects

We started by identifying potential projects for 4.7, and people to lead them. The following projects are currently targeting merge for WordPress 4.7:

  • Create page-based nav menus without leaving live preview#34923 – @celloexpressions
    • @westonruter committed a first pass here, closing the primary ticket as fixed.
    • #37914, #37915, and #37916 have been created for follow up, and are currently in the 4.7 milestone. We need input from the taxonomy component to enable terms to be previewed before adding support for terms.
  • A new experience for themes in the customizer#37661 – @celloexpressions
    • There are a few more dev-heavy tasks but we’re ready for design feedback (@folletto will take a look when he has time) and user testing.
    • In the core dev chat, @karmatosed volunteered to coordinate user testing here.
  • Code-editing gateways, via CSS#35395 – @johnregan3
    • We decided that bundling CSSTidy (used by Jetpack) in core is the best solution for sanitizing CSS.
    • Syntax highlighting for a more proper code-editing experience is a nice-to-have but not required for a first pass.
    • CSS should be stored in a new custom post type (with revisions), with a distinct post for each theme (i.e., all CSS will be theme-specific here).
    • @johnregan3 volunteered to spearhead this project and expects to have it ready for 4.7.
  • Customizer browser history #28536 – @westonruter
    • Development is happening on github, and there is only one issue currently, with customize-loader.js. We discussed potentially eliminating the iframe aspect of the customize loader script eventually, as it has caused a lot of issues and doesn’t offer significant usability benefits.
    • We also need to investigate possible performance issues in conjunction with #37661.
  • Customize snapshots/transactions #30937 – @westonruter
    • We decided that the snapshots UI will remain in a plugin for now, but transactions themselves could potentially be ready for 4.7. Transactions allow for the customizer to be used to preview changes to REST API in headless sites.
    • @westonruter brought up a few concerns with the sequencing of transaction updates and selective refresh, which could result in two HTTP requests for the preview where there was previously one. Ensuring no degradation in performance is key here.
    • Transactions would complement #37661 nicely in 4.7 even without the snapshots UI, as theme customizations during the theme selection workflow could be saved without being published to the live site.
  • Customizer notifications #35210 – @westonruter
    • This needs more design feedback and a patch based on the latest proposal.
    • This is less of a project, so we’ll track it as a ticket moving forward.
  • Refactoring sliding panels UI#34391 – @delawski
    • @delawski will work to finish this up soon so that it can get into 4.7 relatively early.
    • We’ll need to coordinate this with the theme experience refresh in #37661, which bypasses the margin-top hacks.

Additional projects discussed:

  • Improve UI for linking preview elements to controls#27403
    • We might try to make some improvements here, but we aren’t currently targeting major changes for 4.7. This might change if more contributors contribute here, particularly on the design side.
  • Twenty Seventeen
    • @helen mentioned in the dev chat that information on Twenty Seventeen will be announced next week. Depending on the customize scope, we might want to have a dedicated person to help there and report back to the customize component meetings.
  • Customize Posts
    • Not targeting 4.7, but it would greatly benefit from a thorough UX review now that the majority of the functionality is in place.
    • We’d like to fix #30378 in 4.7, using JS templates for the base WP_Customize_Control UI, to support the plugin.
    • A new project to bring similar functionality to taxonomy terms is breaking ground.
  • Live Preview Feature Project
    • After 4.7, we’ll revisit this project to take a holistic look at how live preview works in core. The end result will likely be a UX strategy for introducing contextual live preview for posts and terms, likely leveraging the existing customizer API and technology developed in the Customize Posts plugin, but potentially with an entirely different user interface than what’s currently known as the customizer: namely, looking at ways the customizer framework can be bootstrapped onto the frontend along with inline editing.

Additional Tickets Needing Attention

We briefly drew attention to the following tickets needing feedback from other teams:

  • Improving contrast and UI consistency in the customizer – #29158needs-testing
  • Improve custom background properties UI – #22058 – needs additional feedback on the latest proposals, and a patch
  • Appropriate means for themes to add top-level promotional links – #37335 – needs input from theme review team
    • The theme review team agreed that this was probably a good solution, but wants to investigate other options for developers before moving in this direction. On the core side, we’ll wait for direction from them

Open Floor

We closed with an open floor in lieu of a ticket scrub, due to time.

  • @clorith brought up sticky panel headers/back buttons (#34343 and #35186)
    • @delawski would like to work on these tickets after finishing #34391. We’ll need additional design feedback here as well to decide the direction (probably one or the other of the tickets).

Recent Customize Commits

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

  • [38396]: Customize: Circumvent the customizer attempting to preview links to static assets (such as uploaded images).
  • [38436]: Customize: Allow users to more seamlessly create page-based nav menus during customization.
  • [38464]: Customize: Improve handling of active state for dynamically-created controls/sections/panels.
  • [38478]: Customize: Use new `$status_code` parameter for `wp_send_json_error()` instead of calling `status_header()` separately.
  • [38479]: Customize: Fix i18n by re-using the `add_new_item` post type label instead of using a post type name in a generic string, in [38436].
  • [38492]: Customize: Introduce `paneVisible` state and ensure pane is visible when a construct is expanded (or focused).
  • [38503]: Accessibility: Make links in the Customizer underlined by default.

Big thanks to everyone who contributed to patches committed this week: @Presskopp, @afercia, @westonruter, @celloexpressions, @valendesigns, @melchoyce, @mapk, @iseulde, @mrahmadawais, @sayedwp, @johnbillion, and @curdin.

We’re always looking for more contributors; check out the open customize tickets and swing by #core-customize in Slack to get involved.

Agenda for 2016-09-05 Meeting

We will have a meeting next week despite the holiday in the US; Monday, September 5 at 17:00 UTC. Agenda:

4.7 Projects

Additional Tickets Needing Attention

  • Improving contrast and UI consistency in the customizer – #29158needs-testing
  • Improve custom background properties UI – #22058 – needs additional feedback on the latest proposal, and a patch
  • Appropriate means for themes to add top-level promotional links – #37335 – needs input from theme review team
  • Customizer notfications – #35210 – needs UX feedback and a patch (and perhaps a clearer demonstration of the iteraction)

Ticket Scrub

  • Identify tickets ready for commit consideration, and 4.7 milestoning from future release tickets with a patch.
  • 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