What’s new in Gutenberg? (17th August)

The release this week introduces a few significant user experience improvements. The inserter has been tweaked to accommodate new icons for all core blocks (with core embeds showing the icon for the corresponding service), more visual breathing room, and better handling of searches with diacritics. The new icons aim to encourage people creating their own blocks to supply their own SVG—the hope is to make sure we can avoid multiple cases of duplicated icons diminishing the overall ability to quickly scan blocks.

The publishing flow has been updated to show the tag input panel and post format selector before publishing. Previewing should also be a bit more robust in handling the new tab.

A new help modal—showing all available keyboard shortcuts—has also been added. Several shortcuts have been introduced: inserting a new block before / after the current block, toggling the inspector settings, removing a block, and showing said help menu.

Likewise, there are several bug fixes, notably for IE11 users.

Showing the new keyboard shortcuts panel.

3.6 🥒

Deprecations removed with this version.

REST API chat summary: August 9

This post summarizes the REST API component team chat from August 9 (agenda, Slack archive).

5.0 Priorities

The REST API team’s primary goal for the next major release is to support the Gutenberg team. There are still a number of REST API-related issues open in the Gutenberg merge proposal milestone; we always welcome assistance in getting these taken care of.

Issues that were raised as needing eyes and opinions:

  • #44758 (handling user’s locale in REST API responses)
  • #39953 (handling dates on draft posts)
  • gutenberg#8683 and gutenberg#2457 (supporting Gutenberg use with custom controllers and REST routes outside of the wp/v2 namespace)

Outside of Gutenberg, the two major areas of development we aim to tackle are

  • further improvements to the API’s support for meta,
  • and authentication.

Meta Handling

Following the register_meta improvements in 4.9.8, we wish to continue improving the state of meta handling and registration within the REST API.

  • @flixos90 will be re-opening the discussion around how to register complex meta values (e.g. permitting associative arrays instead of just integers, strings and the like). See #43392.
  • #43941 (support default values for registered meta) has clear potential benefits to users and will also be prioritized.
  • @spacedmonkey and others are driving additional tickets which could benefit meta handling, including #44387 & #44238.


