Dev Chat Summary: February 15th (4.7.3 week 3)

This post summarizes the dev chat meeting from February 15th (agendaSlack archive).

4.7.3 Schedule

  • Completed first pass on all tickets in the 4.7.3 milestone, @jnylen0 is reviewing those that “need” to land in 4.7.3, and identifying a release date for 4.7.3 in the coming week

Customizer team update

  • #23601 (Use ACE Code Editor for Theme and Plugin editors) and #12423 (Include Ace (or similar) as default code editor)
    • Topic of discussion is a code editor library to be used in Custom CSS, WP content editor HTML view, file editor, and any other place that code is modified
    • Had planned to go ahead with CodeMirror since it is what Jetpack uses in its Custom CSS module, but @afercia pointed out accessibility problems
    • So we’re looking for insights into best of breed accessible code editor libraries
    • @afercia: looking to to understand if (1.) there’s consensus about introducing some sort of syntax highlighter library (plus other functionalities) and (2.) if it is going to completely replace the current WP content editor HTML view
    • @jorbin: Once one is decided upon, would like to encourage reaching out to the project maintainers and opening a dialogue about things like security and backwards compatibility
    • @helen: each area (Custom CSS, WP content editor HTML view, file editor) needs individual consideration and rationale
    • Goal is to provide a better user experience for when users edit code in WP
    • Custom CSS:
      • #38707: Customizer: Additional CSS highlight, revisions, selection, per-page, pop-out
      • @westonruter this is what #core-customize is most interested in, but picking a code editor library should be done ensuring that it doesn’t cause headaches if code editors are implemented for HTML view and file editor. i.e. the same library should be used throughout core.
    • WP content editor HTML view:
      • @joemcgill: the text editor now is not technically an HTML view, but is a plain text editor that is parsed into HTML. For instance, breaks are turned into `<p>` tags, shortcodes can be typed, etc., so a “code editor” is something slightly different.
      • @helen: per @iseulde and lots of discussions over time, is a little more complicated in that it’s not an actual HTML editor, so is getting rid of wpautop() is a requirement
      • @mike: I’d love to see code highlighting in the HTML view.
      • @afercia: If both the visual editor and the text editor are going to be replaced by Gutenberg and some sort of CodeMirror-like, well the level of accessibility for both is still uncertain and there’s the danger to introduce an accessibility barrier for the main scope of WordPress: entering content.
    • File editor:
      • @jorbin: I seem to remember that having been replaced with something fancier than what is in place now, but that having been ripped out
      • @helen: File editors really raise the question of whether users should be made more comfortable in them vs. being encouraged to use something else.
      • @brechtryckaert: security-wise I’m not a fan of the ability to edit files from the backend, people who are comfortable enough to edit code usually have a prefered editor
    • @jorbin: We already have our agreed upon accessibility coding standards that state:
      • All new or updated code released in WordPress must conform with the WCAG 2.0 guidelines at level AA

    •  @westonruter: if CodeMirror fails this test, as it seems to, then we need input on GPL-compatible code editors that are accessible.
    • @afercia: I propose to discuss this at the next accessibility meeting on Monday, invite people to do research, and possibly involve the testers group.
  • #38900 (Customize: Add REST API endpoints for changesets) and #39634 (Customize: Add REST API endpoints for panels, sections, controls, settings, and partials)
    • Thanks to @kadamwhite we have an initial (empty) feature plugin repo for the REST API endpoints for customization
    • Feel free to watch that repo and be apprised of developments
    • Next steps are to design the endpoints, write the failing tests for them, and then  go about writing the endpoint controllers
    • @kadamwhite: this is the first major effort within other areas of core that are turning up inconsistencies like #39805 (Expose featured_media property on post resources in “embed” context) so I’m excited to see what other improvements we can make as this work continues

Editor team update

  • Working full steam on prototypes, notably the Gutenberg UI prototype
  • The related GitHub repo has quickly become wonderfully active
  • Looking to discuss browser support for the new editor
    • @georgestephanis: So long as it can fall back to something that doesn’t utterly die, it should probably be fine.
    • WP Admin currently supports IE 8
    • Current browser market share
    • @jorbin: I would love to see us not drop support for anyone if possible
    • @joemcgill: Alternately, if we’re going to bump the browser requirements at any point, now is probably the time.
    • @joen: flexbox was mentioned as being nice to use in context of editor UI
    • flexbox support
  • The agenda for the Editor chat today was to discuss how using the UI prototype felt in the past week, and deciding where to take it next
  • We are looking for people to use and provide feedback the prototype, so please take a look if you can!

REST API team update

  • The REST API team has no significant updates since last week.

#4-7, #4-7-3, #core-editor, #core-restapi, #dev-chat, #summary

Improving the Settings API for accessibility and ease-of-use

On January 2nd the first meeting to discuss improvements of the well-known, but not well-loved Settings API took place in #accessibility. After a healthy discussion the next meeting was set to take place last Monday. Since the suggested improvements are not solely related to accessibility, the location for the meeting was moved to #core. This post is a recap of what was decided during these two meetings.

Archives of the full conversations:

Attendees: @afercia, @flixos90, @helen@joedolson, @johnbillion, @rianrietveld, @sc0ttkclark

First Meeting

The original reason for calling these meetings were several accessibility problems on WordPress settings pages. To quite some extent, these are related to the table markup that is automatically printed by the current Settings API. On a related note, it was mentioned that being required to write callback functions for rendering each and every field is a major drawback. Providing default callbacks would thus not only make it easier to work with the API, but also further improve accessibility as these callbacks would all be reviewed by the team. So the two main goals that were figured out were:

  • Add some basic support to automatically render fields so that plugin developers no longer need to write their own callback functions for basic fields.
  • Get rid of the table structure to improve accessibility. Furthermore the accessibility team should also ensure that the markup generated as the core field output is accessible.

