The Block Registration API – status update

Build a directory for discovering blocks, and a way to seamlessly install them is one of the 9 priorities in the 2019 roadmap. This post tries to summarize work done so far and identify all the next steps required to land this project in WordPress core later this year.

It has been over two months since the Meta team published a post intended as a starting point for discussion and new ideas for the Block Directory, and a new type of plugin:

Put briefly, I’d like to propose a new type of WordPress plugin that provides blocks and nothing else: Single Block Plugins. These will be hosted in a separate Block Directory section of the Plugin Directory. They will be JavaScript-based, and each plugin will register a single Block. And they will be searchable and installable from within the Gutenberg editor itself.


Currently, new Gutenberg blocks can be provided by plugins, which often register many blocks, and which are managed from outside the editor. The proposal mentioned above outlines a new type of simple block-based plugin that is intended to be seamlessly installed from within Gutenberg itself. It was later followed up with the call for design on installing blocks from within Gutenberg. There was an essential technical aspect highlighted in the post:

The API will provide an endpoint for searching for blocks by name and description, and return metadata similar to that of plugins. Gutenberg’s Inserter could use that endpoint to also show relevant block plugins that are available to install, with a button and process for seamless installation.


This new endpoint is going to be based on the Block Registration API RFC which intends to address the server-side awareness of blocks and simplify the block discovery for the block directory project. In practical terms, it means that we are seeking for a solution where block type registration is declarative and context-agnostic. Any runtime (PHP, JS, Android, iOS or other) should be able to interpret the basics of a block type and should be able to fetch or retrieve the definitions of the context-specific implementation details.

Core Editor team reached the point where we believe that the Request for Comments is close to being finalized. However, there are still some areas where we feel that other WordPress teams could have a significant impact on the proposal.


The way how translations are handled inside JSON files is something novel for WordPress core. The current proposal for PHP follows the existing get_plugin_data core function which parses the plugin contents to retrieve the plugin’s metadata, and it selectively applies translations dynamically. It would be also similar for JavaScript, with the remark that we plan to implement a custom Babel plugin which would mirror PHP behavior for ESNext code. The transformation would happen during the build step to ensure that files can be statically analyzed before scripts are enqueued. You can find more details in RFC document in the Internationalization section. There is also an issue#15169 opened which describes the technical details of the proposed JavaScript implementation of the Babel plugin.

Core JS team discussed this topic at the end of the weekly meeting on Apr 2nd. We have received great feedback from @swissspidy which helped to shape the proposal. However, we still encourage other Polyglots team members to voice their opinions.

New REST API endpoints

The long term vision for the block discovery in WordPress includes:

  • Fetching the available block types through REST APIs.
  • Fetching block objects from posts through REST APIs.

The proposed implementation for the server-side awareness of block types should ensure that it stays intact with all recommendations that REST API team might have. That’s why we encourage the REST API team to get involved in the process early on. There is no immediate need to start working on new block type related API endpoints. However, it would be great to have it included on the roadmap. Ideally, they should stay as close as possible to the API and the final shape of the endpoint for searching for blocks.

#block-directory, #core-editor, #gutenberg, #i18n, #meta, #rest-api

Media Meeting Recap – May 23, 2019


This post is a summary of the latest weekly Media component meeting, which took place in the #core-media Slack channel, on Thursday, May 23, 2019. The purpose of these meetings are to move priority tasks forward, provide feedback on issues of interest, and review media focused issues. The focus of this meeting, was around the timing of our meeting going forward.

Attendees: @karmatosed @joemcgill @desrosj @mikeschroder @antpb @anevins @sergeybiryukov @pbiron

Transcript: Read on Slack


It was discussed by @desrosj that #46052 would be great to have fixed to 5.2.2. There was discussion around wether or not this issue was a regression due to block editor or not related at all. Worth noting that this is happening also while using the Classic Editor plugin. Investigation is needed still.


Discussion began around the scope of Media for 5.3. There are 47 tickets in the 5.3 milestone. @desrosj mentioned that a few things need to happen to keep the scope manageable. If you have a chance, it would be great to review any tickets assigned to yourself in the 5.3 milestone and decide to punt or future release the issue. As he said,

Everyone should look at the tickets they own in the milestone and determine of the issue is realistic for 5.3. If not, please punt to Future Release (no shame in this!).

If the ticket is realistic, but you have lost interest or are not the best person to own anymore, please just remove yourself as owner.

There are 24 un-owned issues. I’d like to see all of these have an owner to help push these along during the release.


