WP 5.5: merge all PHP changes

[ellatrix]

With the WordPress 5.5 beta release around the corner, all PHP changes since Gutenberg v7.5 have to be merged with Core. Since we already want to merge Gutenberg 8.4 into core (updating the JS packages), this needs to be done as soon as possible, before 2020-06-24.

• Update Packages GB 8.5 (JS): Update WordPress Packages wordpress-develop#347
• Update Packages GB 8.5 (JS)

---

• Block Patterns: https://core.trac.wordpress.org/ticket/50445
• Block API
  • WP_Block and WP_Block_List: https://core.trac.wordpress.org/ticket/49926
  • Block Type endpoint: REST API: Expose blocks registered on the server wordpress-develop#317
• Image Editing endpoint
• Block Directory: REST API: Introduce Plugins and Block Directory endpoint wordpress-develop#359
• Compat
  • Update default block categories: https://core.trac.wordpress.org/ticket/50278 Together with package update.
  • Register block from block.json metadata file: https://core.trac.wordpress.org/ticket/50263
  • Remove default "layout" block attribute from WP_Block_Type::get_attributes: https://core.trac.wordpress.org/ticket/50257

It looks like the following files have changed.

git diff release/7.5...master --name-only -- 'lib/' | sed 's/.*/[&](https:\/\/github.com\/WordPress\/gutenberg\/commits\/master\/&)/'

I collapsed some directories that contain one feature.

? = Undecided
x = Not for this release
A = Assigned

A lib/block-directory.php (Block Directory) @tellyworth
A lib/blocks.php (Block API) @gziolo @epiqueras
A lib/class-wp-block-list.php (Block API) @gziolo @epiqueras
A lib/class-wp-block-pattern-categories-registry.php (Block Patterns) @youknowriad
A lib/class-wp-block-patterns-registry.php (Block Patterns) @youknowriad
A lib/class-wp-block.php (Block API) @gziolo @epiqueras
A lib/class-wp-rest-block-directory-controller.php (Block Directory) @tellyworth @TimothyBJacobs
A lib/class-wp-rest-block-types-controller.php (Block API) @spacedmonkey @TimothyBJacobs
x lib/class-wp-rest-customizer-nonces.php (Navigation Screen)
A lib/class-wp-rest-image-editor-controller.php (Image editing) @ajlende @TimothyBJacobs @azaozz @ellatrix
x lib/class-wp-rest-menu-items-controller.php (Navigation Screen)
x lib/class-wp-rest-menu-locations-controller.php (Navigation Screen)
x lib/class-wp-rest-menus-controller.php (Navigation Screen)
A lib/class-wp-rest-plugins-controller.php (Block Directory) @tellyworth @TimothyBJacobs
x lib/class-wp-rest-widget-forms.php (Widget Screen)
lib/client-assets.php
A lib/compat.php @gziolo
x lib/demo-block-template-parts/header.html (FSE)
x lib/demo-block-templates/ (FSE)
x lib/edit-site-export.php (FSE)
x lib/edit-site-page.php (FSE)
x lib/editor-features.php (Global Styles)
x lib/experimental-default-theme.json (FSE)
x lib/experiments-page.php (Internal)
x lib/global-styles.php (Global Styles)
x lib/load.php (Internal)
x lib/navigation-page.php (Navigation Screen)
A lib/patterns/ (Block Patterns) @youknowriad
lib/rest-api.php
x lib/template-loader.php (FSE)
x lib/template-parts.php (FSE)
x lib/templates.php (FSE)
x lib/utils.php (Internal)
x lib/widgets.php (Widget Screen)

To know what changed in specific files, I use git diff release/7.5...master -- lib/compat.php for example.

[oandregal]

Ella, I can help prepare a patch to bring in the changes related to lib/global-styles.php. There are some ongoing conversations that may affect which parts are ported and/or how, but I'll figure it out.

[ellatrix]

@nosolosw Thanks!

[ellatrix]

Found a neat trick to collapse also there file types that's not available in the Github UI: https://github.com/WordPress/gutenberg/compare/release%2F7.5...master?file-filters%5B%5D=.php

It's still a huge page that has problems loading though.

[gziolo]