The first meeting was also centered on whether these improvements should be tackled through means of the Fields API project, a new “Settings API v2” or improving the existing Settings API. In the end it was decided to continue working with the existing API, mainly for the following reasons:

  • The Fields API project is a huge effort that will still take a while until it can possibly be merged into core. Still, it will follow up with the changes that will be introduced in the Settings API, as @sc0ttkclark pointed out. While printing fields is certainly the focus of the Fields API, introducing a few technically simple callbacks in core at this point will not be a problem as these can be migrated to the Fields API ones at any time.
  • While the existing Settings API has its problems, it appears to be possible to handle the necessary improvements without running into backward-compatibility issues. A completely new Settings API could have further benefits, but it would leave many users behind that would need to manually migrate, and furthermore would take much longer to scaffold and implement.

After the meeting, a general ticket for the task was opened at #39441. The ticket description provides more information on how the two identified goals should be accomplished. In addition to the technical details, the first part of the accessibility measures will be to create an HTML-only prototype of what a better settings page would look like. It should be created without the limitations of the Settings API, so that the result can be the best possible example for what the enhanced Settings API should produce.

Second Meeting

@rianrietveld had four items on the agenda for the second meeting.

  • At first, everyone was asked to review the patch that @flixos90 provided on the above ticket. The patch only applies to introducing default field callbacks, so it still lacks adjustment of the table markup and a proper accessibility review, but it shows a possible technical approach.
  • Related to the patch, a tiny plugin was created and uploaded to the ticket as well. This plugin allows for easy testing of the functionality. For easier collaboration and possible iterations, that plugin has now been moved to GitHub. Feel free to try it out with the patch applied.
  • Some results of an accessibility test for form elements that was conducted by the accessibility team were revealed as a preparation for the prototype settings page in HTML. A few major issues to consider were discussed, for example the requirement of IDs on every field, the proper usage of fieldset and legend elements and the problematic usage of <input type="number"> for Dragon NaturallySpeaking speech recognition software. For creating the HTML prototype, it was decided to focus on replicating the core settings pages “General” and “Discussion”.
  • For the next step of the efforts, @afercia volunteered for creating the prototypes. As of now, the field markup he created for the two replicated settings pages can be inspected on GitHub (last two items in the list). These will probably be discussed in the next meeting.

If you are interested in helping out, there are several ways for you to do so: Please review the suggested improvements, the HTML prototypes and/or the technical approach. Feedback can be provided on the ticket, this post or by participating in the upcoming meeting/s. The Settings API meeting takes place biweekly on Monday at 17:00 UTC, so feel free to drop by. The next meeting will be on Monday, January 30.

#accessibility, #settings

Week in Core, November 30 – December 6, 2016

Welcome back the latest issue of Week in Core, covering changes [39380-39529]. Here are the highlights:

  • 150 commits
  • 63 contributors
  • 140 tickets created
  • 17 tickets reopened
  • 104 tickets closed
  • WordPress 4.7 released 🎉

Ticket numbers based on trac timeline for the period above. The following is a summary of commits, organized by component.

Code Changes


  • Accessibility: Remove inappropriate content from the Themes screen heading. [39528] #26601
  • Accessibility: Remove inappropriate content from the Add Themes screen heading. [39527] #26601
  • Accessibility: Remove inappropriate content from the Media Library screens headings. [39526] #26601

Build/Test Tools

  • Correctly set up the current screen during list table tests so that they don’t fail when run individually. [39481] #38761
  • Specify exact node version in package.json. [39480], [39478] #35105, #38657
  • Remove PHP 7.1 from allowed failures [39424-39425] #37625

Bundled Theme

  • Default Themes: Update version numbers and readme files for 4.7 release [39496] #38858
  • Twenty Seventeen: Fix CSS specificity problem with CSS feature query for object-fit [39495] #39073
  • Twenty Seventeen: Improve display of video header and header image in modern browsers [39485], [39483] #39035
  • Twenty Seventeen: Add specific font stack for Thai language [39484], [39482] #38937
  • Twenty Seventeen: Improve ARIA for the nav menu. [39451-39452] #39029, #39026
  • Twenty Seventeen: Ensure header text color updates in Customizer preview when cleared [39447-39448] #38993
  • Twenty Seventeen: Fix broken menu toggle in Customizer after menu items are added [39419], [39423] #38992
  • Twenty Seventeen: Fix style issues with gallery image links [39418], [39422] #38969
  • Twenty Seventeen: Hide front section panels on page load of Customizer. [39417], [39421] #38951
  • Twenty Seventeen: Add .has-header-video styles for custom color schemes. [39416] #38995
  • Twenty Seventeen: Better handling of custom headers when no image is set. [39413-39414] #38995
  • Twenty Seventeen: Make spacing on pages without comments consistent [39404-39405] #38972
  • Twenty Seventeen: Make sure header text color is applied when color schemes are active. [39397-39398] #38980
  • Twenty Seventeen: Make fixed navigation apply at correct height on front page, without header video or image [39394], [39392] #38927
  • Twenty Seventeen: Provide a background color fallback for non-webkit browsers on input styles [39388] #38939
  • Twenty Seventeen: Allow child themes to easily extend custom color patterns [39386] #38949
  • Twenty Seventeen: Make screen reader text on scroll arrow more meaningful [39384] #38970
  • Twenty Seventeen: Keep header videos from extending past footer. [39380-39381] #38950


  • Merge a similar string between comments.php, XML-RPC and the REST API comments controller. [39508] #39013


  • Prevent infinite full refresh from occurring when selective refresh falls back for a nav menu that has items excluded from rendering via filtering. [39510-39511] #38612
  • Defer populating post_name for auto-draft posts in customized state until posts are published. [39506-39507] #39078
  • Ensure changeset_uuid query param is removed from the customize.php window’s location once a changeset has been published (committed) with starter content. [39504-39505] #39081
  • Prevent posts/pages imported via starter content from being dropped when adding post/page stubs via nav menus and the dropdown-pages control. [39502-39503] #38114, #34923, #39071
  • Ensure textarea for Custom CSS displays as code (in LTR) when an RTL language is active. [39499-39500] #35395, #39085
  • Ensure a custom_css post insertion gets an initial post revision. [39479], [39477] #30854, #38672, #35395, #39032
  • Custom CSS: Change the help link to something better for users. [39467], [39466] #39015
  • Fix posts limit query arg for WP_Query from incorrect number to posts_per_page. [39434-39435] #39022
  • Reuse existing non-auto-draft posts and existing auto-draft posts in the customized state with matching slugs when applying starter content. [39411] #38114, #38928
  • Reject a changeset update when a non-future date is provided and also ensure that a published changeset always gets set to the current date/time. [39409-39410] #30937, #38943
  • Fix handling of the nav menu item labels (titles) that match defaults (original titles) and fix the display of item type labels. [39395], [39393] #38015, #38955





  • Accessibility: Improve keyboard accessibility avoiding confusing tab stops in the Media views. [39529] #30599
  • Docs: Add inline documentation for image-edit.js. [39493] #38748
  • Fix regression with display of small images in media library. [39399], [39396] #38965
  • Docs: Document the usage of the global $wpdb in _filter_query_attachment_filenames(). [39390] #38973


  • Tag 4.7 [39525] #
  • WordPress 4.7 “Vaughan”. [39524] #
  • Post-RC3 bump. [39519] #
  • WordPress 4.7 RC3. [39516] #
  • Post-RC2 bump. [39474] #
  • WordPress 4.7 RC2. [39473] #
  • Twenty Seventeen: Add .has-header-video styles for custom color schemes. [39415]

