Editor: Update WordPress packages to use with WordPress 5.8

[gziolo]

Trac ticket: https://core.trac.wordpress.org/ticket/52991

I executed npm run wp-packages-update and npm run build:dev to update the block editor to the latest version based on WordPress packages published to npm.

It works!!!

---

This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.

[gziolo]

I’m surprised to see it happening, but it looks like the update for WordPress packages works on the first try in core. The version of the Gutenberg plugin (v10.3.1) is ready to land.
It would be great to learn which PHP changes are missing and need to be backported, but I think we can do it separately. I haven’t tried enabling FSE features or installing the Gutenberg plugin.

[youknowriad]

I think we should compare the "lib" folder between the two Gutenberg versions used previously and the new one.

[youknowriad]

Do you know which version was used before?

[youknowriad]

I think for instance, that there are a number of changes to the block-supports folder (all of them maybe?) that should be backported.

[gziolo]

Do you know which version was used before?

Not yet, but I'm going to check it soon.

There are some changes in how blocks are aligned when the plugin gets activated:

The most important part is that it works with the plugin installed so it feels like we can merge those changes as the first step and backport all the missing bits afterward. What do you think?

[youknowriad]

The most important part is that it works with the plugin installed so it feels like we can merge those changes as the first step and backport all the missing bits afterward. What do you think?

I don't know to be honest, I wouldn't want to merge a broken experience personally, at least we should identify them and have tickets for them. I'm going through some of theme right now WordPress/gutenberg@v9.9.3...v10.3.2

For example, I see the lazy loading related changes as well.

[gziolo]

Many of the changes are behind the feature flag for FSE themes on PHP side. I'm not sure how much of the code is also removed from the JS build for those features marked as experimental which is most of the FSE blocks.

[youknowriad]

Here's what I got so far, I only kept the changes that should probably be backported (not experimental things)

• Block Supports changes (even if it uses experimental flags, these flags are used in Core blocks, so this is mandatory)
• Inline lazy loading (I don't know if this impacts the experience if not backported, maybe it's optional and should have its own ticket) Independent
• New style handles to register and tweak dependencies (classic.css and reset.css, reusable-blocks.css). this is very important
• Prevent the default editor styles from being loaded. this is very important too
• Update Reusable block CPT labels
• editor settings function (you know better for this one)
• WP_REST_URL_Details_Controller (not sure about that one and whether it's used by stable JS things)
• Layout block support and « supportsLayout » editor setting. (this might require some theme.json related stuff so we could potentially skip until we backport theme.json stuff)
• New block category (theme) though maybe it’s just for FSE blocks now (need to confirm that done in https://core.trac.wordpress.org/changeset/50564)
• Add object-position to the allowed kses attributes

[gziolo]

Thank you @youknowriad for checking. I converted your comment into todo list and marked the last item as done. I took care of it 2 weeks ago.

[gziolo]

Inline lazy loading (I don't know if this impacts the experience if not backported, maybe it's optional and should have its own ticket)

@aristath, can you help us decide whether it's mandatory to include for WordPress 5.8 or more importantly in this context if that has any relation to JS code?

[draganescu]

WP_REST_URL_Details_Controller arrived via #18042 and would be used by #19387 which is not ready yet.

[aristath]

@aristath, can you help us decide whether it's mandatory to include for WordPress 5.8 or more importantly in this context if that has any relation to JS code?

inline lazy styles loading has no JS dependencies so it can go in 5.8 👍
It is completely opt-in (by default enabled for FSE but otherwise opt-in is required) and won't break anything out of the box, so it would be great to have it in core and allow developers to start taking advantage of it.

[youknowriad]

@aristath I'm reading that it can go into its own dedicated ticket right? And updating the packages won't break anything if it's not done at the same time?

[aristath]

@aristath I'm reading that it can go into its own dedicated ticket right? And updating the packages won't break anything if it's not done at the same time?

Yes, updating the packages won't break anything if not done at the same time. It can be a separate, dedicated ticket.

[youknowriad]

This one is only half backported, because it's only used for themes with theme.json which is not in Core yet. So for now I only included the mandatory filter to make themes without theme.json work properly.

[youknowriad]

Did another review of the diff and checked a few items on the list, I think we're good.

We're missing two things:

• the editor settings refactoring (this can potentially be separate as I don't think it impacts frontend, it's just a refactoring)
• lazy loading (can we create a ticket and link to it as a reference)

There are three things that we should remember to do when back porting theme.json changes (if they land on 5.8)

• Fully backport the layout block support,
• Add a conditional check about the "classic.css" dependency in the style loader (only load it for non theme.json themes),
• Add the supportsLayout editor setting.

[gziolo]

I will fix the issues reported by CI, improve PHPDoc comments and test locally.

We're missing two things:

• the editor settings refactoring (this can potentially be separate as I don't think it impacts frontend, it's just a refactoring)
• lazy loading (can we create a ticket and link to it as a reference)

Right, those can land separately 👍🏻

We also need to add unit tests for newly added functionality in the follow-up patches

• block supports
  • align
  • border
  • colors
  • custom classname
  • generated classname
  • layout
  • padding
  • typography
• block_has_support

The best news is that everything looks like in the Gutenberg plugin after all changes applied by @youknowriad 🎉

[gziolo]

All changes committed in https://core.trac.wordpress.org/changeset/50761.

[youknowriad]

Would love if we can run the e2e tests against trunk. I tried running the command but it's failing because of wp-env somehow.

[peterwilsoncc]

Thanks for following this up folks. It looks like my instinct was correct that it would require more than a simple package update so I'm glad I left it for the experts. :)

[gziolo]

@peterwilsoncc, actually I also backported changes from 5.7.1 in a45c871 as a temporary step. However, @youknowriad helped to identify missing PHP changes and here we are enjoying all the latest stable features of Gutenberg in WordPress trunk 😄