@azaozz has been graciously diligent in comprising a list of Uploads issues that should be prioritized. Most of all #40439 needs to be merged as soon as possible as it is currently a blocker for all of the issues in the list. For that ticket, @mikeschroder mentioned that some eyes/hands are needed on the UX/UI side for handling during the upload; likely a mix between the modal and Gutenberg. There is currently UI for testing in the patch but this is not the final design. This should aim to land early in the 5.3 cycle. The full list can be found below:

@pbiron brought up a ticket that would be great to have #44900 be considered for 5.3. It currently needs design feedback so that @pbiron can move it along. Any help there would be very appreciated.

The media team is also aiming for a A11y Media focused bug scrub at the beginning, middle, and end of the release cycle. More to come on that as they are scheduled. There are a large handful of smaller bugs that will not require a major amount of work to address in this cycle so they will be high priority. Any preferred times/dates for the scrubs are encouraged to be included in the comments below.

Next Meeting

The next #core-media meeting is set for Thursday, May 30, 2019 at 13:00UTC See you there!

#core-media, #media, #summary

Dev Chat Summary: 22 May

@chanthaboune served as the facilitator for discussion and many contributors were in attendance.


Nothing major to announce this week. Tune in next!

5.2.1 Debrief

WordPress 5.2.1 released yesterday! For information on the release you may refer to the 5.2.1 blog post. Thanks to @desrosj and @earnjam for leading such a smooth release. As of now, there are no notable issues. If you are seeing any issues, please discuss in the comments below or create a new ticket at:


There are a handful of tickets in the 5.2.2 milestone. A team is needed to help wrangle those tickets into a new release. Now is the time to volunteer for leading 5.2.2. This release would aim to be for a 2 week release cycle to clear up remaining tickets in the milestone. There were two volunteers to lead in chat today: @audrasjb and @justinahinon. Please volunteer in the comments below if you are also interested in leading or co-leading!

@aduth said there was mention of a few issues in #core-editor chat earlier today of Gutenberg bugs which would be nice to aim to include for the release:

Major release (5.3)

Comments were closed today in the call for 5.3 tickets post. @chanthaboune will be pulling those together the submissions and do some outreach to maintainers that have not included items to the post as we prepare for the next major release. These tickets will inform what focuses this release will have.

Calls from component maintainers

@azaozz, is continuing to plan for some recommended changes and focuses for the Uploads and Media components.

@desrosj reminded us that the following components: General Component, Comments, Pings/Trackbacks, External Libraries, Filesystem API, Rewrite Rules, and Script Loader are all currently without any maintainers. If those parts of core interest you, feel free to reach out to @chanthaboune to get involved!

@karmatosed mentioned that there is an editor component triage on Friday at 17:00 UTC, @desrosj and @karmatosed will be running it in #core-editor and the triage will focus on trac tickets.

@johnbillion asked if there were any component maintainers looking for new maintainers of their components and @chanthaboune made the important reminder, “open source is designed to let people move in and out of volunteer positions as needed” If you are not comfortable saying in dev chat that you would like to make changes, please feel free to reach out privately to @chanthaboune or other co-maintainers.

Open Floor

There was an ask by @afragen to have a committer review He also reminded us committers are not the only ones with valuable feedback. Please direct any thoughts about the issue to the ticket, even if you are not one. 🙂

#5-3, #5-2, #5-2-1, #devchat, #summary

Dev Chat Agenda: May 22

Below is the agenda for the weekly devchat meeting on Wednesday, May 22, 2019, 2000 UTC.

  • Announcements
  • 5.2.1 Debrief
  • 5.2.2 Planning
    • Call for release leads
  • 5.3
  • Calls from component maintainers
  • Open Floor

If you have anything to propose for the agenda or specific items related to those listed above, please leave a comment below.

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

#agenda, #devchat

#5-3, #5-2, #5-2-1, #core

Editor Chat Summary, May 22nd

Agenda, Slack Transcript


  • WordPress 5.2.1 was released and comes with a few Block Editor bugfixes, including RTL keyboard navigation and Format API ones.

Task Coordination

Slack Transcript

Visibility of documentation

Agenda, Slack Transcript

@karmatosed raises the question of how we can make the User docs and Developer docs more visible. Raised from community engagement.

Action items:

  • Engage docs and marketing. @karmatosed and @chrisvanpatten
  • Publish a make post on existing doc resources. @karmatosed
  • Add links to docs in (to be discussed with marketing). @karmatosed
  • Idea worth exploring: how docs can be surfaced the Help tab in wp-admin. Unowned.

Open Floor

Slack transcript