Options, Meta APIs

  • REST API: Register the admin_email setting in single site only. [39470-39472] #38990
  • REST API: Site URL setting should not be present on multisite installations. [39468] #39005
  • REST API: Correct the admin_email setting description for single site installs. [39406] #38990
  • Multisite: Display different descriptions for multisite or single site installations. [39407] #38990
  • Options: Pass the $passed_default parameter to the 'default_option_{$option} filter in add_option(). [39382] #38176, #38930



  • Comments: Merge similar strings between comments.php and the REST API comments controller. [39490-39491] #39014
  • Merge similar date strings in the revisions and comments controllers. [39488-39489] #39016
  • Treat any falsy value as false in ‘rest_allow_anonymous_comments’. [39487] #39010
  • Docs: Add missing REST API-related args to register_post_type() and register_taxonomy(). [39462-39463] #39023
  • Merge similar strings in a comments endpoint parameter description. [39457] #39036
  • Fix bug where comment author and author email could be an empty string when creating a comment. [39446], [39444] #38971
  • Fix handling of some orderby parameters for the Posts controller. [39440-39441] #38971
  • Disable DELETE requests for users in multisite. [39438-39439] #38962
  • Return a WP_Error if meta property is not an array. [39436-39437] #38989
  • Add test for creating a comment with an invalid post ID. [39408] #38991
  • Fix incorrect uses of rest_sanitize_value_from_schema(). [39400-39401] #38984


  • Don’t assign the delete_site capability to anyone on single site installs. [39494] #38326
  • Multisite: Replace is_super_admin() with manage_network for admin bar permissions. [39492] #39064, #37616


  • Docs: Update an @since as there will not be a 4.6.2 before 4.7. [39475-39476] #37291
  • REST API: Capability check for editing a single term should use the singular form. [39464] #35614, #39012
  • REST API: Use the correct error message when editing a single term. [39460-39461] #39017
  • REST API: Fix incorrect capability check on term create. [39402-39403] #35614, #38958
  • Performance: Revert [38677] from the 4.7 branch. This avoids fatal errors caused with recursive calling of term functions within the get_terms filter. [39454] #21760


  • Reuse existing non-auto-draft posts and existing auto-draft posts in the customized state with matching slugs when applying starter content. [39412] #38114, #38928


  • Fix the styling of notices generated by the editor UI. [39501] #38917


  • Clarify the return value of get_current_user_id() for non-logged-in users. [39486] #39051
  • REST API: Require the reassign parameter when deleting users. [39426-39427] #39000

Thanks to @andizer, @mor10, @adamsilverstein, @afercia, @azaozz, @boonebgorges, @celloexpressions, @ChopinBach, @clorith, @coffee2code, @davidakennedy, @dd32, @desrosj, @dlh, @flixos90, @georgestephanis, @helen, @helen, @hnle, @iaaxpage, @imnok, @jbpaul17, @jeremyfelt, @jnylen0, @joedolson, @joehoyle, @joemcgill, @johnbillion, @jorbin, @kadamwhite, @karmatosed, @ketuchetan, @laurelfulford, @littlebigthing, @lucasstark, @melchoyce, @michaelarestad, @mikeschroder,, @nacin, @netweb, @ocean90, @ovenal, @pento, @peterwilsoncc, @presskopp, @rachelbaker, @rahulsprajapati, @ramiabraham, @ramiy, @rensw90, @rianrietveld, @rmccue, @samuelsidler, @sayedwp, @SergeyBiryukov, @sstoqnov, @The PHP tea, @timmydcrawford, @utkarshpatel, and @westonruter for their contributions!

#4-7, #week-in-core

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:

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:

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:

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:

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:

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:

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.


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

Starter content for themes in 4.7

One of the hardest things for people setting up sites with WordPress for the first time is understanding what themes are and how a given theme can work for you, especially when there’s no content there to visualize. There are also significant gaps between local theme previews, screenshots, and .org previews. Even when there are easy-to-use site customization tools, it is difficult to figure out where to start and what things are going to be like.

To help users along that path, 4.7 introduces the concept of “starter content” – theme-specific selections of content to help showcase a theme to users and serve as a starting point for further setup of new sites. Starter content works especially well in tandem with visible edit shortcuts, allowing users to not only see what content might work best where within a theme, but from there to be able to jump to building off of that base without having to initially spend time figuring out, say, which widgets areas map where.

