Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WP 5.5: merge all PHP changes #23210

Closed
10 of 12 tasks
ellatrix opened this issue Jun 16, 2020 · 28 comments
Closed
10 of 12 tasks

WP 5.5: merge all PHP changes #23210

ellatrix opened this issue Jun 16, 2020 · 28 comments
Labels
[Priority] High Used to indicate top priority items that need quick attention [Type] Task Issues or PRs that have been broken down into an individual action to take

Comments

@ellatrix
Copy link
Member

ellatrix commented Jun 16, 2020

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.

@ellatrix ellatrix added the [Type] Task Issues or PRs that have been broken down into an individual action to take label Jun 16, 2020
@ellatrix ellatrix added this to the Gutenberg 8.4 milestone Jun 16, 2020
@ellatrix ellatrix added the [Priority] High Used to indicate top priority items that need quick attention label Jun 16, 2020
@oandregal
Copy link
Member

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
Copy link
Member Author

@nosolosw Thanks!

@ellatrix
Copy link
Member Author

ellatrix commented Jun 16, 2020

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
Copy link
Member

gziolo commented Jun 17, 2020

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
Copy link
Contributor

draganescu commented Jun 17, 2020

@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
Copy link
Member

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
Copy link
Member

gziolo commented Jun 17, 2020

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
Copy link
Member

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
Copy link
Member Author

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
Copy link
Contributor

Is there any documentation around that?

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

@spacedmonkey
Copy link
Member

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

@draganescu
Copy link
Contributor

draganescu commented Jun 18, 2020

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
Copy link
Member

oandregal commented Jun 18, 2020

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
Copy link
Member

We also need to port this - #22721

@TimothyBJacobs
Copy link
Member

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
Copy link
Contributor

ockham commented Jun 18, 2020

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
Copy link
Member

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
Copy link
Member

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
Copy link
Contributor

ockham commented Jun 22, 2020

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
Copy link
Member Author

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

@ellatrix
Copy link
Member Author

@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
Copy link
Member

@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 ellatrix removed this from the Gutenberg 8.5 milestone Jun 22, 2020
@ellatrix
Copy link
Member Author

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

@TimothyBJacobs
Copy link
Member

@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
Copy link
Member

gziolo commented Jun 22, 2020

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
Copy link
Member

gziolo commented Jun 23, 2020

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

@tellyworth
Copy link
Contributor

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
Copy link
Contributor

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

This was referenced Jul 15, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Priority] High Used to indicate top priority items that need quick attention [Type] Task Issues or PRs that have been broken down into an individual action to take
Projects
None yet
Development

No branches or pull requests

10 participants