Technical organisation post-5.0

Once WordPress 5.0 is released, the intention is to have a minor WordPress release twice a month. These releases will be focused on editor improvements and bug fixes. They can also include bug fixes beyond the editor.


Work on the editor will continue on GitHub, while work on WordPress Core will continue in Trac. The JavaScript packages from GitHub, which represent more than just Gutenberg code, will be updated on a regular basis and merged into WordPress Core.

A typical Workflow for a Core bug fix involving a JavaScript package will follow this process:

  1. A Trac ticket is created to track the bug resolution.
  2. If the issue is found to be related to a JavaScript package, a corresponding GitHub issue is created referencing the Trac ticket.
  3. The issue is resolved in a GitHub pull request and merged to master.

Then, on a regular basis, the Editor Team will:

  1. Publish updates to the WordPress npm packages from the Gutenberg repository.
  2. Update the packages in Core.
  3. Close the Trac tickets fixed by the packages update.

In addition to the editor improvements, prototypes, and implementation of Phase 2 work will also happen in the GitHub repository. We will use feature flags to avoid including the Phase 2 work in the WordPress Core package updates. This will allow us to continue using the Gutenberg plugin releases for beta testing.

Deprecation policy for JavaScript APIs

There hasn’t been a decision made yet on the process for deprecating JavaScript APIs. Discussions around a comprehensive deprecation policy have started in #core-js. Some ideas around script versioning and more prominent deprecation notices will be explored. Once those discussions have a clear outcome a post will be made to this blog (Core P2).

During the plugin phase, the deprecation strategy of the Gutenberg APIs went through several iterations:

  • In the early days, all the APIs were considered experimental, which meant that there were no expectation of backward compatibility between plugin releases.
  • Once the plugin became more stable and widely used, we started ensuring backward compatibility for all the APIs for at least 2 versions of the plugin.

This strategy won’t be applied in Core because it’s very important that we continue to maintain the user trust with auto-updates and there’s no intention in changing that in the future.

That said, maintaining backward compatibility for JavaScript APIs has costs. It’s impactful and it can harm the user experience. Maintaining APIs indefinitely is not a reasonable approach as we can’t keep loading more kilobytes of JavaScript as we add new APIs and support old ones.

If you have thoughts on the subject, please join the discussions in the #core-js Slack Channel and share your ideas during our weekly meetings (Each Tuesday at 14h/2pm UTC).


Classic Editor Plugin Support Window

The Gutenberg project is a fundamental shift for WordPress. We recognise that there will be a transition period as everyone adjusts to building plugins, themes, and sites using these new tools. To ease the transition for businesses and entrepreneurs, it’s been mentioned that the Classic Editor plugin would be maintained into the future. To give everyone more clarity on how long that’s likely to be, we’d like to add a date to how long the Classic Editor plugin will be supported.

The Classic Editor plugin will be officially supported until December 31, 2021.

During that time we will make sure that Gutenberg works seamlessly with existing WordPress infrastructure. That could include tools for testing and updating code, tutorials and additional documentation, or new compatibility layers. What is eventually created will be based on community feedback.

Since the Classic Editor plugin is central in this transition, we are considering including it with upgrades to WordPress 5.0. New WordPress installs would still add it manually, and we’ve included it in the Featured Plugins list to increase visibility. If you have thoughts on this idea, please leave a comment.


  • What does “officially supported” mean? It will be guaranteed to work as expected in the most recent major release of WordPress, and the major release before it.
  • Can this date be extended? In 2021 we will evaluate continuing maintenance of the plugin, based on usage. We expect continued maintenance to be fairly trivial.
  • Will other fallbacks (for example, Custom Post Types, or Meta Boxes) work in Core for the next three years? While it will still be possible for CPTs and Meta Boxes to be marked incompatible with the block editor, future WordPress releases will move this functionality to the Classic Editor plugin. When this happens, WordPress will recommend that site owners install and activate the Classic Editor plugin when a fallback is triggered.

#5-0, #classic-editor

5.0 / Gutenberg Status Update – Nov 13

Current open PRs for review: 44 in 4.4 Milestones (+9)
Current open issues milestoned RC: 148 (-14)
Current open issues milestoned 5.0.0: 3 (+1)
Current open issues milestoned 5.0.1: 2
Current open issues milestoned 5.0.x (fast follow): 19 (+4)
Current beta: Beta 4, released today.
Current plugin: 4.3, released yesterday.
Next beta: Beta 5, planned for Thursday.