The good news is that packages/block-library/* is automatically synced with the build process in WordPress core. We can also skip everything in packages/e2e-tests/*. In addition to that bin/get-server-blocks.php was for internal usage and it was removed.

I plan to backport:

• phpunit/class-register-block-type-from-metadata-test.php
• phpunit/fixtures/block.asset.php
• related parts to that in lib/compat.php

[draganescu]

@TimothyBJacobs @spacedmonkey Just to note in this thread, are you aiming at bringing the menu endpoints into core for 5.5, because if so the files in that update these will be handled by one of you in a patch right? (This is just something in my memory but I could be completely wrong)

[TimothyBJacobs]

are you aiming at bringing the menu endpoints into core for 5.5

Will any of the Gutenberg features utilizing the endpoints be shipping in 5.5? If so, yep that's my plan.

the files in that update these will be handled by one of you in a patch right

Yeah we have a tracking ticket for it on Core and will make sure they get merged.

[gziolo]

There is a Trac ticket for block types REST API endpoint, but it as well rather depends on whether we integrate it with the codebase.

I'll be looking into backporting register_block_type_from_metadata next week.

[TimothyBJacobs]

I might ship the block types endpoint regardless, since we're dropping the individual block renderer endpoints there wouldn't otherwise be a way to get those attributes.

That being said, I'd be infinitely more comfortable if Gutenberg was using it.

[ellatrix]

The good news is that packages/block-library/* is automatically synced with the build process in WordPress core.

Is there any documentation around that?

[youknowriad]

Is there any documentation around that?

AFAIK, no documentation but it's just a copy script that happens on npm install (or build)

[spacedmonkey]

I have a PR for menus endpoint and block types
Menus endpoint - WordPress/wordpress-develop#319
Block Type endpoint - WordPress/wordpress-develop#317

[draganescu]

Hi @TimothyBJacobs ,

Will any of the Gutenberg features utilizing the endpoints be shipping in 5.5? If so, yep that's my plan.

It likely that the Navigation page won't make it but the Navigation block does use the endpoints to "create from existing". On the other hand I don't know if the block will be out of experimental by that time.

My question was mostly related to @spacedmonkey 's effort above :)

[oandregal]

Ella, I've got clarity about some global styles related things, and we're not shipping them in 5.5, I've crossed out a couple of files we don't need (lib/global-styles.php and lib/editor-features.php).

I've also audited lib/client-assets.php for the things I'm familiar with and the function gutenberg_extend_settings_link_color shouldn't be ported to core either (I don't know how you prefer to mark this in the ticket, so I didn't).

[spacedmonkey]

We also need to port this - #22721

[TimothyBJacobs]

On the other hand I don't know if the block will be out of experimental by that time.

Do we know when a decision will be made on that? We really need first party usage before including the nav endpoints in Core.

[ockham]

I added some fields to the /themes endpoint in #21578. Those have been backported to Core already, but ended up in a slightly different format. So this change doesn't need backporting to Core, but I'll update Gutenberg to reflect that format, and add some kind of version check so it doesn't add those fields if they're already provided by Core.

Sound about right @TimothyBJacobs ? 😊

[TimothyBJacobs]

I added some fields to the /themes endpoint in #21578. Those have been backported to Core already, but ended up in a slightly different format. So this change doesn't need backporting to Core, but I'll update Gutenberg to reflect that format, and add some kind of version check so it doesn't add those fields if they're already provided by Core.

Sound about right @TimothyBJacobs ? 😊

Yep! See also #23054.

[noisysocks]

It likely that the Navigation page won't make it but the Navigation block does use the endpoints to "create from existing". On the other hand I don't know if the block will be out of experimental by that time.

I think that it (still) doesn't make sense to ship the Navigation block without also shipping either FSE or the Navigation screen. The block isn't very useful inside posts or pages.

[ockham]

I added some fields to the /themes endpoint in #21578. Those have been backported to Core already, but ended up in a slightly different format. So this change doesn't need backporting to Core, but I'll update Gutenberg to reflect that format, and add some kind of version check so it doesn't add those fields if they're already provided by Core.
Sound about right @TimothyBJacobs ? blush

Yep! See also #23054.

PR: #23321

[ellatrix]

@noisysocks The navigation block shouldn't be included this release.

[ellatrix]

@spacedmonkey @TimothyBJacobs If a REST API endpoint will not be used by anything, there's probably no point in adding it to core. On the contrary, maybe it does more damage as we won't be able to change it if it isn't experimental.

[TimothyBJacobs]

@spacedmonkey @TimothyBJacobs If a REST API endpoint will not be used by anything, there's probably no point in adding it to core. On the contrary, maybe it does more damage as we won't be able to change it if it isn't experimental.

Agreed. The menus route is no longer in the milestone.

[ellatrix]

@TimothyBJacobs Is the block types endpoint still something that should be merged?

[TimothyBJacobs]

@TimothyBJacobs Is the block types endpoint still something that should be merged?

I’d prefer to see it being used to bootstrap the editor, I believe @gziolo is looking at that?

But I think it is important to land regardless since the individual block renderer endpoints, and their accompanying attribute schemas, have been dropped in 5.5.

I’m less worried about block types since it is pretty much a direct output of the block registration RFC which as I understand it has been stabilized.

[gziolo]

There is still some time left to work on integration with the block types endpoint. It’s very solid and follows the RFC fully. If we missed anything we can fix it during the release process. I want us to have at least a proof of concept that validates integration with the block registration on the client.

[gziolo]

• register_block_type_from_metadata is now backported together with tests ( from lib/compat.php) – https://core.trac.wordpress.org/ticket/50263.
• PR for WP_Block and tests is opened at Editor: Introduce WP_Block and WP_Block_List classes wordpress-develop#351.

We still need to check what was added to lib/compat.php and decide whether it needs to be backported.

[tellyworth]

The enqueue code from lib/block-directory.php is backported in WordPress/wordpress-develop#359.
The data-handle part from that is going into a patch on https://core.trac.wordpress.org/ticket/48654. I think it's safe for that to be done separately, since there's nothing that currently depends on that filter as far as I'm aware.

[youknowriad]

This is done right? Closing, let me know if we should reopen