Editor: Update WordPress packages to use with WordPress 5.8

[gziolo]

In the response to the discussion during the Dev Chat, I'm opening a ticket to group all efforts to keep WordPress packages up to date in the WordPress 5.8 release cycle:

@clorith started a discussion on more frequently merging updates from the Gutenberg plugin in to Core. Highlighting that this would make testing future releases of WordPress features easier without keeping track of which features will remain in the plugin for the time being. There was general support for the idea.​ @chanthaboune is offered her help to move this forward

​https://make.wordpress.org/core/2021/03/25/dev-chat-meeting-summary-march-24-2021/

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

This PR only updates development dependencies for WordPress packages to align better with the Gutenberg plugin.

[gziolo]

In 50685:

Build Tools: Update development dependencies from WP packages

This patch updates only development dependencies for WordPress packages to align better with the Gutenberg plugin.

See #52991.

[prbot]

​gziolo commented on ​PR #1175:

Committed in https://core.trac.wordpress.org/changeset/50685 without the dummy commit.

Trac ticket remains open.

[gziolo]

In 50686:

Editor: Ensure @wordpress/inteface package is listed as a dependency

Discovered when backporting changes for WordPress 5.7.1 release.

See #52991.

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.

[prbot]

​gziolo commented on ​PR #1176:

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:
​https://github.com/WordPress/wordpress-develop/pull/1176
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.

[prbot]

​youknowriad commented on ​PR #1176:

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

[prbot]

​youknowriad commented on ​PR #1176:

Do you know which version was used before?

[prbot]

​youknowriad commented on ​PR #1176:

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

[prbot]

​gziolo commented on ​PR #1176:

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:

<img width="1917" alt="Screen Shot 2021-04-07 at 14 43 19" src="​https://user-images.githubusercontent.com/699132/113868198-b663d900-97af-11eb-89a6-21707f4176d1.png">

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?

[prbot]

​youknowriad commented on ​PR #1176:

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 ​https://github.com/WordPress/gutenberg/compare/v9.9.3...v10.3.2

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

[prbot]

​gziolo commented on ​PR #1176:

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.

[prbot]

​youknowriad commented on ​PR #1176:

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)
• 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)

[prbot]

​gziolo commented on ​PR #1176:

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.

[prbot]

​gziolo commented on ​PR #1176:

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?

[prbot]

​draganescu commented on ​PR #1176:

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

[prbot]

​aristath commented on ​PR #1176:

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.

[prbot]

​youknowriad commented on ​PR #1176:

@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?

[prbot]

​aristath commented on ​PR #1176:

@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.

[prbot]

​youknowriad commented on ​PR #1176:

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.

[prbot]

​gziolo commented on ​PR #1176:

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

[gziolo]

In 50761:

Editor: Update WordPress packages to use with WordPress 5.8

In the response to the discussion during the Dev Chat, I'm doing a first pass to keep WordPress packages up to date in the WordPress 5.8 release cycle.

See ​https://github.com/WordPress/wordpress-develop/pull/1176 for more details.

Props youknowriad, aristath, andraganescu.
See #52991.

[prbot]

​gziolo commented on ​PR #1176:

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

[prbot]

​youknowriad commented on ​PR #1176:

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.

[prbot]

​peterwilsoncc commented on ​PR #1176:

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. :)

[prbot]

​gziolo commented on ​PR #1176:

@peterwilsoncc, actually I also backported changes from 5.7.1 in ​https://github.com/WordPress/wordpress-develop/commit/a45c8715410b1f362218da80eda9bd0248fd5503 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 😄