Note: this is a daily update on progress towards WordPress 5.0, as outlined in this post. This status update is also shared in the #core-editor channel in Slack.

What’s new in Gutenberg? (12th November)

This update gathers a big number of fixes and improvements. It also completes many accessibility tasks — the original milestone for blockers is now closed.

Version 4.3 is fully released and Beta 4 will be coming later in the day.

Showing integration with the 2019 theme

4.3 / WordPress 5.0 (Beta 4) 🐺

Bug Fixes

Other Changes



Mobile Apps

Deprecations removed with this version.

Status Update

  • Current PRs for review: 35 in 4.4 Milestone.
  • Open issues in 5.0 RC: 162.
  • Open issues in 5.0.0: 2.
  • Open issues in 5.0.1: 2.
  • Open issues in 5.0.x (fast follow): 15.
  • Current beta: Beta 3, November 5.
  • Current plugin: 4.3, released today.
  • Next beta: Beta 4, planned for today.

#core-editor, #editor, #gutenberg

Dev Chat Agenda: November 14th (5.0 Week 7)

This is the agenda for the weekly devchat meeting on November 14th, 2018 at 21:00 UTC:

  • 5.0 Planning and Updates
  • 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 those listed above, please leave a comment below. Either way, we look forward to seeing you at the devchat this week!

This meeting is held in the #core channel in the Making WordPress Slack.

#5-0, #agenda, #core, #dev-chat

Introducing Twenty Nineteen

Gutenberg grants users an unprecedented level of freedom to customize their site’s layout and design. In order to fully achieve their vision, users will need a new generation of flexible themes, built to take advantage of the creative freedom that Gutenberg offers.

With that in mind, WordPress 5.0 will launch with a brand new default theme: Twenty Nineteen. The theme will be led by @allancole, supported by @kjellr as a design coach.

Twenty Nineteen Theme, Blog Post Example
Twenty Nineteen Theme, Homepage Example

Full page mockups: Low-resHigh-res
InVision prototypes: Post Desktop, Post Mobile, Homepage Desktop, Homepage Mobile

At the core of Twenty Nineteen is its simple, sophisticated typography. The theme’s aesthetic is minimal and non-prescriptive, allowing the theme to work well in a variety of applications. For example: it is effective as an minimal, typography-driven blogging theme, but can also be adapted for use as a static business website.

Twenty Nineteen will ship with full Gutenberg support. It will include both front and back-end styles, so that users can be fully confident in their site’s appearance when they hit publish.

Twenty Nineteen Theme, Gutenberg Editor Styles Mockup


As mentioned in the release plan, WordPress 5.0 will be released on November 19th, 2018, so this is a faster-than-usual theme build. The first release candidate is estimated for the end of October, so we’ll want to have a working version of the theme ready by then. Because of time limitations we may remove Twenty Nineteen from 5.0 if it is not ready in time for launch.

Get Involved

If you are interested in contributing, please be sure to follow this blog. During the design and development process, there will be weekly half-hour meetings every Tuesday at 16:00 UTC in #core-themes, beginning today, October 16, 2018.

Theme development will happen on GitHub and in the interest of time, an in-progress version of the theme code has been uploaded here: Once the theme is stable, it will be merged into core and the GitHub repo will be depreciated.

Some notes:

  • The theme is based on both _s and the gutenberg-starter-theme.
  • SASS is used in some key areas which has been helpful for keeping styles in-sync between the Gutenberg editor, and the front-end experience. This is not usual for a default theme and open to debate.
  • There is plenty of work left to do too and issues will be created in the coming days to help guide the process.

Learn more

If you’re interested in learning more about default themes, you can read the following posts:

Update on 5.0 Release Schedule

As discussed during the Core devchat this week, the initial November 19th target date is looking a bit too soon for a release date. After listening to a lot of feedback — as well as looking at current issues, ongoing pull requests, and general progress — we’re going to take an extra week to make sure everything is fully dialed in and the release date is now targeted for Tuesday, November 27th (within the space that was originally outlined).

Taking a step back, it’s great to see all the progress since the days of the prototypes and how full theme integration, like with the 2019 theme, can make the experience come together…