How it works

Starter content is applied and displayed upon entering the customizer, with no changes appearing on the live site until customizer changes are explicitly saved and published. In 4.7, this initial view of a theme with starter content will only happen for “fresh sites” – new installs that have not yet had any posts, pages, widgets, or customizer settings updated. This state is indicated in the fresh_site option with a value of 1. The current limitation is in line with prioritizing initial site setup for this release, and allows for themes to begin implementing content and ensuring that there is a solid base before introducing more complicated logic and UI to “merge” starter content with existing content in a future release (#38624). That being said, if two themes in a given fresh site both have starter content, if the starter content from the first theme is applied and you make some changes to that starter content, when you switch to the second theme the starter content from that theme will override the starter content from the first theme only for the settings which have not been modified. Also remember that theme mods are always theme-specific, so starter content for theme switches will never be copied.

Core provides a set of content that themes can select from (technical details below). These include a variety of widgets, pages, and nav menu items (including references for the pages), along with the ability to provide attachments, theme mods, and options. Any included images for attachments need to be from within a theme or plugin folder and cannot be loaded from an external URL. Twenty Seventeen will ship with starter content enabled; there are no plans to add the functionality to past default themes.

How to use it

Themes define a subset of core-provided starter content using add_theme_support() – let’s look at a breakdown of how Twenty Seventeen does things. In its setup function hooked to after_setup_theme, we see an array with collections of widgets, posts (pages), attachments, options, theme mods, and nav menus registered as the starter content. The customizer looks for this starter-content at after_setup_theme priority 100, so do make this call at that point or later:

add_theme_support( 'starter-content', array( /*...*/ ) )


Each widget area ID corresponds to one sidebar registered by the theme, with the contents of each widget area array being a list of widget “symbols” that reference core-registered widget configurations. Most default widgets are available (archives, calendar, categories, meta, recent-comments, recent-posts, and search), as well as text widgets with business hours (text_business_info) and a short prompt for an “about this site” style blurb (text_about). Themes should place widgets based on what works best in that area – for instance, business info in a footer widget of a business-centric theme, or a nicely styled calendar widget in the sidebar of a blog.

Custom widgets can also be registered at the time of starter content registration or later filtered in, which will be more likely the case for plugins, as add_theme_support() for starter content will be overridden by any later calls.

// Custom registration example
add_theme_support( 'starter-content', array(
	'widgets' => array(
		'sidebar-1' => array(
			'meta_custom' => array( 'meta', array(
				'title' => 'Pre-hydrated meta widget.',
			) ),

// Plugin widget added using filters
function myprefix_starter_content_add_widget( $content, $config ) {
	if ( isset( $content['widgets']['sidebar-1'] ) ) {
		$content['widgets']['sidebar-1']['a_custom_widget'] = array(
			'my_custom_widget', array(
				'title' => 'A Special Plugin Widget',
	return $content;
add_filter( 'get_theme_starter_content', 'myprefix_starter_content_add_widget', 10, 2 );

Posts (Pages)

Like widgets, core provides posts which can be referenced by symbols; all six currently in the core set are pages, but the starter content API can support various post types (including attachments, which are defined and handled separately). The symbols for the core-provided pages as of 4.7 are home, about, contact, blog, news, and homepage-section. The pages references by blog and news are both empty in the content area and are meant to be assigned as the page for posts (detailed with options below). Imported posts can further be used as post IDs when referenced using the symbol of the item within double curly braces, e.g. {{home}} for the static front page option.

Posts, like widgets, are also easily customizable, either by overriding specific fields for a predefined item or by defining a new custom one entirely. The available fields are post_type, post_title, post_excerpt, post_name (slug), post_content, menu_order, comment_status, thumbnail (featured image ID), and template (page template name, as would be stored in post meta).

// Overriding/supplementing a predefined item plus a custom definition
add_theme_support( 'starter-content', array(
	'posts' => array(
		'about' => array(
			// Use a page template with the predefined about page
			'template' => 'sample-page-template.php',
		'custom' => array(
			'post_type' => 'post',
			'post_title' => 'Custom Post',
			'thumbnail' => '{{featured-image-logo}}',


While attachments are post objects, they have special handling due to the sideloading of specified media. Media must be loaded from within the theme or plugin directory – external URLs are currently disallowed for performance reasons. The location of the media, either as a full file path or relative to the theme root, is indicated in the file array item, and some other post fields are available, with post_content mapping to description and post_excerpt to caption. Imported attachments can further be used by using their respective array keys as symbols used within double curly braces, e.g. {{featured-image-logo}} as the featured image (thumbnail) for a post. In the example below, an attachment is specified and used as the featured image for the about page.

add_theme_support( 'starter-content', array(
	'attachments' => array(
		'featured-image-logo' => array(
			'post_title' => 'Featured Logo',
			'post_content' => 'Attachment Description',
			'post_excerpt' => 'Attachment Caption',
			'file' => 'assets/images/featured-logo.jpg',
	'posts' => array(
		'about' => array(
			// Use the above featured image with the predefined about page
			'thumbnail' => '{{featured-image-logo}}',

Nav Menus

Nav menus are also specially treated post objects. There are essentially two types of nav menu items – custom links, which require a title and url, and object references, which require type, object, and object_id, which can be a {{post}} symbolic reference.

Options and Theme Mods

Options and theme mods are more freeform and merely require a match for a name. Symbolic references to imported items are particularly useful here, such as for the page_on_front option and Twenty Seventeen’s multi-section homepage as stored in theme mods. Themes hosted on .org will likely be limited to theme mods and a subset of options; all other developers are encouraged to consider user experience and expectations first.

What does this mean for themes?

Core-provided content helps support a consistent preview experience across themes with high quality localized content, helping users understand how WordPress and that theme fit their needs. Theme authors are encouraged to select from core-provided content, but as is always the case with WordPress, starter content still has some flexibility, and will continue to mature as a feature over time.

While theme review guidelines need to be finalized and documented, it is anticipated that themes being submitted to will be expected to select from core-provided content to promote consistency and to help keep the theme review process from becoming lengthier, with exceptions being made on a case by case basis. Themes being distributed outside of are not subject to the same review process; however, it is recommended that consistent user experiences be the primary consideration in how starter content is chosen and implemented.

What’s next?

Testing this feature with your theme or plugin does not require a fresh install every time – you can set the fresh_site option to 1 using the tool of your choice, such as wp-cli or phpMyAdmin. Do note that content merging logic has not been tackled so you may not quite get the exact same effect as a truly fresh install; however, since all of the changes are held in a customizer changeset and are not otherwise live on the site, there is no data loss, unless you save and publish the starter content overrides of course.

In the future, all sites should be able to live preview new themes in ways that really showcase that theme’s capabilities, whether that’s with no content made yet or with a lot of existing content to work into the preview. This will take a lot of consideration around user expectations for content merging, and should be tackled as its own feature. There are also potentially interesting extensions such as UI for users to select from sets of content or selectively accept/reject staged changes.

And finally, to best align preview experiences in various places, theme previews on .org should also leverage starter content. Helping hands are needed here – please ping me (@helen) in Slack should you be interested!

#4-7, #dev-notes

Week in Core, November 23 – 29, 2016

Welcome back the latest issue of Week in Core, covering changes [39341-39379]. Here are the highlights:

  • 39 commits
  • 30 contributors
  • 81 tickets created
  • 3 tickets reopened
  • 31 tickets closed

Ticket numbers based on trac timeline for the period above. The following is a summary of commits, organized by component.

Code Changes

Build/Test Tools

  • Build: Remove fsevents from npm-shrinkwrap.json [39368] #38657
  • Add an extra WP_Error assertion when testing a valid user activation key. This provides a better failure message if the assertion does fail. [39364] #38716
  • When testing the output of wp_list_pages(), use a known and fixed date for each post so the tests don’t fail when the date changes between the beginning and end of a test. [39363] #38688
  • Git: Prevent untracked files from being ignored by git in bundled themes. [39362] #27207, #38779
  • Add npm-shrinkwrap.json to 4.7. [39358] #38657

Bundled Theme

  • Twenty Seventeen: Add textdomain for starter content attachment titles. [39374-39373] #38981
  • Twenty Seventeen: Ensure edit button label displays properly in other languages [39341] #38876


  • Fix regression in ability to hide fields for advanced menu properties in nav menu item controls. [39379-39378] #34391, #38952
  • Fix regression in ability to create submenus for nav menus via drag and drop. [39377-39376] #34391, #38948
  • Fix logic for previewing the URL for nav_menu_item settings for terms and post type archives. [39365] #38114, #38945
  • Refactor logic for updating custom_css posts by introducing wp_update_custom_css_post() function and renaming update filter. [39350] #35395, #38672
  • Clean up docs and code style for customize changes in 4.7. [39345] #37770, #38908


  • Correctly remove security attribute from iframes in IE 10 and IE 11. [39347] #38694


  • Git: Ignore patch related files, so they can’t be accidentally committed. [39361] #38727
  • SVN: Ignore patch related files, so they can’t be accidentally committed. [39360] #38727
  • Docs: Add a missing changelog entry for the point where the $tagnames parameter was added to get_shortcode_regex(). [39351] #38914



  • WP_Hook: Re-initialize any actions added directly to $wp_filter by advanced-cache.php. [39370-39369] #38929


  • Add test for creating a comment with an invalid post ID. [39375] #38816, #38991
  • Add tests for empty or “no-op” updates. [39371] #38700, #38975
  • Special case the “standard” post format to always be allowed. [39353] #38916
  • Allow unsetting a post’s password. [39352] #38919
  • Add support for comments of password-protected posts. [39349] #38692
  • Always fire the rest_insert_* actions after the related object is updated or inserted. [39348] #38905
  • Make JS Client store schema in session storage. [39344] #38895
  • Allow unsetting of page templates in update requests. [39343] #38877
  • Update “resource” strings to use the appropriate nouns. [39342] #38811


  • Fix logic for previewing the URL for nav_menu_item settings for terms and post type archives. [39366] #38114, #38945
  • Theme starter content: Add support for featured images and page templates. [39346] #38615


  • Fix the styling of notices generated by the editor UI. [39367] #38917

Thanks to @mor10, @adamsilverstein, @afercia, @azaozz, @celloexpressions, @danielbachhuber, @davidakennedy, @dd32, @delawski, @DrewAPicture, @flixos90, @georgestephanis, @helen, @iseulde, @jnylen0, @joehoyl, @joehoyle, @johnbillion, @karmatosed, @keesiemeijer, @lucasstark, @nacin, @ocean90, @odysseygate, @pento, @rachelbaker, @ramiy, @swissspidy, @tg29359, @westonruter, and @xrm for their contributions!

#4-7, #week-in-core

Week in Core, November 15 – 22, 2016

Welcome back the latest issue of Week in Core, covering changes [39233-39340]. Here are the highlights:

  • 108 commits
  • 53 contributors
  • 114 tickets created
  • 16 tickets reopened
  • 101 tickets closed

Ticket numbers based on trac timeline for the period above. The following is a summary of commits, organized by component.

Code Changes

Bundled Theme

  • Twenty Seventeen: CSS coding standards [39340] #38901
  • Twenty Seventeen: Ensure galleries display correctly in IE11. [39339] #38872
  • Twenty Seventeen: Avoid an undefined index notice after [39291]. [39317] #38847
  • Twenty Seventeen: Adds background-attachment: fixed; to devices that should support it [39297] #38395
  • Twenty Seventeen: Ensure the use of proper image size for custom header image [39291] #38847
  • Twenty Seventeen: Remove some extraneous function calls. [39286] #38848
  • Twenty Seventeen: Additional default header image optimizations. [39279] #38793
  • Twenty Seventeen: Add styles for custom header video controls. [39273] #38697
  • Twenty Seventeen: Compress the default header image. [39248] #38793


  • REST API: On Comment create, limit the ability to set the author_ip value directly. [39302] #38819
  • REST API: Change “ipv4” types to “ip” to support ipv6. [39296] #38818
  • REST API: Remove the karma property and query parameter from the Comments endpoints. [39292] #38821
  • REST API: On comment create, return an error if the type property is set to anything other than comment. [39290] #38820
  • REST API: On comment create, return an error if the post parameter does not relate to a valid WP_Post object. [39288] #38816
  • REST API: On comment create, fallback to the user_agent header value. [39287] #38817
  • Query used to fill comment descendants should reset ‘offset’ and ‘number’ params. [39274] #37696


  • Prevent selective refresh from causing infinite fallback refreshes when nav menu contains invalid items. [39333] #38890
  • Remove iframe-specific behaviors from customize preview when previewing on frontend and not contained inside iframe. [39332] #30937, #38867
  • Ensure that WP_Customize_Manager::save_changeset_post() returns setting_validities even for supplied values that are unchanged from values in changeset. [39320] #38705, #30937, #38865
  • Ensure WP_Customize_Setting::value() returns previewed value for custom types utilizing the customize_value_{$id_base} filter. [39318] #38864
  • Autoprefixer for [39249]. [39301] #29158
  • Remove obsolete edit shortcut style rules from Twenty Seventeen. [39285] #38776
  • Ensure Close button actually closes customizer (instead of going back) after switching to a different theme inside a customize-loader iframe. [39271] #38833
  • Prevent edit shortcut buttons from being inserted into container elements in the head or into elements which should not get interactive children. [39270] #27403, #38672, #38830
  • Allow URL for Codex link in Additional CSS section to be translated. [39268] #35395, #38823
  • More visible focus and hover states for close and back buttons. [39249] #29158
  • Ensure edit shortcuts have same background color regardless of theme colors. [39243] #38776
  • Add !important line-height to edit shortcut buttons. [39242] #38787
  • Allow starter content to apply in a new theme when switching from another theme containing changes. [39241] #38114, #38541
  • Only show video header controls if previewing front page; show explanatory notice when controls are hidden. [39237] #38796, #38778
  • Adjust layout for edit shortcuts only when shown. [39233] #38651


  • Add support for LIKE-escaped tables in ::get_table_from_query(). [39275] #38751



  • Plugin install: De-duplicate a conditional, introduced in [38172]. [39336] #38190
  • Docs: Use 3-digit, x.x.x style semantic versioning for @since 4.7.0 entries. [39281] #37770
  • Tests: Add a missing $message argument for assertEquals() in [39265]. [39267] #23626
  • Tests: Use assertEquals()‘ native functionality for delta comparison in test_wp_convert_bytes_to_hr(). [39265] #23626


  • In wp_dropdown_languages() rename the new show_site_locale_default argument to show_option_site_default. [39331] #38632, #38871
  • Add an additional caching layer for _load_textdomain_just_in_time(). [39330] #37997
  • Introduce more translator comments for strings that contain placeholders but don’t have an accompanying translator comment. [39326] #38882
  • Move the support forums URL in update-related HTTP API error messages to a separate translatable string that is already used elsewhere. [39325] #38880
  • Remove an erroneous @TODO introduced in [39323]. [39324] #38882
  • Begin introducing translator comments for strings which include placeholders but no accompanying translator comment. [39323] #38882
  • REST API: Merge two error messages for edit / update. [39322] #38879
  • REST API: Update error messages in WP_REST_Comments_Controller to use the common text for permission errors. [39321] #38875
  • Use ‘WordPress hook name’ instead of ‘PHP hook name’ in translator comments added in [39315]. [39316] #38862
  • Add translator comments for strings in _deprecated_*() functions. [39315] #38862
  • Remove unnecessary __() calls in _rotate_image_resource() and _flip_image_resource(). [39314] #38862
  • REST API: Merge some more permission error strings missed in [39309]. [39313] #38857
  • Text Changes: Merge strings referring to list_users capability. [39312] #38857
  • Merge two ‘RSS Error:’ strings. [39311] #38861
  • REST API: After [39306], move author_ip argument to the correct place. [39310] #38822
  • REST API: Merge and clarify some permission error strings. [39309] #38857
  • Text Changes: Merge and clarify some permission error strings in the admin. [39308] #38857
  • Merge two ‘ERROR:’ strings. [39307] #38860
  • REST API: After [39302], clarify author_ip parameter in error message. [39306] #38822
  • REST API: Merge two similar permission error strings in class-wp-rest-comments-controller.php. [39305] #38857
  • REST API: Merge two similar permission error strings. [39304] #38857
  • REST API: Clarify parameters when used in error strings. [39298] #38822
  • REST API: After [39252] and [39264], uppercase some more ‘ID’ references in translatable strings. [39266] #38791
  • REST API: Uppercase ‘ID’ in endpoint descriptions and error messages for consistency with other strings. [39264] #38791
  • REST API: Unify some more permission error messages. [39259] #38803
  • REST API: Unify permission error messages. [39257] #38803
  • Remove “ tags from translatable strings in wp-includes/class-wp-customize-manager.php. [39254] #38802
  • REST API: Remove two duplicate strings, use the ones we already have. [39252] #38791
  • REST API: Unify permission error messages. [39251] #38791, #34521
  • REST API: After [39238] and [39239], move the remaining translator comments to preceding line. [39245] #38791
  • Docs: Apply documentation standards to the new get_available_languages filter. [39244] #38788
  • REST API: Move translator comments to preceding line. [39239] #38791
  • REST API: Add translator comments to text with placeholders. [39238] #38791
  • Add the get_available_languages filter. [39235] #38788



  • REST API: Check read permissions on posts when viewing comments. [39295]
  • Small coding standards cleanup of wp-custom-header.js. [39277]
  • Post-4.7 beta 4 bump. [39263]
  • WordPress 4.7 Beta 4. [39262]

Options, Meta APIs

  • REST API: Update description strings to match already existing ones in the admin. [39335] #38807

Posts, Post Types

  • Accessibility: Improve the Post Attributes meta box fields labels. [39247] #38790
  • Improve sanitisation of templates’ post types. [39236] #38766


  • Set the comment type to a readonly property in the schema. [39337] #38820, #38886
  • Trim trailing slashes from routes. [39329] #38873
  • Correctly map meta keys to field names. [39328] #38786
  • Disable anonymous commenting by default. [39327] #38855
  • Add test case for users/me endpoint that the context param defaults to view. [39293] #38842
  • Allow parent property to be explicitly set to 0 when creating or updating a Post. [39289] #38852
  • Clean up argument and property types. [39250] #38792


  • Update register_taxonomy hook to use WP_Taxonomy object. [39283] #38765
  • Prevent wp_list_categories() from producing not well-nested output if hide_title_if_empty is true. [39280] #38839, #33460

Text Changes

  • Merge some duplicate strings with the same meaning in error messages, adjust some other strings for consistency and accuracy. [39278] #38808
  • Unify permission error messages in wp-admin/users.php. [39258] #38804
  • Unify permission error message in wp-ajax-response.js. [39253] #34521


  • Prevent unneeded database updates in wp_get_custom_css_post(). [39338] #38866
  • Twenty Seventeen: Make all Codex links in DocBlocks use HTTPS [39300] #38854
  • Twenty Seventeen: Rename the starter content menus to match the menu area names. [39294] #38615
  • Improve a11y and extendability of custom video headers. [39272] #38678
  • Theme starter content: Add reference IDs for most default widgets. [39261] #38615
  • Theme starter content: Refine the content for pages. [39260] #38615
  • Theme starter content: Add more social link items to select from. [39256] #38615
  • Theme starter content: Revamp the credits widget into an about widget. [39255] #38615
  • Remove front page restriction from video header functions. [39240] #38738
  • Customize: Use video-specific labels for buttons in Header Video media control. [39234] #38172


  • Avoid calling editor.focus() on loading the content in the editor. It may trigger scroll-into-view in the browser. Call the quirks fix in TinyMCE directly. [39334] #38511
  • Fix automatic scroll on page load. [39299] #38511
  • Remove extra space in tooltip. [39284] #38063
  • Tews: fix Firefox issues. [39282] #36434, #38511



Thanks to @adamsilverstein, @afercia, @andy, @azaozz, @boonebgorges, @bradyvercher, @celloexpressions, @chesio, @ChrisWiegman, @danielbachhuber, @davidakennedy, @dd32, @derrickkoo, @dimadin, @flixos90, @folletto, @gitlost, @helen, @iseulde, @jnylen0, @joehoyle, @joemcgill, @johnbillion, @johnpgreen, @jrf, @laurelfulford, @lucasstark, @lukecavanagh, @markoheijnen, @melchoyce, @mikeschroder, @netweb, @ocean90, @odysseygate, @pento, @peterwilsoncc, @Presskopp, @rachelbaker, @ramiy, @rianrietveld, @rmccue, @schlessera, @SergeyBiryukov, @sharkomatic, @sirbrillig, @sstoqnov, @swissspidy, @tharsheblows, @timmyc, @transl8or, @welcher, @westonruter, and @yoavf for their contributions!

#4-7, #week-in-core

Dev Chat Summary: November 16 (4.7 week 13)

This post summarizes the dev chat meeting from November 16th (agendaSlack archive).


  • Dev Chat timing: Weekly chat has been moved to 21:00 UTC.
  • Schedule: Thursday, November 17th is the target for RC! RC means the list of tickets should be at zero (with the exception of the about page), as a release candidate is supposed to represent software you believe you can release. It is currently at 24.
  • Tickets:For any tickets you’ve moved into the milestone, please get these resolved in the next day.
  • Dev Notes: These should all be published this week, with a collective Field Guide forthcoming from @jorbin.

Dev Notes / Field Guide for 4.7

  • There are a few outstanding Dev Notes, but it’s getting close. We’re waiting on the Customize summary from @celloexpressions, Media summary from @joemcgill, Starter Content from @helen, and @davidakennedy is finishing up one on Twenty Seventeen.
    • Media summary is ready to publish, was just waiting on the PDF post from Tuesday, November 15th.
    • Video Headers post could be done by @bradyvercher, but @joemcgill own making sure it happens
  • @jorbin started drafting the Field Guide, but he’s going to need to hand off finishing it off since he will be offline starting Thursday, November 17th for a week.
    • @adamsilverstein and @jbpaul17 will work to finish things up
    • @jorbin to coordinate with Adam and Jeff to sure the remaining tasks are sorted out
    • @ipstenu happy to proofread for typos and grammar.
  • @jorbin also started the discussion to ensure the email to plugin devs goes out after the Field Guide is published.  That’s a collaboration with the meta team and the pluginsrepo team.

Release Candidate

  • @helen (thankfully) was able to move RC back from Tuesday, November 15th to Thursday, November 17th.
  • However, we’ve got 23 tickets hanging out in the report, 22 of which need to be resolved or punted in order to reach RC.
  • [Bug Scrub of remaining 4.7 tickets proceeded]

#4-7, #dev-chat, #summary

Dev Chat Summary: November 9 (4.7 week 12)

This post summarizes the dev chat meeting from November 9th (Slack archive).


  • Dev Chat timing: The Chat remains at 20:00 UTC.  Daylight Savings Time means that 20:00 UTC may be a different time for you already, or it may be a different time soon. However, next week we will be at 21:00 UTC.
  • Schedule: Today is the target for Beta 3! That leaves us one week until the Release Candidate, where the list of tickets must be at zero. It is currently at 32, down from 74 last week.
  • Tickets: For any tickets you’ve moved into the milestone, please make sure these are active tickets, with some kind of activity every day.
  • Bug Scrubs: @Helen is running regular scrubs this week.
  • Dev Notes:  These will be compiled into the field guide this weekend.

Bug Scrubs

  • Would like to see near daily scrubs for now until RC of report 6 and of the “Defects Awaiting Review, reported against trunk” section of report 40
  • @helen, @jorbin, and @jbpaul17 are all trying to run scrubs just about everyday, but everyone should also be scrubbing
  • Media, REST API, and Customizer component teams are all actively running scrubs as well

Dev Notes / Field Guide for 4.7

Beta 3

  • Likely to go out on Thursday morning instead of today, although given time zones and such we should operate on “it’s happening today” anyway
  • We are at 32 open tickets. Would love to see us get down to 20.
  • Work/tickets that folks would ideally like to resolve for Beta 3:
    • #38522: HTTP Errors on Upload with Certain PDFs
    • #38726: REST API: `unfiltered_html` and slashing: terms
    • #38672: Custom CSS should work with existing Jetpack custom CSS
    • #38541: Allow starter content to apply in a new theme when switching from another theme containing changes
    • #38660: Customizer: Edit shortcuts buttons: consider to don’t use flexbox
    • #38700: REST API: Cannot send an empty or no-op comment update
    • #38720: REST API: Updating a comment without sending content is valid, but unsupported
    • Starter content
    • Video headers

Release Candidate

  • Please remember that with RC comes string freeze, so if you have any strings you think need to freeze, now is the time to get them in
  • We should be closing 4-5 tickets a day in order to hit RC on Tuesday.
  • Please keep testing, and working on patches.

#4-7, #dev-chat, #summary

Dev Chat Summary: November 2 (4.7 week 11)

This post summarizes the dev chat meeting from November 2nd (agendaSlack archive).


  • Dev Chat timing: The Chat remains at 20:00 UTC.  Daylight Savings Time means that 20:00 UTC may be a different time for you already, or it may be a different time soon.
  • Schedule: Today is the target for Beta 2! That leaves us one week until the final scheduled beta, where the list of tickets should be at zero. It is currently at 74.
  • Tickets: For any tickets you’ve moved into the milestone, please make sure these are active tickets, with some kind of activity in the last 7 days.
  • Bug Scrubs: Can you run a scrub to help ensure tickets move forward? If you have interest in helping run a scrub and ensure tickets land in 4.7, then please reach out to @jbpaul17 or @jorbin and we’ll find a time that works best for you.

Beta 1 Testing Updates

  • Forums-wise, an unresolved Twenty Seventeen issue that may be user error, the rest were either confirmed user error or filed in Trac
  • A couple customizer defects reported, one regarding infinite refresh and another one that relates to content security policy and Firefox which needs more reporter feedback since it is not reproducible by me. Also the edit shortcuts still have unresolved issues and maybe even need some UI changes to improve discoverability.

Remaining 4.7 Schedule

  • Beta 2 later today. Beta 3 in a week.
  • RC comes 6 days after that – the reason for RC being on a Tuesday instead of Wednesday is because of php[world] for @Helen (will be keynoting).
  • The goal is for RC to be much closer to a traditional RC (i.e. something finished and polished).  This means the final Beta should be where we are at zero open tickets besides possibly the About page.
  • An RC really should represent the state in which we believe the software could be shipped
  • The week after that is US Thanksgiving – we have the option of another RC if needed, but there may be lower activity volume as people travel and have obligations, etc.
  • Note that to ship an RC we have to be at zero tickets, though, which is less than 2 weeks away.
  • Would very much like to be able to have a video ready before WCUS (@Helen has vague outline, looking for help outside of the usual WP suspects)
  • Then the week after that is WCUS – again, have the option of another RC if needed, and we should hit string freeze at that time at the latest, as many people will be traveling for WCUS.
  • Then, release on December 6.

Dev Posts / Field Guide for 4.7

Bug Scrubs

  • Would like to see near daily scrubs for now until RC of report 6 and of the “Defects Awaiting Review, reported against trunk” section of report 40
  • It looks like 11AM and 2PM Eastern should work each day
  • Would love to see a European and/or Australian also do some during non-USA centric times
  • We should have some scheduled stuff for people to show up if they need to schedule their time, but if you’re around and going through the report, throw up a here or another bat signal and just do one ad hoc.

Beta 2

  • What needs to be done to get this out the door?
  • Likely to go out on Thursday instead of today
  • We are at 71 open tickets. Would love to see us get down to at least 40.
  • generally there are still enhancements (polish) going in for new features.
  • Since a lot about the REST API is about developer experiences, polishing the developer experience seems like a perfectly good thing to be doing during beta.
  • Whether it’s a bug or an enhancement in your eyes is not the important criterion – it’s about whether it’s a part of what you believe a polished set of REST API endpoints should be when you ship them.
  • Tickets to folks would ideally like to resolve for Beta 2:
    • #37032: Guard against infinite reload when setting change causes premature selective refresh
    • #38543: Twenty Seventeen: Firefox 49 renders site name & description off screen.
    • #38532: Customizer: Edit shortcuts buttons: clicking does not work in Firefox
    • #29158: Customizer UI Design lacks contrast for visual hierarchy and does not match wp-admin
    • #38420: API Post status parameter does not accept multiple values
    • #38609: REST API should honor the `unfiltered_html` capability
    • GitHub Issue #2848: Avoid use of wp_filter_post_kses to prevent lossy slash handling
  • Additional items needed for Beta 2 are a news post for .org and a haiku

#4-7, #dev-chat, #summary