@yannicki asks about the status of adding an inner container to the Group block. It’s in review status and there is some uncertainty around the approach. Will get more attention in the next weeks.

New package @wordpress/data-controls. To be released to npm in next Gutenberg release (expected in a week). @nerrad

Work continues to explore useSelect primitive in @wordpress/data package. @nerrad

Triage sessions: @youknowriad @nerrad @karmatosed

  • these group activities with a set schedule are valuable to bring new contributors and clarify the status of certain proposals
  • this can be resource expensive if they’re ran and attended by the core-team only
  • to be continued and evaluated after a while

#core-editor, #editor-chat, #summary

Editor Chat Agenda: May 22nd

This is the agenda for the weekly editor chat meeting on Wednesday, 22nd May 2019, 13:00 UTC.

  • Tasks Coordination
  • Open Floor

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

If you have anything to propose for the agenda or specific items related to those listed above, please leave a comment below.

#agenda, #core-editor, #editor-chat

JavaScript chat summary, May 14th, 2019

Below is a summary of the discussion from last week’s JavaScript chat (agendaSlack Transcript)

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

Agenda: React Hooks for Data

Slack Conversation

We discussed an issue to introduce a useSelect React hook to the @wordpress/data package. The discussion focused on determining what the best API would be and a concern was raised to investigate the potential performance impact. We agreed it would be best to have a single useSelect function which allows to pass in a mapping callback for more complex conditional type use-cases involving multiple selectors/stores. We could create utility functions for simple cases.

Open floor: Node compatibility

The version of node-sass we use isn’t compatible with Node 12.x. A PR to update node-sass to a compatible version is now merged.

#core-js, #corejs, #javascript, #js

WordPress 5.2.1-RC2

WordPress 5.2.1-RC2 is now available for testing!

There are two ways to test the newest WordPress 5.2 release candidate: try the WordPress Beta Tester plugin (you’ll want to select the “point release nightlies” option), or you can download the release candidate here (zip).

What’s in this release?

In addition to the everything included in RC1, 5.2.1-RC2 fixes 3 issues discovered by those who tested RC1:

  • #47323 prevents a fatal error that occurs when upgrading to 5.2.1 from WordPress < 5.2.
  • #47304 fixes a regression that can affect the accuracy of <lastBuildDate> in feeds.
  • #47312 changes the string used on the About page for 5.2.1 to one that is already translated.

You can browse the full list of changes in 5.2.1 on Trac.

What’s next?

Committers: The dev-reviewed workflow (double committer sign-off) still applies when making any changes to the 5.2 branch.

The official 5.2.1 release is still scheduled for Tuesday, May 21.

Happy testing!

#5-2, #5-2-1, #releases

WordPress 5.2.1-RC1

WordPress 5.2.1-RC1 is now available for testing! But, your help is needed to test!

There are two ways to test the WordPress 5.2 release candidate: try the WordPress Beta Tester plugin (you’ll want to select the “point release nightlies” option), or you can download the release candidate here (zip).

What’s in this release?

5.2.1 contains 32 high priority bug fixes and regressions, improvements to the block editor, accessibility, i18n, and polishes the Site Health feature introduced in 5.2. Here are some changes of note:

  • #47180: An issue typing in the block editor while using a RTL language has been fixed.
  • #47186: An bug causing 32-bit systems to run out of memory when using sodium_compat was fixed.
  • #47189: The “Update your plugins” link in Site Health now links to the correct page in multisite installs.
  • #47185: An issue in wp_delete_file_from_directory() where files were not deleting on Windows systems has been fixed.
  • #47205: A bug was fixed where spaces could not be added in the Classic Editor after pressing shift+enter.
  • #47265: 2 fatal errors on the error protection page when a PHP error was encountered in a drop-in (such as advanced-cache.php) were fixed.
  • #47244: wp_targeted_link_rel() has been improved to prevent instances where single and double quotation marks were incorrectly staggered.
  • #47169: PHP/MySQL minimum version requirement checks now return proper error codes when requirements are not met in test environments.
  • #47177: The backwards compatibility of get_search_form() was improved.
  • #47297: The accuracy of the HTTP requests test in Site Health was improved.
  • #47229: TinyMCE has been updated to version 4.9.4.

You can browse the full list of changes on Trac.

What’s next?

Committers: The dev-reviewed workflow (double committer sign-off) should now be enforced when making any changes to the 5.2 branch.

The official 5.2.1 release is scheduled for Tuesday, May 21.

Happy testing!

#5-2, #5-2-1, #releases

Security in 5.2

Post originally written by Scott Arciszewski.

Protection Against Supply-Chain Attacks