It has also proven difficult to align plugin releases (and their release candidates) with beta releases of core, process wise, so here’s the outline for the final stretch:

  • Core betas to go out on Monday, November 12th (beta 4) and Thursday, November 15th (beta 5) aligning with plugin releases (4.3 and 4.4).
  • Work to be organized and prioritized around three milestones: 5.0 Release Candidate, 5.0 Launch, 5.0.1, and 5.0.x (planning for +0.0.1 every two weeks following 5.0).
  • 5.0 RC1 targeted for Monday, November 19th.
  • Daily high-level updates on current status (open pull requests to be reviewed, outstanding bugs, etc) in the core-editor channel.

The last part of delivering a project of this scale is always hard and emotions run high. I’d like to take a step back and truly thank everyone for the staggering amount of work, attention, and care being put into preparing this release. I am grateful for the hard work of all contributors — not just those submitting code — including those who have given candid and valuable feedback throughout. It is all helping us move towards a better product.


WordPress 5.0 Schedule Updates

Gutenberg 4.2 (release candidate) has just been released, and we’d like to have a WordPress 5.0 Beta including those updates. Additionally, there are a few more known bugs and tasks to complete in WordPress 5.0, before we can tag a Release Candidate. With that in mind, we feel it’d be prudent to allow for some extra beta time in the WordPress 5.0 schedule.

Beta 2: October 29, 2018

  • Beta 2 included fixes to bugs discovered in Beta 1, an update to the latest version of the block editor, and the Twenty Nineteen theme.
  • Gutenberg 4.2 (RC) was released today, October 30.

Beta 3: November 2, 2018

  • Beta 3 will include updates to the block editor from Gutenberg 4.2, as well as required bug fixes.
  • All Core enhancement tickets must be fixed by this date.
  • This will also be the new soft string freeze date.

Beta 4: November 5, 2018

  • Beta 4 will include bug fixes that come up following Gutenberg 4.2, as well as additional fixes from Gutenberg’s WordPress 5.0 milestone.
  • Assess need for additional beta releases prior to Release Candidate 1.

Release Candidate 1: November 12, 2018

  • All Core bug reports should be fixed by RC1. Release-related task tickets can remain open.
  • The WordPress 5.0 milestone should have low impact or low priority issues remaining, which may be moved to WordPress 5.0.1.
  • This will continue to be the hard string freeze date.
  • There will be additional Release Candidate releases, if needed.

WordPress 5.0: November 19, 2018

  • Final release of WordPress 5.0 will include Gutenberg and all necessary bug fixes.

To answer a few immediate questions:

  • Why the shortened RC period? The block editor has been available for over a year. It’s already had a longer testing period, with 30 times the number of sites using it, than any previous WordPress release. The primary purpose of the beta and release candidate periods is to ensure that it’s been correctly merged into Core.
  • Why so many betas? By adding extra betas we can fix and test iteratively, which will result in a well-polished final release. It also lets the faster cadence of Gutenberg releases continue.
  • What will happen to the Gutenberg releases? Over the past six months, there has been a release every two weeks. We’ll plan to continue that over the first few WordPress 5.0.x releases, to ensure that bug fixes are available as quickly as possible.
  • How soon should we expect WordPress 5.0.1? Approximately two weeks after WordPress 5.0, unless we see bug reports that indicate a need for a faster release.

PHP Meeting Recap – November 5th

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

  • Note that, in order to maintain the original time in most parts of the world after the end of daylight saving time, the meeting time has been adjusted from 15:00 UTC to 16:00 UTC.
  • Due to the focus on Gutenberg and the resulting lack of activity in other areas, this and the following meetings should preferably be used for some “housekeeping”, reviewing the project roadmap and planning the next steps after 5.0.
  • @flixos90 asked to review the Servehappy feature project page, since that has not been updated in a long time. The page would later be updated to reflect some of the additional requirements that came up mid-2018 and to show the currently planned timelines for all features in the project’s scope, plus links to relevant resources and tickets.
  • @afragen brought up #44619 which had not been tagged with the “servehappy” keyword before, mentioning that the ticket is close to ready. @sergeybiryukov pointed out that it should receive design feedback first.
  • @joyously asked about the plans for themes requiring certain PHP versions. While nothing has been developed in this regard yet, themes should eventually be able to specify a minimum required PHP version, just like plugins. This information should be available through the Themes API, and WordPress core should implement techniques to restrict installation, updates and activation of such themes if the requirements are not met, again just how it has been worked on for plugins for the past couple months. However proceeding with this is currently blocked by the lack of theme readme support for, since the minimum requirements should be specified via the readme.
  • The Tide project could in the future be used as an additional means to determine PHP compatibility of plugins and themes.

