search

WordPress / gutenberg

The Block Editor project for WordPress and beyond. Plugin is available from the official repository.
https://wordpress.org/gutenberg/
Other
10.52k stars 4.21k forks source link

WP 5.5: merge all PHP changes #23210

Closed ellatrix closed 4 years ago

ellatrix commented 4 years ago

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.

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 commented 4 years ago

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 commented 4 years ago

@nosolosw Thanks!

ellatrix commented 4 years ago

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 commented 4 years ago

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:

draganescu commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

Is there any documentation around that?

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

spacedmonkey commented 4 years ago

I have a PR for menus endpoint and block types Menus endpoint - https://github.com/WordPress/wordpress-develop/pull/319 Block Type endpoint - https://github.com/WordPress/wordpress-develop/pull/317

draganescu commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

We also need to port this - https://github.com/WordPress/gutenberg/pull/22721

TimothyBJacobs commented 4 years ago

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 commented 4 years ago

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:

TimothyBJacobs commented 4 years ago

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.

noisysocks commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

ellatrix commented 4 years ago

@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 commented 4 years ago

@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 commented 4 years ago

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

TimothyBJacobs commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

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

tellyworth commented 4 years ago

The enqueue code from lib/block-directory.php is backported in https://github.com/WordPress/wordpress-develop/pull/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 commented 4 years ago

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