We aim to release a tested version of the OAuth 2.0 plugin to the plugin repository by the end of the year. This will greatly assist application developers who wish to integrate their WordPress site with external applications. We are also interested in pursuing a basic auth solution within core (see discussion in #42790).

As @rmccue is currently unavailable to lead development in this area, we are opening a call for a lead contributor to the REST API authentication plugins. We need somebody to own the vision for how external applications should authenticate with WordPress.

Agenda for today’s meeting

The REST API team will be meeting shortly (now, in fact…) in #core-restapi for our regular weekly meeting at 2018-08-16T17:00 UTC. As always, if you have a REST API related ticket you would like to bring to the component team’s attention, please join us or leave a note in the #core-restapi channel. Hope to see you all later today!

PHP Meeting Recap – August 13th

This recap is a summary of our previous PHP meeting. It highlights the ideas and decisions which came up during that meeting, both as a means of documenting and to provide a quick overview for those who were unable to attend.

You can find this meeting’s chat log here.

Chat Summary

  • The content of the Update PHP page was further discussed. There is a Google document available where @alexdenning has been working on revised copy. It is open for comments if you have suggestions.
  • As a reminder, the goal is to shorten the copy by removing unnecessary technical details and thus more positively encouraging the user to update. At the same time, we must not omit that there may be issues and, most importantly, we have to educate about the prerequisite steps necessary to roll back in case a problem occurs that cannot be fixed quickly.
  • As most problems actually need technical assistance to solve, we should not go into too much detail there, but point out that they might want to get help from a developer in such a case. However, basic suggestions as finding a replacement plugin in case a plugin is incompatible should remain, as we still want to encourage users who would be unable or unwilling to hire a third person.
  • At the same time, with the improvements being made in #44458 we can actively encourage the update because, even in case of errors, the site owner will still be able to log in to the site to provide short-term fixes at least.
  • Over the course of the meeting, we made a couple comments on the document with the items we discussed. Please refer to the Google doc linked above for details.
  • We also briefly picked up discussion on visual assets for the page. While that should preferably happen after the copy is in place, it doesn’t hurt thinking about it already, especially since some pieces might be relatively independent of what the final copy will be like. These are ideas we have been considering:
    • Timeline of PHP versions and their end of lifes (dynamic including the passed PHP version, or not)
    • Graphic of the relation between server, PHP, website, WordPress (possibly also including plugins and themes)

Next week’s meeting

  • Next meeting will take place on Monday, August 20th, 2018 at 15:00 UTC in #core-php.
  • Agenda: Further discuss the Update PHP page copy and visual assets to use.
  • If you have suggestions about this but cannot make the meeting, please leave a comment on this post so that we can take them into account.

Javascript Chat Summary – August 14

Below is a summary of the discussion from this week’s JavaScript chat (agenda, Slack transcript).

Have a topic for discussion for the next meeting? Leave a suggested edit on next week’s agenda.

This week we discussed WordPress packages and how to optimize their distribution using npm. As of today, Gutenberg is built of 41 packages where each of them can be used independently by every plugin and theme developer in their projects.

Duplication concerns over independent versioning

Slack Conversation

Problem: An issue was raised about our independent versioning of packages, and how this can lead to duplication which, for packages like data which behave as a singleton, can result in some pretty undesirable outcomes. Related comments on GitHub:


  • This is not specific to @wordpress/data, and could affect anything which behaves in a global / singleton fashion: @wordpress/hooks@wordpress/filters@wordpress/blocks.
  • The issue is mitigated but not eliminated by moving away from Lerna independent versioning (toward fixed versioning) because the chance for differing versions still exists.
  • This shouldn’t be an issue in WordPress context at all. This seems to be an issue for external apps which consume WordPress packages directly from npm.

Decision: Avoid “globals” behavior, where a consumer must define and operate with its own registry (specific to @wordpress/data).

Action items:

How required built-ins should be polyfilled

Slack Conversation

Problem: The current npm packages that being built for Gutenberg polyfill usage of some browser features that are not available on older browsers. This polyfill is global and affects any client who uses WordPress npm packages. This is unexpected and can alter the runtime environment in surprising ways. More details in the related issue.

Decision: corejs flag should be set to false when generating distribution version for packages and set to 2 when bundling with Webpack. In addition, we should inform developers consuming WordPress packages to install proper polyfills on their own.

Guidelines for releases

Slack Conversation

Proposal: We have a documentation proposal to improve guidelines for creating, managing and publishing packages.

Observations: The versioning recommendations are very oriented toward deprecations which seems to be the right approach.

Action item: Add section about managing changelogs based on the discussion from last week.

Dev Chat Agenda: August 15th (4.9.9 Week 1)

This is the agenda for the weekly devchat meeting on August 15, 2018 at 20:00 UTC:

  • 4.9.8 feedback
  • 4.9.9 planning
  • Updates from focus leads and component maintainers
  • General announcements

If you have anything to propose to add to the agenda or specific items related to the above, then please leave a comment below. Either way, we look forward to seeing you at the devchat this week!

#4-9-8, #4-9-9, #agenda, #core, #dev-chat

Dev Chat Summary: August 08, 2018 (4.9.9 Week 1)

This post summarizes the weekly dev chat meeting held Wednesday, August 08, 2018 (agenda | Slack archive).

👉🏼💥 Release Lead Nominations 💥👈🏼

It’s time to select release leads for our 4.9.9 maintenance release. Hooray! If you’d like to nominate someone, or yourself, add a comment to this post. Don’t be shy, y’all.

What does a release lead do? Here are some good resources: 

🔥 Hot Tip 🔥 You don’t have to be an engineer to be a release lead.

4.9.8 Release Feedback

  • Check the goodies in the maintenance release post, if you haven’t.
  • Big thanks to @pbiron, @joshuawold, @sergeybiryukov, @psykro and Mission Control. 🙌🏼
  • @pbiron plans to post a retrospective similar to this in the next week or two.
  • Overall, the Try Gutenberg callout has been effective in getting people to use Gutenberg and find bugs. Active users jumped from 20k to 100k in just a few days. 
  • The support team reports via @clorith things have been pretty quiet since the release. More info inbound on wider areas of focus for support, so stay tuned.
  • There are some reported issues to jump on:

4.9.9 Planning

  • We’re all going proceed as if we’re doing a 4.9.9 maintenance release, so keep working on the growing list of tickets here.
  • However, as of today, we aren’t committed to a 4.9.9 maintenance release. Why?
    • There is not a rush to get a maintenance release the door
    • We don’t have committed leads yet (see above)
    • So far, we don’t have any significant issues from 4.9.8 that require attention

Focus Lead and Component Maintainer Updates


  • The REST API meeting is today – August 9, 2018 – at  17:00 UTC. Welp, this already happened.
  • The key agenda items are: 
    • Prioritize register_meta improvements for 5.0
    • Review API-related Gutenberg tickets
    • Selecting and prioritizing additonal backlog tickets for 5.0



Thank you to all who gave us feedback so far! The feedback is being processed and iterations are underway. 

Open Floor

Post counts on on shared taxonomy terms 

Via @davecpage. There are multiple tickets open related to this:

These are all related to the taxonomy component, and we’ll currently slate them for release in 4.9.9.

General Announcements

Dev Chat Coordination: The Sequel

@jeffpaul is ill and will hopefully return next week. Until he’s at full strength, @joemcgill@audrasjb@antpb and I will continue to run dev chat.

Next Meeting

The next meeting will take place on Wednesday, August 15, at 20:00 UTC in the #core Slack channel. Please drop in with any updates or questions. If you have items to discuss, drop a comment on next week’s agenda post, so we can take them into account.

What’s new in Gutenberg? (9th August)

Another update has sailed! This one comes after WordPress 4.9.8 release with the “try the new editor” notice, which has increased the number of installs from 15k to more than 120k in a few days. This is an important milestone as we broaden the testing horizons. We’d like to take a moment to thank everyone that has tested and given feedback through the various channels.

Likewise, huge thanks to everyone that has helped answer questions, addressed forum feedback, triaged new issues, fixed bugs, and generally jumped in to contribute.

Back to the release, this one includes several fixes, polish, and cleaner interactions around the writing flow. On the developer side, there’s been work around refining and adding to the pool of APIs and documentation.

Showing updates to some UI components.

3.5 🥥

Deprecations removed with this version.

REST API meeting agenda: August 9

We’ve been remiss about posting these, but discussion has been ongoing in #core-restapi over the past few weeks. We’ve seen a lot of discussion of Gutenberg priorities and compatibility issues, and have also been discussing the need for more robust authentication and considering future improvements to register_meta.

This week, the agenda for our scheduled REST API component meeting today (2018-08-09 17:00 UTC) is:

  • register_meta: discuss and prioritize future enhancements
  • Gutenberg: call for volunteers to assist with priority tickets
  • 5.0: Discuss what our component priorities should be leading up to 5.0
  • Open floor / bug triage

As always, if you have a REST API related ticket you would like to bring to the component team’s attention, please join us or leave a note in the #core-restapi channel. Hope to see you all later today!

Dev Chat Agenda: August 8th (4.9.8 Week 6)

This is the agenda for the weekly devchat meeting on Wednesday, August 08 at 20:00 UTC

  • 4.9.8 release feedback and reported issues:
  • 4.9.8 Try Gutenberg Callout feedback 
  • 4.9.9 Discussion and Roadmap (if we need a 4.9.9 release)
  • Gutenberg Announcements
  • Updates from focus leads and component maintainers.
  • General announcements.

Javascript Chat Summary – August 7

Below is a summary of the discussion from this week’s JavaScript chat (agenda, Slack transcript).

Have a topic for discussion for the next meeting? Leave a suggested edit on next week’s agenda.

Automating Publishing to npm

Slack Conversation

Problem: Publishing modules to npm can be difficult because it is not always clear at the time of publishing to what version the package should be updated. The individual performing the publish is not always the same as the contributors who had proposed changes to the package.


  • Adopt conventional commits to enable automatic versioning (pull request)
    • Issue: This is hard to enforce
  • Encourage developers to introduce relevant changelog entries as part of proposed changes. The type of change should indicate versioning requirements.
    • Issue: Not every version bump is caused by directly by new changes, sometimes indirectly by updated dependencies.
    • Issue: Prone to frequent merge conflicts with many developers adding entries to the same text file.

Decision: Encourage developers to introduce changelog entries and evaluate success in a future meeting.

Package Deprecations Versioning

Slack Conversation

Problem: When deprecating a feature in Gutenberg, we add logging to highlight the deprecation, and allow for two minor releases of the plugin before removing the functionality. With this in mind, how do we handle versioning of modules? Following SemVer, the major version should be bumped on backwards-incompatible changes. If the deprecation is not entirely faithful and therefore introduces a breaking change, it results in the need for two separate major version bumps by the removal of a single feature.

Discussion points:

  • Is this really a common use case?
  • Could it be considered a good thing to promote the idea that deprecation “shims” should be fully compatible?
  • How does SemVer consider deprecations?
    • Very specifically: “Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backwards compatible functionality is introduced to the public API. It MUST be incremented if any public API functionality is marked as deprecated.”

Decision: The major version should be bumped on any backwards-incompatible change. This will usually occur at the final removal of the feature. The deprecation should be fully backwards-compatible and, if it is not, it should warrant a separate major version bump.



Slack Conversation

Problem: There are several inconsistencies between the WordPress PHP implementation of add_query_arg and the parallel addQueryArgs from the @wordpress/url package:

Name pluralization: addQueryArgs (JS) vs. add_query_arg (PHP)
Arguments: url, param (JS) vs. param, url (PHP)
Usage: Object only (JS) vs. object or key+value pair (PHP)

Discussion points:

  • Consistency vs. improvements
  • Real-world workflows where developers will expect JavaScript reimplementations to behave the same as their PHP counterpart.
  • In general, we should seek to avoid confusion in appearing similar if in-fact the behaviors are not the same.

Decision: There will be no changes to the name or argument order of the addQueryArgs function. Supporting key and value arguments may be a separate enhancement to consider.

Data Plugins API

Slack Conversation

Announcement: The @wordpress/data module now supports a plugin API. Persistence behaviors, which were previously baked in, are now extracted out to an opt-in plugin. This should help improve isolation of specific behaviors, and allow external consumers to use only specific features relevant for their products.

A new pattern for asynchronous state behaviors has been implemented, distributed as the @wordpress/redux-routine package and integrated with the @wordpress/data module via a new controls plugin.

DOM Ready

Slack Conversation

Announcement: A fix has been backported from the Meta team into the @wordpress/dom-ready package, addressing an issue where callbacks may not be called reliably if the document was in specific states. This was the cause of intermittent white-screen issues on the Gutenberg marketing page.

Open Floor

Usage of wp.api

Slack Conversation

Question: Do we still use wp.api ?

Answer: Only in the (now-deprecated) withAPIData higher-order component. Once this deprecation is complete, there will be no more usage of wp.api and it can be safely removed.