Starting with WordPress 5.2, your website will remain secure even if the servers get hacked.

We are now cryptographically signing WordPress updates with a key that is held offline, and your website will verify these signatures before applying updates.

Signature Verification in WordPress 5.2

When your WordPress site installs an automatic update, from version 5.2 onwards it will first check for the existence of an x-content-signature header. If one isn’t provided by our update server, your WordPress site will instead query for a filenamehere.sig file and parse it.

The signatures were calculated using Ed25519 of the SHA384 hash of the file’s contents. The signature is then base64-encoded for safe transport, no matter how it’s delivered.

The signing keys used to release updates are managed by the core development team. The verification key for the initial release of WordPress 5.2 is fRPyrxb/MvVLbdsYi+OOEv4xc+Eqpsj+kkAS6gNOkI0= (expires April 1, 2021).

(For the sake of specificity: Signing key here means Ed25519 secret key, while verification key means Ed25519 public key.)

To verify an update file, your WordPress site will calculate the SHA384 hash of the update file and then verify the Ed25519 signature of this hash. If you’re running PHP 7.1 or older and have not installed the Sodium extension, the signature verification code is provided by sodium compat.

Our signature verification is implemented in the new verify_file_signature() function, inside wp-admin/includes/file.php.

Modern Cryptography for WordPress Plugins

The inclusion of sodium_compat on WordPress 5.2 means that plugin developers can start to migrate their custom cryptography code away from mcrypt (which was deprecated in PHP 7.1, and removed in PHP 7.2) and towards libsodium.

Example Functions

 * @param string $message
 * @param string $key
 * @return string
function wp_custom_encrypt( $message, $key )
    $nonce = random_bytes(24);
    return base64_encode(
        $nonce . sodium_crypto_aead_xchacha20poly1305_ietf_encrypt(

 * @param string $message
 * @param string $key
 * @return string
function wp_custom_decrypt( $message, $key )
    $decoded = base64_decode($message);
    $nonce = substr($decoded, 0, 24);
    $ciphertext = substr($decoded, 24);
    return sodium_crypto_aead_xchacha20poly1305_ietf_decrypt(

How to Seamlessly and Securely Upgrade your Plugins to Use the New Cryptography APIs

If your plugin uses encryption provided by the abandoned mcrypt extension, there are two strategies for securely migrating your code to use libsodium.

Strategy 1: All Data Decryptable at Run-Time

If you can encrypt/decrypt arbitrary records, the most straightforward thing to do is to use mcrypt_decrypt() to obtain the plaintext, then re-encrypt your code using libsodium in one sitting.

Then remove the runtime code for handling mcrypt-encrypted messages.

// Do this in one sitting
$plaintext = mcrypt_decrypt( $mcryptCipher, $oldKey, $ciphertext, $mode, $iv );
$encrypted = wp_custom_encrypt( $plaintext, $newKey );

Strategy 2: Only Some Data Decryptable at Run-Time

If you can’t decrypt all records at once, the best thing to do is to immediately re-encrypt everything using sodium_crypto_secretbox() and then, at a later time, apply the mcrypt-flavored decryption routine (if it’s still encrypted).

 * Migrate legacy ciphertext to libsodium
 * @param string $message
 * @param string $newKey
 * @return string
function wp_migrate_encrypt( $message, $newKey )
    return wp_custom_encrypt(
        'legacy:' . base64_encode($message),

 * @param string $message
 * @param string $newKey
 * @param string $oldKey
 * @return string 
function wp_migrate_decrypt( $message, $newKey, $oldKey )
    $plaintext = wp_custom_decrypt($message, $newKey);
    if ( substr($plaintext, 0, 7) === 'legacy:' ) {
        $decoded = base64_decode( substr($plaintext, 7) );
        if ( is_string($decoded) ) {
            // Now apply your mcrypt-based decryption code
            $plaintext = mcrypt_decrypt( $mcryptCipher, $oldKey, $decoded, $mode, $iv );

            // Call a re-encrypt routine here
    return $plaintext;

Avoid Opportunistic Upgrades

A common mistake some developers make is to try to do an “opportunistic” upgrade: Only perform the decrypt-then-re-encrypt routine on an as-needed basis. This is a disaster waiting to happen, and there is a lot of historical precedence to this.

Of particular note, Yahoo made this mistake, and as a result, had lots of MD5 password hashing lying around their database when they were breached, even though their active users had long since upgraded to bcrypt.

Detailed technical information about this new security feature, written by Paragon Initiative Enterprises (the cryptography team that developed it) are available here.

#5-2 #dev-notes