Next week’s meeting

  • Next meeting will take place on Monday, November 12th, 2018 at 16:00 UTC in #core-php.
  • Agenda: Review future proceedings for the project and refine roadmap and priorities.
  • 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.

#core-php, #php, #servehappy

New! JavaScript i18n support in WordPress 5.0

For years, internationalization (i18n) has been a thing that has been pretty well supported in WordPress when it comes to PHP development. For PHP, WordPress already provides all the tools necessary to make it as easy as possible to localize WordPress core, themes and plugins to any language. Today we are bringing the same capabilities to JavaScript development for WordPress.

How does it work?

When registering your scripts you can add wp-i18n as a dependency to allow you to add translatable strings as you would in PHP:

wp_register_script( 'my-handle', plugins_url( '/js/my-file.js', MY_PLUGIN ), array( 'wp-i18n' ) );

Inside your scripts you will then be able to use wp-18n as follows:

const { __, _x, _n, _nx } = wp.i18n;

__( '__', 'my-domain' );
_x( '_x', '_x_context', 'my-domain' );
_n( '_n_single', '_n_plural', number, 'my-domain' );
_nx( '_nx_single', '_nx_plural', number, '_nx_context', 'my-domain' );

These functions mirror their PHP counterparts and can be used in exactly the same manner.

The final step is to tell WordPress your script contains translations and of which domain, this is to allow WordPress to selectively load only the necessary translations to ensure everything is as fast as can be:

wp_set_script_translations( 'my-handle', 'my-domain' );

Advanced usage

Right now it’s already possible to ship your own translations using the load_textdomain function and passing your own MO file. This is also possible using wp_set_script_translations which accepts an optional third path argument that allows you to tell WordPress to first look elsewhere for translations:

wp_set_script_translations( 'my-handle', 'my-domain', plugins_url( '/languages', MY_PLUGIN ) );

If passed WordPress will first check if a file in the format of ${domain}-${locale}-${handle}.json exists in the given path and use it as the source of translations if so. Alternatively it will also first check the given path for the md5 filename before defaulting to the WordPress languages directory.

If you want to ship your own translation files these should be in the JED 1.x ( .json ) format. GlotPress is able to create these along with other tools such as po2json. Ideally these files should only contain translations that occur within their respective JS files.

Behind the screens

When you upload your plugin or theme to all JS files will automatically be parsed the same as is already being done for PHP files. Any detected translations will be added to to allow the community to cooperate to ensure WordPress, plugins and themes are available in as many languages as possible.

In order to parse all JS files the i18n-command for wp-cli is used. This replaces makepot.php to not only allow picking up translations in JS files but also to audit strings, parse strings only of a specific text domain and even pick up a few strings that weren’t detected by makepot.php. This command is freely available and open-source as makepot.php was and it’s recommended that anyone using makepot.php transition over to this much improved replacement.

Based on these parsed translations Language Packs are generated. Traditionally these used to only contain PO and MO files, one pair for each locale. In order to selectively load only the necessary translations regardless of whether it’s used or not a few more files are being added, one JSON file for every JS file that contains translations per locale.

When parsing JS files for translations we don’t know which handle is used to register that file so we’ve had to use an alternate mechanism to find the translations belonging to each file. To do this we’re using the md5 of the relative path of each file. This is appended to the usual name of ${domain}-${locale} in the form of ${domain}-${locale}-${md5}.json.

When you set script translations for a handle WordPress will automatically figure out the relative md5 hash of your source file, check to see if a translations file exists and if so ensure that it’s loaded into wp.i18n before your script runs.

Plugin and theme support

Translation and Language packs support for plugins and themes that are hosted on the repo is expected in the upcoming weeks. The patches are ready and waiting for commit. Plugin and theme authors are encouraged to start using wp-i18n in their JavaScript projects.


This API wouldn’t have been possible without the long standing efforts of @ocean90, @swissspidy, @nerrad, @atimmer, @schlessera and more recently @herregroen. Thanks a ton for the incredible work you’ve all put into making this a reality! Another thanks to @herregroen for providing the necessary input for this devnote.