Update @wordpress packages and backport changes from Gutenberg plugin into Core

[Bernhard Reiter]

* Update @wordpress packages with packages published from Gutenberg.

• Backport PHP changes from Gutenberg's lib/compat/wordpress-6.1/ files.

This PR serves two purposes:

1. It's kind of a dry run for WP 6.1, to identify issues early.
2. It's supposed to unblock @gziolo's #2940. That PR changes the way we identify experimental blocks by looking for an __experimental flag in block.json. For that to work however, we need the latest version of blocks that includes that flag 🙃

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

It's supposed to unblock @gziolo's ​https://github.com/WordPress/wordpress-develop/pull/2940. That PR changes the way we identify experimental blocks by looking for an experimental flag in block.json. For that to work however, we need the latest version of blocks that includes that flag

Now, that you have the latest version of WP packages in this branch, you could try to apply the changes from the #2940 here and run the sync again. It should automatically detect at least the new List Item block.

It's supposed to unblock @gziolo's #2940. That PR changes the way we identify experimental blocks by looking for an experimental flag in block.json. For that to work however, we need the latest version of blocks that includes that flag

Now, that you have the latest version of WP packages in this branch, you could try to apply the changes from the #2940 here and run the sync again. It should automatically detect at least the new List Item block.

TBH I was considering to maybe get this PR in shape and merge it, and only then merge @2940 -- mostly to keep changes a bit more contained. Think that's viable? 😄

(I'm happy to try it locally, though 😄 )

(I'm happy to try it locally, though 😄 )

I would do it locally to check which blocks were added for 6.1 so you can include them manually here. Feel free to keep the changes related to the sync process outside of this PR 👍🏻

(I'm happy to try it locally, though 😄 )

I would do it locally to check which blocks were added for 6.1 so you can include them manually here. Feel free to keep the changes related to the sync process outside of this PR 👍🏻

Ah, gotcha! Makes sense, I'll give that a go -- thank you!

Hmm. I ran git merge add/sync-stable-blocks-utility, resolved a conflict in tools/webpack/blocks.js (remove explicit block lists), and ran npm run sync-gutenberg-packages. No changes though 😕

PR is a path for following changes in the Gutenberg plugin:

• ​https://github.com/WordPress/gutenberg/pull/42209
• ​https://github.com/WordPress/gutenberg/pull/42413

Gutenberg tracking issue: ​https://github.com/WordPress/gutenberg/issues/43440
Trac ticket: https://core.trac.wordpress.org/ticket/56467

Sidenote: I really like the suggestion @TimothyBJacobs made recently in canUser optimization PR - ​https://github.com/WordPress/gutenberg/pull/43480#issuecomment-1231013981. Once those suggestions are implemented, I think we can trim down the preloaded paths array.

Backports changes from ​https://github.com/WordPress/gutenberg/pull/42957.

The site_icon_url index was supposed to ship with WP 5.6 but was never backported into the core - ​https://github.com/WordPress/gutenberg/pull/22952.

I also created an alternative PR to use the existing site_icon index, but later @TimothyBJacobs pointed out that site_icon_url is preferable since it can be filtered - ​https://github.com/WordPress/gutenberg/pull/43514#issuecomment-1231049189.

Gutenberg tracking issue: ​https://github.com/WordPress/gutenberg/issues/43440
Trac ticket: https://core.trac.wordpress.org/ticket/56467

Thank you very much, @Mamaduka! 🙌

Some unit tests are failing; apparently, tests/qunit/fixtures/wp-api-generated.js needs updating:

Furthermore, I've glanced over ​https://github.com/WordPress/gutenberg/pull/42957 and ​https://github.com/WordPress/gutenberg/pull/43514. I'm not entirely sure about the conclusion -- it seems like we won't need site_icon_url once we merge ​https://github.com/WordPress/gutenberg/pull/43514; but we still need to backport it for backwards compatibility. Is that correct? 😊

I am running a PHP test suite to regenerate fixtures, and I will push the fix shortly.

Furthermore, I've glanced over ​https://github.com/WordPress/gutenberg/pull/42957 and ​https://github.com/WordPress/gutenberg/pull/43514. I'm not entirely sure about the conclusion -- it seems like we won't need site_icon_url once we merge ​https://github.com/WordPress/gutenberg/pull/43514; but we still need to backport it for backwards compatibility. Is that correct? 😊

We decided to use site_icon_url index, so that it can be filtered via get_site_icon_url. I'll close #43514 after this is backported.

Backport of ​https://github.com/WordPress/gutenberg/pull/41015.

Needed for the package-sync "dry run" PR: ​https://github.com/WordPress/wordpress-develop/pull/3154#discussion_r958841837

### Questions:

• [ ] Should this include other related changes, e.g. ​https://github.com/WordPress/gutenberg/pull/43073?
• [ ] Does this need a (basic) unit test?

cc/ @glendaviesnz @ramonjd for review 😊

Gutenberg tracking issue: ​https://github.com/WordPress/gutenberg/issues/43440
Trac ticket: https://core.trac.wordpress.org/ticket/56467

May make sense to move this logic into add_site_icon_to_index.

I've filed a counterpart PR for GB: ​https://github.com/WordPress/gutenberg/pull/43779

I've thought about adding a unit test, but I'm now leaning against, for the following reasons:

• wp_enqueue_block_support_styles is pretty straight-forward (especially compared to other functions in the same file -- most of which don’t have unit test coverage.) -- It basically just calls add_action().
• It passes a closure to add_action(). This means we can't really have a test that checks for that closure (e.g. via ​`has_action()`, as we can't reference it from outside the function scope.
• AFAICS, this leaves us with some indirect testing, such as running wp_enqueue_block_support_styles(), and then wp_head() (or wp_footer(), respectively), to see if the CSS that was passed to the function was added to the header (or footer, respectively). However, it's kinda messy to look for that styling inside of the (fairly big) header/footer.
• Finally, there isn't really any way to test if the $priority was respected -- which is the change we're actually making here.

[desrosj]

In 54048:

Script Loader: Allow a priority to be passed to wp_enqueue_block_support_styles().

wp_enqueue_block_support_styles() attaches inline styles to the wp_head or wp_footer actions. This adds a priority parameter to the function to allow the styles to be given a loading order when necessary.

Props bernhard-reiter, ramonopoly.
See #56467.

Merged in https://core.trac.wordpress.org/changeset/54048.

Thanks for the suggestion, @TimothyBJacobs. I've updated the PR.

I ran into another problem:

I enabled the debugger and figured that the issue seems to be that the viewScript of the Navigation block is an array: ​https://github.com/WordPress/wordpress-develop/blob/7b087f6ccecced46cec4b57ce50ad39571fe9052/src/wp-includes/blocks/navigation/block.json#L129

Support for array in viewScript was merged in ​https://github.com/WordPress/gutenberg/pull/36176 so we should investigate why this is a problem.

[noisysocks]

In 54079:

Script Loader: Pass startOfWeek setting to @wordpress/date

Allows the block editor to respect the site's Week Starts On setting by defining
i10n.startOfWeek when initialising the @wordpress/date module.

This is a backport of ​https://github.com/WordPress/gutenberg/pull/41648.

See #56467.
Props andrewserong.

I ran into another problem:

I enabled the debugger and figured that the issue seems to be that the viewScript of the Navigation block is an array:

​https://github.com/WordPress/wordpress-develop/blob/7b087f6ccecced46cec4b57ce50ad39571fe9052/src/wp-includes/blocks/navigation/block.json#L129

Support for array in viewScript was merged in ​WordPress/gutenberg#36176 so we should investigate why this is a problem.

Good catch. The following PR ​https://github.com/WordPress/wordpress-develop/pull/3108 should resolve that issue. I want to wrap up the related refactoring this week.

[SergeyBiryukov]

In 54083:

REST API: Add the missing site_icon_url to the index.

The site_icon_url index was supposed to ship with WordPress 5.6, but was ​never backported to core.

This commit backports the original PR from Gutenberg repository:

• ​#42957: REST API: Add the missing 'site_icon_url' to the index

Follow-up to [52080].

Props Mamaduka, bernhard-reiter, TimothyBlynJacobs.
See #56467.

Thanks for the PR! Merged in r54083.

[SergeyBiryukov]

In 54084:

Block Editor: Preload settings and templates permissions.

This is a path for following changes in the Gutenberg plugin:

• ​#42209: Post Editor: Preload templates post type permissions
• ​#42413: Post Editor: Avoid 403 errors for users with low permissions.

Follow-up to [43815], [44172], [46110], [51962], [52995].

Props Mamaduka, bernhard-reiter, TimothyBlynJacobs.
See #56467.

Thanks for the PR! Merged in r54084.

Backporting typography block supports changes from Gutenberg to WP 6.1

See tracking issue: ​https://github.com/WordPress/gutenberg/issues/43440

### Main changes

• ​https://github.com/WordPress/gutenberg/pull/39529
• ​https://github.com/WordPress/gutenberg/pull/40332

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

❗ BLOCKED by ​https://github.com/WordPress/wordpress-develop/pull/3199

Backporting border, color, elements, spacing block supports changes from Gutenberg to WP 6.1

Typography is taken care of over in ​https://github.com/WordPress/wordpress-develop/pull/3203

See tracking issue: ​https://github.com/WordPress/gutenberg/issues/43440

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

See tracking issue: ​https://github.com/WordPress/gutenberg/issues/43440

This includes all changes for block-supports/duotone.php.

• ​duotone.php
  • ​https://github.com/WordPress/gutenberg/pull/42020
  • ​https://github.com/WordPress/gutenberg/pull/39564

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

We need to backport the recent changes from this Gutenberg PR:

• ​https://github.com/WordPress/gutenberg/pull/41981
• ​https://github.com/WordPress/gutenberg/pull/41140

Draft to check tests (in local I got not related errors)
Trac ticket: https://core.trac.wordpress.org/ticket/56467

[SergeyBiryukov]

In 54101:

Editor: Update duotone block supports to allow unset for preset colors.

This add the ability to unset duotone in themes with default duotone set.

This commit backports the original PRs from Gutenberg repository:

• ​#39564: Add ability to unset duotone in themes with default duotone set
• ​#42020: Remove: Unrequired regex search on duotone supports

Follow-up to [50929], [52757].

Props ajlende, jorgefilipecosta, Joen, cbravobernal.
See #56467.

Thanks for the PR! Merged in r54101.

[SergeyBiryukov]

In 54105:

Global Styles: Add support for heading, button, and caption elements.

This enables themes to:

• Set style rules for all heading elements together rather than having to do it individually.
• Style captions in theme.json by adding this into your theme.json file:

  {
  	"styles": {
  		"elements": {
  			"caption": {
  				"color": {
  					"background": "red",
  					"text": "yellow"
  				}
  			}
  		}
  	}
  }
  

This commit backports the original PRs from Gutenberg repository:

• ​#41981: Global Styles: Add support for heading elements
• ​#41140: Global Styles: Add support for caption elements

Follow-up to [50973].

Props cbravobernal, scruffian, madhudollu, mikachan, zieladam, bph, poena, andraganescu, ndiego, bgardner.
See #56467.

Thanks for the PR! Merged in r54105.

This PR migrates the Style Engine PHP functions, classes and tests into Core for 6.1.

It reflects the latest changes from ​https://github.com/WordPress/gutenberg/pull/43840

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

❗ BLOCKED by ​https://github.com/WordPress/wordpress-develop/pull/3199

Backporting changes to script-loader that enqueue block support styles stored by the style engine/

See tracking issue: ​https://github.com/WordPress/gutenberg/issues/43440

### Backporting the following changes

• ​https://github.com/WordPress/gutenberg/pull/42880

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

## Description
Backports the persisted preferences feature from Gutenberg (introduced in ​https://github.com/WordPress/gutenberg/pull/39795).

Removes the old block editor preferences persistence system.

## Testing

1. Ensure you have the Gutenberg plugin disabled
2. Open a block editor (it's worth testing each of the post editor, site editor, widgets editor and customize widgets editor).
3. Change some preferences (e.g. toggle Top Toolbar on)
4. Clear your local storage data
5. Reload the page

Expected: Preferences should be retained (e.g. Top Toolbar should still be on) despite local storage being cleared

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

I'll fix up those failing tests later. Last commit was a bit rushed.

Thanks for the reviews, folks.

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

Backports changes from:

• ​https://github.com/WordPress/gutenberg/pull/41387
• ​https://github.com/WordPress/gutenberg/pull/41189
• ​https://github.com/WordPress/gutenberg/pull/42520
• ​https://github.com/WordPress/gutenberg/pull/43597
• ​https://github.com/WordPress/gutenberg/pull/42586

Also, the GHA failures don't seem to be test failures, but workflow failures, so it looks like your last commit was clean

Good to know! I was on my phone so wasn't sure. I see red and 😱

This PR backports the following changes:

• ​https://github.com/WordPress/gutenberg/pull/40889
• ​https://github.com/WordPress/gutenberg/pull/41160
• ​https://github.com/WordPress/gutenberg/pull/40260
• ​https://github.com/WordPress/gutenberg/pull/41240
• ​https://github.com/WordPress/gutenberg/pull/41753
• ​https://github.com/WordPress/gutenberg/pull/41822
• ​https://github.com/WordPress/gutenberg/pull/41786
• ​https://github.com/WordPress/gutenberg/pull/41696
• ​https://github.com/WordPress/gutenberg/pull/41140
• ​https://github.com/WordPress/gutenberg/pull/42072
• ​https://github.com/WordPress/gutenberg/pull/42096
• ​https://github.com/WordPress/gutenberg/pull/41981
• ​https://github.com/WordPress/gutenberg/pull/42669
• ​https://github.com/WordPress/gutenberg/pull/42776 ⚠️ I don't think there's anything to backport on this one
• ​https://github.com/WordPress/gutenberg/pull/43088
• ​https://github.com/WordPress/gutenberg/pull/43167
• ​https://github.com/WordPress/gutenberg/pull/41335
• ​https://github.com/WordPress/gutenberg/pull/41446
• ​https://github.com/WordPress/gutenberg/pull/43988

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

I might not be around next week. cc @andrewserong in case this PR and related PRs need any attention, though I think we should be sound 👍

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

Backports changes from:

• ​https://github.com/WordPress/gutenberg/pull/43590
• ​https://github.com/WordPress/gutenberg/pull/40933

this only needs a review and check what's breaking the tests (they are all passing locally)

The tests previously ​failed on PHP 5.6 with a fatal error:
Fatal error: Cannot use isset() on the result of an expression (you can use "null !== expression" instead) in src/wp-includes/class-wp-theme-json.php on line 1526

0015d99 should resolve the issue. We already used array_key_exists( $element, static::VALID_ELEMENT_PSEUDO_SELECTORS ) in one place, and that resolves the error in other instances in my testing.

[SergeyBiryukov]

In 54118:

Editor: Backport Elements API updates.

This commit backports the original PRs from Gutenberg repository:

• ​#40260 Add support for button elements to theme.json
• ​#40889 Theme Json: Don't output double selectors for elements inside blocks
• ​#41140 Global Styles: Add support for caption elements
• ​#41160 Global Styles: Load block CSS conditionally
• ​#41240 Global Styles: Button Element: update button element selector
• ​#41335 Duotone: Fix CSS Selectors rendered by theme.json duotone/filter settings for blocks on public pages
• ​#41446 Block styles: Account for style block nodes that have no name
• ​#41696 Global Styles: Allow references to values in other locations in the tree
• ​#41753 Elements: Add an API make it easier to get class names
• ​#41786 Support pseudo selectors on elements in theme json
• ​#41822 Elements: Button - Fix element selectors
• ​#41981 Global Styles: Add support for heading elements
• ​#42072 Fix link element hover bleeding into button element default styles
• ​#42096 Add visited to link element allowed pseudo selector list
• ​#42669 Link elements: Add a :where selector to the :not to lower specificity
• ​#42776 Theme JSON: Add a static $blocks_metadata data definition to the Gutenberg instance of WP_Theme_JSON
• ​#43088 Pseudo elements supports on button elements
• ​#43167 Theme_JSON: Use existing append_to_selector for pseudo elements
• ​#43988 Styles API: Fixed selectors for nested elements

Props onemaggie, bernhard-reiter, cbravobernal, mmaattiiaass, scruffian, andraganescu, dpcalhoun, get_dave, Mamaduka, SergeyBiryukov.
See #56467.

Thanks for the PR! Merged in r54118.

Thanks a lot, folks!

I was alerted that unfortunately, r54118 caused a fatal error on websites running Core trunk and a current version of the Gutenberg plugin 😕

PHP Fatal error:  Cannot redeclare wp_add_global_styles_for_blocks() (previously declared in wp-includes/global-styles-and-settings.php:202) in wp-content/plugins/gutenberg/lib/compat/wordpress-6.1/get-global-styles-and-settings.php on line 12

We'll need to add a ! function_exists() wrapper around the ​function definition in Gutenberg to avoid this.

Unfortunately, this won't fix the problem immediately: WP sites running Core trunk with the GB plugin active will continue to be affected until a new version of the plugin is released (as planned for next Thursday); or until the change is merged into GB trunk (if the site is running GB trunk). And finally, sites running Core trunk and an older version of GB (that has the unguarded wp_add_global_styles_for_blocks function definition) will continue to be affected 😕

I'm not sure how to best cover the latter case. For mitigation, we might want to consider reverting r54118 (as much as it pains me to suggest that) -- at least until a GB version with the fix is released.

---

Going forward, we should probably put some strategies in place to avoid collisions like this:

• Require wp_ function definitions in GB to be guarded with a ! function_exists() check (and ideally enforce with a WPCS lint).
• Add a check in wordpress-develop's CI to install and enable GB alongside Core (and run some basic tests to make sure it doesn’t fatal).

Anyway, this is something we'll discuss separately. I'll file one or two issues tomorrow.

This PR is the beginnings of an attempt to backport the Layout block support refactor from Gutenberg to WordPress core for the 6.1 release. The goal is to attempt to do this in parts.

• Part 1 (this PR) is to backport the foundation for outputting centralised styles
• Part 2 will be to then backport layout.php in a follow-up, once the prerequisite issues have been resolved

Note that in the progress of working on this PR, it also pulls in parts of unrelated changes.

### Scope

• Include centralised Layout styles output
• Include root padding / root layout styles
• Include feature level selectors as they are present in some of the merged files

### Still to-do

• Update broken tests

### Included PRs

This change backports the following changes (while also being slightly different in order to align with core files):

• ​https://github.com/WordPress/gutenberg/pull/40875
• ​https://github.com/WordPress/gutenberg/pull/42544
• ​https://github.com/WordPress/gutenberg/pull/42087
• ​https://github.com/WordPress/gutenberg/pull/43792
• ​https://github.com/WordPress/gutenberg/pull/42544
• ​https://github.com/WordPress/gutenberg/pull/42665
• ​https://github.com/WordPress/gutenberg/pull/42085

Note that it doesn't _entirely_ port over #40875 — the remaining PHP changes for that PR will be explored in a separate PR targeting layout.php

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

Gutenberg tracking issue: ​https://github.com/WordPress/gutenberg/issues/43440

I wasn't too sure where or how we should best register blocks in core tests. I'll look into that further tomorrow.

@andrewserong, we might be able to avoid registering a new block within the bootstrap.php for the feature-level selectors test. From memory, we ​needed to do that because WordPress was loaded before the tests ran, meaning theme.json generated block metadata too soon effectively ignoring any block registration we did in the specific tests. Now the image block adopts the feature level selectors, it's probably time to switch the test to use that core block.

I'm out of time today but will touch base with you tomorrow on this one.

Update: Unbeknownst to me, the wp_ prefix has been changed to gutenberg_ in the GB plugin: ​https://github.com/WordPress/gutenberg/pull/44052

Update #2: Let's hold off on the revert. We might release a Gutenberg point release with ​this fix as a stop-gap.

Do not merge before this GB PR: ​https://github.com/WordPress/gutenberg/pull/44085/

Just a few minor things. This could also use tests to protect it going forward.

@costdev Thanks for your review. I'm definitely happy to contribute some tests, but I may need some advice on the best strategy. Is there an easy way to unit test something like the addition of the meta attribute?

Thanks for following up, Aaron! In that case, we might be better off adding the test for the feature level selectors once the image block's block.json file is updated, which should happen as part of ​https://github.com/WordPress/wordpress-develop/pull/3154. I might leave the scope of this PR as-is, then, but happy to continue investigating if anyone thinks we should pursue it in this PR.

@talldan I'd do something like this (untested):

public function test_should_register_persisted_preferences_meta() {
    wp_register_persisted_preferences_meta();

$actual = get_registered_metadata( 'user', 1, 'wptests_persisted_preferences' );
    $this->assertNotFalse( $actual, 'The expected meta key was not registered' );
    $this->assertSame(
        array(
            // Copy the array contents from source.
        ),
        $actual,
        'The metadata did not have the expected value'
    );
}

PR backports changes are required for using block-based template parts in classic themes - ​https://github.com/WordPress/gutenberg/pull/42729.

Gutenberg tracking issue: ​https://github.com/WordPress/gutenberg/issues/43440
Trac ticket: https://core.trac.wordpress.org/ticket/56467

## Testing Instructions

Classic theme - TT1

• The new "Template Parts" menu shouldn't appear in Appearance.
• Users can't access the /wp-admin/site-editor.php path directly.

Block theme - TT2

• The new "Template Parts" menu shouldn't appear in Appearance.
• The "Editor" menu is accessible.
• The Site Editor works as before.

Themes with block-based templates part enabled
You can grab the testing theme from this repo - ​https://github.com/Mamaduka/block-fragments

• The new "Template Parts" menu is visible under Appearance.
• The menu redirects to the "Template Parts" list view.
• The "Site" and "Templates" navigation items aren't visible.

Warning
The last item will require the latest package update PR to be merged, and it might not be possible to test immediately.

LGTM pending the result of ​this discussion. 👍 Thanks @ramonjd!

That link doesn't seem to be working for me 😕 @costdev -- did you mean ​this discussion (about @access private and classes being final)? If so, has that been sufficiently ​answered by @ramonjd?

I'd love if we could land this PR soon, as it blocks a number of other Style Engine related PRs 😊
@andrewserong maybe you can help out a bit? 🙏

That's right @ockham, not sure why the original link isn't working.

I think we're waiting on feedback from @aristath and @andrewsong on that topic. Not sure if @azaozz has anything more to add as well.

Refresh of #3203.

• Fixes 2 failing unit tests (depends on blocking #3199).
• Updates DocBlock formatting to ​WP standards.

From ​original PR:

❗ BLOCKED by ​https://github.com/WordPress/wordpress-develop/pull/3199

Backporting typography block supports changes from Gutenberg to WP 6.1

See tracking issue: ​https://github.com/WordPress/gutenberg/issues/43440

### Gutenberg sync PR

Once this PR lands we can merge ​https://github.com/WordPress/gutenberg/pull/43928

### Main changes

• ​https://github.com/WordPress/gutenberg/pull/39529
• ​https://github.com/WordPress/gutenberg/pull/40332

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

Props @ramonjd.

I think we're waiting on feedback from @aristath and @AndrewSong on that topic.

For my part, I've been thinking about this, and I'm pretty confident that the function signatures and method names are fine for now. The classes have been running in Gutenberg for some time.

Ultimately the purpose of all this code is to accept block style input and output compiled CSS. I expect there'll be updates to the body of some functions, and probably unforeseen future conditions that will require new methods, and later, deprecations, but that's the story of WordPress.

The unknowns will remain unknowns :D

I'd lean on @aristath's and @AndrewSong's opinion though.

Thanks for pings!

For my part, I've been thinking about this, and I'm pretty confident that the function signatures and method names are fine for now. The classes have been running in Gutenberg for some time.

I agree, and like you mention in the thread, maintaining backwards compatibility is expected for the style engine classes. One of the things I believe @aristath had in mind with these classes was the eventual use cases of plugins and themes, so we ultimately do want these to be stable and well-supported classes with consistent public methods. The structure and naming of the public methods went through lots of iterations in the Gutenberg plugin and appears to be pretty stable now from my perspective.

I think this PR looks in a good shape to land, personally.

@ockham, I believe this one should be ready for final review/commit now that we've got approval from @tellthemachines (thanks!)

To recap:

• This PR does not require the style engine changes to be merged in first, as it doesn't change layout.php, so should be able to be safely committed at any time.
• Once the style engine PR is merged (​https://github.com/WordPress/wordpress-develop/pull/3199), I can put together a separate PR that backports layout.php.
• Once this PR and the style engine PR is merged, we can put together a separate PR to backport the spacing presets work (CC: @glendaviesnz).

As mentioned above, the Style Engine classes went through a lot of iterations and discussion. What we ended up with is a hierarchy and structure that is solid, stable, makes sense, and I feel it can withstand the test of time 👍

Good catch. The following PR ​https://github.com/WordPress/wordpress-develop/pull/3108 should resolve that issue. I want to wrap up the related refactoring this week.

This has now been merged; I've just rebased this PR to include the changes.

Good catch. The following PR #3108 should resolve that issue. I want to wrap up the related refactoring this week.

This has now been merged; I've just rebased this PR to include the changes.

Did it resolve the issue?

I see e2e tests failing. It looks like the new view file for the Navigation block is not present. My bet is that you need to list it in the webpack config here:

​https://github.com/WordPress/wordpress-develop/blob/3381f05fa241daf172d6c1c893fd25959c3b0656/tools/webpack/blocks.js#L152-L155

In the long run, we will have to find a more general solution, so it can be automatically detected like for other script and style types.

I see e2e tests failing. It looks like the new view file for the Navigation block is not present. My bet is that you need to list it in the webpack config here:

​https://github.com/WordPress/wordpress-develop/blob/3381f05fa241daf172d6c1c893fd25959c3b0656/tools/webpack/blocks.js#L152-L155

In the long run, we will have to find a more general solution, so it can be automatically detected like for other script and style types.

Add wp_theme_element_class_name() alias for the "internal" WP_Theme_JSON::get_element_class_name().

Backport of @c4rl0sbr4v0s' ​https://github.com/WordPress/gutenberg/pull/44099.

See ​this discussion for the rationale.

Note that I've opted not to replace calls to WP_Theme_JSON::get_element_class_name in the ​tests -- since those are specifically for the WP_Theme_JSON class.

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

[audrasjb]

In 54156:

Editor: Backport Style Engine API functions, classes and tests.

This PR migrates the Style Engine PHP functions, classes and tests into Core for 6.1. It backports the original [WordPress/gutenberg#40260 PR #40260] from Gutenberg repository.

Props ramonopoly, bernhard-reiter, costdev, azaozz, andrewserong, mukesh27, aristath.
See #56467.

Committed in https://core.trac.wordpress.org/changeset/54156

@ockham what is the status of the Warning in the description?

The last item will require the latest package update PR to be merged, and it might not be possible to test immediately.

@ockham what is the status of the Warning in the description?

The last item will require the latest package update PR to be merged, and it might not be possible to test immediately.

Ah, my bad, I should've elaborated on that. I was indeed able to test and confirm everything except for

The "Site" and "Templates" navigation items aren't visible.

As @Mamaduka said, we'll only be able to verify this once we've synced @wordpress/ packages. That ​sync is still blocked. However, I don't think we need to hold off until that package sync, since part of the logic responsible for conditionally showing the "Site" and "Templates" menu items lives in JS (and can be considered part of those packages, rather than the PHP that this PR touches).

In any case, we can easily test this separately once we sync packages.

Does that sound okay?

I see e2e tests failing. It looks like the new view file for the Navigation block is not present.

Right; I also get two PHP notices when testing locally:

Notice: Function register_block_script_handle was called incorrectly. The asset file for the "viewScript" defined in "core/navigation" block definition is missing. Please see [https://wordpress.org/support/article/debugging-in-wordpress/ Debugging in WordPress] for more information. (This message was added in version 5.5.0.) in /var/www/src/wp-includes/functions.php on line 5839

Notice: Function WP_Block_Type_Registry::register was called incorrectly. Block type names must contain a namespace prefix. Example: my-plugin/my-custom-block-type Please see [https://wordpress.org/support/article/debugging-in-wordpress/ Debugging in WordPress] for more information. (This message was added in version 5.0.0.) in /var/www/src/wp-includes/functions.php on line 5839

My bet is that you need to list it in the webpack config here:

​https://github.com/WordPress/wordpress-develop/blob/3381f05fa241daf172d6c1c893fd25959c3b0656/tools/webpack/blocks.js#L152-L155

Good guess 😄 The following fixes the first warning:

{{{diff
diff --git a/tools/webpack/blocks.js b/tools/webpack/blocks.js
index ab9fd926f0..e2060546ac 100644
--- a/tools/webpack/blocks.js
+++ b/tools/webpack/blocks.js
@@ -151,6 +151,7 @@ module.exports = function( env = { environment: 'production', watch: false, buil

entry: {

'file/view': join( baseDir, node_modules/@wordpress/block-library/build-module/file/view ),
'navigation/view': join( baseDir, node_modules/@wordpress/block-library/build-module/navigation/view ),

+ 'navigation/view-modal': join( baseDir, node_modules/@wordpress/block-library/build-module/navigation/view-modal ),

},
output: {

devtoolNamespace: 'wp',

}}}

(The second one is still there, though.)

[audrasjb]

In 54159:

Editor: Backport foundation for Layout block support refactor (part 1).

This change backports the following changes from Gutenberg repository:

• [WordPress/gutenberg#40875 gutenberg#40875] Layout: Use semantic classnames, centralize layout definitions, reduce duplication, and fix blockGap in theme.json
• [WordPress/gutenberg#42544 gutenberg#42544] Layout: Add a disable-layout-styles theme supports flag to opt out of all layout styles gutenberg#42544
• [WordPress/gutenberg#42087 gutenberg#42087] Theme.json: Add block support feature level selectors for blocks gutenberg#42087
• [WordPress/gutenberg#43792 gutenberg#43792] Global Styles: Split root layout rules into a different function gutenberg#43792
• [WordPress/gutenberg#42544 gutenberg#42544] Layout: Add a disable-layout-styles theme supports flag to opt out of all layout styles gutenberg#42544
• [WordPress/gutenberg#42665 gutenberg#42665] Layout: Reduce specificity of fallback blockGap styles gutenberg#42665
• [WordPress/gutenberg#42085 gutenberg#42085] Core CSS support for root padding and alignfull blocks gutenberg#42085

Note that it doesn't entirely port over PR40875 — the remaining PHP changes for that PR will be explored in a separate PR targeting layout.php.

Props andrewserong, aaronrobertshaw, isabel_brison.
See #56467.

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

Backports ​https://github.com/WordPress/gutenberg/pull/44015 ​https://github.com/WordPress/gutenberg/pull/44109 ​https://github.com/WordPress/gutenberg/pull/44159

This PR ports the work done in Gutenberg (to be released in 14.1) to add hooks to filter the theme.json data. Specifically, it adds the following filters: theme_json_default, theme_json_blocks, theme_json_themetheme_json_user.

[hellofromTonya]

In 54160:

Editor: Revert [54159].

Reverting changeset due to failing PHPUnit tests. Tests pass without changeset [54156], but fail with it. Reverting to explore why in the original PR after rebasing.

See #56467.

This PR was committed in https://core.trac.wordpress.org/changeset/54159. However, the added tests from this PR failed.

During investigation, I found that this PR tests pass when the Style Engine's commit is not applied, but fails when it is.

So this PR's commit was reverted.

Next step:

• [ ] Rebase this PR against the current trunk (which includes the Style Engines commit.
• [ ] Then investigate to find the root cause.
• [ ] Fix the root cause.

Then it'll be ready again for commit consideration.

This PR was committed in https://core.trac.wordpress.org/changeset/54159. However, the added tests from this PR failed.

FWIW, here's a ​link to the failing tests.

Sharing some more findings (also ​posted in Slack):

Weirdest thing, I tried rebasing locally but can’t reproduce the error here :thinking: (At least not when only running npm run test:php — --group=themes — running the full test suite now.)

Furthermore, it looks like ​https://github.com/WordPress/wordpress-develop/pull/3244 has ​the same test failures — and that PR has a totally unrelated change (introduces a new function as an alias for an existing class method).

Heisenbug? :confused:

Testing Report

Env:

• WordPress: trunk
• Plugins: none
• Browser: Firefox
• Localhost: wp-env

Results:

Classic theme - TT1

• The new "Template Parts" menu shouldn't appear in Appearance ✅
• Users can't access the /wp-admin/site-editor.php path directly ✅

Block theme - TT2

• The new "Template Parts" menu shouldn't appear in Appearance ✅
• The "Editor" menu is accessible ✅
• The Site Editor works as before ✅

Themes with block-based templates part enabled
Theme: ​https://github.com/Mamaduka/block-fragments

• The new "Template Parts" menu is visible under Appearance ✅
• The menu redirects to the "Template Parts" list view ✅
• The "Site" and "Templates" navigation items aren't visible ❌ (needs the JS packages updated - per notes in the description)

Observations:

• With the block-fragments (classic theme with block-based templates) enabled, I am able to directly access /wp-admin/site-editor.php but it's a white screen. No errors in the browser's console or error logs.

@Mamaduka @ockham Is this something that will be fixed with another backport? Or a known issue?

@ironprogrammer Thank you! The ​style engine PR has now been merged; would you mind rebasing this PR? 😊

Follow-up:

When applying this PR on top of the current trunk, the tests pass locally and within the CI. I opened a separate PR #3249 as a confidence check and to isolate the code changes. Tests pass ✅

During investigation, I found that this PR tests pass when the Style Engine's commit is not applied, but fails when it is.

Repeating this same process, tests pass locally in both cases ✅

This leads me to believe the issue from earlier may possibly be related to something within the wp-env remote deps, such as Docker, Composer, GitHub, etc. Whatever that something was, it appears to be resolved.

So, I'm recommitting this PR, but just to make sure, recommitting it on top of trunk.

Since the unit test errors seem spurious (​see), I'll try rebasing to kick them off again.

[hellofromTonya]

In 54162:

Editor: Backport foundation for Layout block support refactor (part 1).

Backports the following changes from the Gutenberg repository:

• [WordPress/gutenberg/40875 gutenberg/40875] Layout: Use semantic classnames, centralize layout definitions, reduce duplication, and fix blockGap in theme.json
• [WordPress/gutenberg/42544 gutenberg/42544] Layout: Add a disable-layout-styles theme supports flag to opt out of all layout styles gutenberg/42544
• [WordPress/gutenberg/42087 gutenberg/42087] Theme.json: Add block support feature level selectors for blocks gutenberg/42087
• [WordPress/gutenberg/43792 gutenberg/43792] Global Styles: Split root layout rules into a different function gutenberg/43792
• [WordPress/gutenberg/42544 gutenberg/42544] Layout: Add a disable-layout-styles theme supports flag to opt out of all layout styles gutenberg/42544
• [WordPress/gutenberg/42665 gutenberg/42665] Layout: Reduce specificity of fallback blockGap styles gutenberg/42665
• [WordPress/gutenberg/42085 gutenberg/42085] Core CSS support for root padding and alignfull blocks gutenberg/42085

Notes:

• It doesn't entirely port over PR 40875 — the remaining PHP changes for that PR will be explored in a separate PR targeting layout.php.
• [54159] was reverted in [54160] due to PHPUnit test failures for tests added by the commit. Later, tests passed when applied on top of trunk. There were various outages today of upstream wp-env dependencies, which likely were the root cause of the earlier failures. For historical tracking and to make sure, recommitting [54159] but instead on top of current trunk. See PR 3205 for more details.
• Giving additional props for those who did a deep dive investigation into the failed tests.

Follow-up to [54160], [54159].

Props andrewserong, aaronrobertshaw, isabel_brison, bernhard-reiter, hellofromTonya.
See #56467.

Committed via https://core.trac.wordpress.org/changeset/54162.

Refresh of #3219.

• Adds PHPunit test for new wp_register_persisted_preferences_meta function.
• Validates registration and structure of meta key.

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

Props noisysocks costdev talldan

Submitted refresh PR including unit test in ​https://github.com/WordPress/wordpress-develop/pull/3253.

@ockham Done!

CC @ramonjd.

Hmmm, the test failures may be related to #3199, which removes spaces between generated CSS attributes and values. Looking into it.

However, the tests in this PR are passing.

I think this looks good to me, but would be good to have someone else from core to take a look as well 🙂

❗ BLOCKED by ​https://github.com/WordPress/wordpress-develop/pull/3204

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

❗ BLOCKED by #3218 (that PR will output the layout styles generated by this PR, and needs to land first)

This PR is a follow-up to ​https://github.com/WordPress/wordpress-develop/pull/3205 and backports the remaining parts of the layout block support.

Note: the updates to the server test fixtures are all expected changes — the updates to the Layout support are that we now also output semantic classnames for the layout types (e.g. is-layout-flow or is-layout-flex). Also, the wp-container-xxx` classname will no longer be output for many blocks that use the default layout settings.

## To-do

• [x] ~Backport tests~
• [x] ~Ensure it's working on top of #3218~

To confirm that it's working, you can manually copy the changes from #3218 on top of this PR, and in the rendered view of TwentyTwentyTwo theme, the space between styling of the row block should be output correctly as in the screenshot below (note the highlighted layout classnames that have been added there, too is-layout-flex, etc):

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

@tellthemachines I believe this one is working correctly — it just depends on ​https://github.com/WordPress/wordpress-develop/pull/3218 in order for the generated styles to be output.

Props noisysocks costdev talldan

It's talldanwp on wordpress.org. Thanks for adding the tests. 😄

Hmmm, the test failures may be related to ​https://github.com/WordPress/wordpress-develop/pull/3199, which removes spaces between generated CSS attributes and values.

@ironprogrammer I think in this case I'd lean toward updating those existing tests. As you mention. the style engine intentionally defaults to not prettifying output, so inline styles therefore don't have spaces. Given that there'll be a slight mismatch until all of the block supports are merged, I wonder if the assert_content_and_styles_and_classes_match test function should be updated to be more permissive of spaces? (It currently normalizes spaces between property/value pairs, but not between the colon and the value here: ​https://github.com/WordPress/wordpress-develop/blob/trunk/tests/phpunit/tests/blocks/supportedStyles.php#L155)

I know there are quite a few failing tests, but just in case it helps, I believe it's expected that for the main test_get_stylesheet test it _will_ contain .wp-block-image{margin-bottom: 30px;}.wp-block-image img, .wp-block-image .wp-block-image__crop-area{border-top-left-radius: 10px;border-bottom-right-radius: 1em;} now that the image block's block.json file has been updated to use the feature level selector for border radius. So, the expected value of Tests_Theme_wpThemeJson::test_get_stylesheet will likely need to be updated in the test 🙂

perhaps @jorgefilipecosta or @gziolo can help?

Thanks a lot, @fabiankaegy! Looks like this PR is good to go, except for failing unit tests, which I think are due to this: ​https://github.com/WordPress/wordpress-develop/pull/3234/files#r971773508.

@Mamaduka If you're around, could you rebase and change that number to 23? 🙏

Fork of @Mamaduka's ​https://github.com/WordPress/wordpress-develop/pull/3234, to apply ​this small fix.

Quoting that PR's description:

## Testing Instructions
Classic theme - TT1

• The new "Template Parts" menu shouldn't appear in Appearance.
• Users can't access the /wp-admin/site-editor.php path directly.

Block theme - TT2

• The new "Template Parts" menu shouldn't appear in Appearance.
• The "Editor" menu is accessible.
• The Site Editor works as before.

Themes with block-based templates part enabled You can grab the testing theme from this repo - ​https://github.com/Mamaduka/block-fragments

• The new "Template Parts" menu is visible under Appearance.
• The menu redirects to the "Template Parts" list view.
• The "Site" and "Templates" navigation items aren't visible.

Warning
The last item will require the latest package update PR to be merged, and it might not be possible to test immediately.

For any other details, please see the ​original PR.

(@Mamaduka is AFK and gave me permission to fork his PR via DM.)

Gutenberg tracking issue: ​https://github.com/WordPress/gutenberg/issues/43440
Trac ticket: https://core.trac.wordpress.org/ticket/56467

@Mamaduka is currently AFK -- I've forked this PR and applied my fix: ​https://github.com/WordPress/wordpress-develop/pull/3258

@fabiankaegy Would you mind approving this PR? 😊

@fabiankaegy Would you mind approving this PR? 😊

I'm not sure whether I have sufficient access to actually approve it. But from my perspective this is ready to go :)

[audrasjb]

In 54174:

Editor: Backport wp_theme_element_class_name() alias.

This changeset backports the wp_theme_element_class_name() alias for the "internal" WP_Theme_JSON::get_element_class_name() function.

This is a backport of ​gutenberg/PR44099.

Note: this changeset doesn't replace calls to WP_Theme_JSON::get_element_class_name in the tests, since those are specifically for the WP_Theme_JSON class.

Props bernhard-reiter, cbravobernal, costdev.
See #56467.

Committed in https://core.trac.wordpress.org/changeset/54174

@ockham I'll let you close this PR if everything is ok :)

Oops, I closed it accidentally :D

Retested per my ​Test Report. Confirmed @fabiankaegy resolves the white screen issue of attempting to access /wp-admin/site-editor.php ✅

Testing Report

Env:

• WordPress: trunk
• Plugins: none
• Browser: Firefox
• Localhost: wp-env

Results:

Classic theme - TT1, TT0

• The new "Template Parts" menu shouldn't appear in Appearance ✅
• Users can't access the /wp-admin/site-editor.php path directly ✅

Block theme - TT2, Frost

• The new "Template Parts" menu shouldn't appear in Appearance ✅
• The "Editor" menu is accessible ✅
• The Site Editor works as before ✅

Themes with block-based templates part enabled
Theme: ​https://github.com/Mamaduka/block-fragments

• The new "Template Parts" menu is visible under Appearance ✅
• The menu redirects to the "Template Parts" list view ✅
• The "Site" and "Templates" navigation items aren't visible ❌ (needs the JS packages updated - per notes in the description)

Observations:

With the block-fragments (classic theme with block-based templates) enabled, I am able to directly access /wp-admin/site-editor.php but it's a white screen. No errors in the browser's console or error logs.

Fixed ✅ Now when attempting to go directly to /wp-admin/site-editor.php, the user gets an error as expected:

The theme you are currently using is not compatible with the Site Editor.

[audrasjb]

In 54175:

Editor: Backport build_query_vars_from_query_block changes from Gutenberg repository.

This changeset backports changes from the following Gutenberg pull requests:

• ​gutenberg#43590 Add a filter to build_query_vars_from_query_block
• ​gutenberg#40933 Block Library - Query Loop: Add parents filter

Props ntsekouras, bernhard-reiter.
See #56467.

Committed in https://core.trac.wordpress.org/changeset/54175

Oops, I closed it accidentally :D

No worries @audrasjb 😄 Thank you for committing!

I'll fork this so I can rebase and address @gziolo's suggestions.

🎼 _So Fresh, So Clean_ 🎶

This is a fork of @ramonjd's ​https://github.com/WordPress/wordpress-develop/pull/3218, to rebase it (now that ​https://github.com/WordPress/wordpress-develop/pull/3199 has been merged), and to address ​feedback by @gziolo.

Original PR desc:

Backporting changes to script-loader that enqueue block support styles stored by the style engine/

See tracking issue: ​WordPress/gutenberg#43440

### Backporting the following changes

• ​Style engine: enqueue block supports styles in Gutenberg gutenberg#42880

(​https://github.com/WordPress/gutenberg/pull/4288 has testing instructions.)

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

[hellofromTonya]

In 54176:

Themes: Introduces block-based template parts for Classic themes.

Allows Classic / Hybrid themes to use block-based template parts without using complete block-based templates.

• Exposes the Site Editor's template parts UI
• Adds Appearance > "Template Parts" menu
• Enabled within the theme via adding a theme support for 'block-template-parts'

  add_theme_support( 'block-template-parts' );
  

This is a backport from Gutenberg.​See WordPress/gutenberg PR 42729.

Follow-up to [52330], [52069], [52178].

Props mamaduka, fabiankaegy, poena, scruffian, manfcarlo, bernhard-reiter, hellofromTonya.
See #56467.

Thank you everyone for your contributions! Committed via https://core.trac.wordpress.org/ticket/56467.

Thank you everyone for your contributions! Committed PR 3258 (finalization of this PR) via https://core.trac.wordpress.org/ticket/56467.

I'll fork this so I can rebase and address @gziolo's suggestions.

​https://github.com/WordPress/wordpress-develop/pull/3259

Unit tests are failing 😕

1) Tests_Theme_wpGetGlobalStylesheet::test_should_enqueue_stored_styles
Registered styles with handle of "core-block-supports" do not match expected value from Style Engine store.
Failed asserting that two arrays are equal.
--- Expected
+++ Actual
@@ @@
 Array (
-    0 => '.saruman{color:white;height:100px;border-style:solid;}'
+    0 => '/**\n
+     * Core styles: block-supports\n
+     */\n
+    .saruman {\n
+    	color: white;\n
+    	height: 100px;\n
+    	border-style: solid;\n
+    }\n
+    '

Trac ticket: https://core.trac.wordpress.org/ticket/56467
Backports ​https://github.com/WordPress/gutenberg/pull/44189

This PR consolidates the name of a filter introduced in this cycle, renaming it from get_style_nodes to theme_json_get_style_nodes as to be more coherent with the other hooks that we introduce in 6.1 as well, see ​https://github.com/WordPress/wordpress-develop/pull/3247

Related PR ​https://github.com/WordPress/wordpress-develop/pull/3261

Rebased, now that ​https://github.com/WordPress/wordpress-develop/pull/3199 has landed.

Unit tests are failing -- apparently because of extra whitespace in the "expected" string. Errors look like this:

1) Test_Block_Supports_Border::test_border_color_slug_with_numbers_is_kebab_cased_properly
Failed asserting that two arrays are identical.
--- Expected
+++ Actual
@@ @@
 Array &0 (
     'class' => 'has-border-color has-red-border-color'
-    'style' => 'border-radius: 10px; border-style: dashed; border-width: 1px;'
+    'style' => 'border-radius:10px;border-style:dashed;border-width:1px;'
 )

/var/www/tests/phpunit/tests/block-supports/border.php:70
phpvfscomposer:///var/www/vendor/phpunit/phpunit/phpunit:97
/var/www/vendor/bin/phpunit:118

A similar issue seems to be present over at ​https://github.com/WordPress/wordpress-develop/pull/3237#issuecomment-1247405947

@spacedmonkey Are you happy with the REST code in this PR?

Closing in favor of PR #3253 which applies this PR and adds tests.

# Test Report

Env:

• OS: macOS Monterey
• Localhost: wp-env
• Plugins: none
• Theme: TT2
• Browsers: Chrome and Firefox

## Tests and Results
All tests will use Chrome and Firefox to check if preferences persist between browsers and on reload in same browser.

### Test 1: Posts UI

Changing preferences in one browser:

• should persist in same browser on page load ✅
• should persist in the other browser on page load ✅

### Test 2: Site Editor

Changing preferences in one browser:

• should persist in same browser on page load ✅
• should persist in the other browser on page load ✅

### Test 3: Should not change other UIs

Changing preferences in Post UI should not change Site Editor preferences ✅

[hellofromTonya]

In 54182:

Editor: Persist preferences in user meta.

Adds a new feature to persist editor UI preferences between page loads and browsers.

• Adds a new preferences persistence API.
• Saves editor preferences in user meta instead of in browser's local storage.

Why?
Due to the transient nature of browser storage, this persistence is not as sticky as it is expected to be, including: switching browsers (unique storage between browsers), or using private browsing tabs (storage cleared between sessions), or the same user across a network of sites (storage unique by domain).

This is a backport from Gutenberg.​See WordPress/gutenberg PR 39795.

Props talldanwp, youknowriad, noisysocks, mamaduka, costdev, ironprogrammer, hellofromTonya.
See #56467.

Committed via https://core.trac.wordpress.org/changeset/54182. Thank you everyone for your contributions!

Newer version in PR 3253 was committed via https://core.trac.wordpress.org/changeset/54182.

A similar issue seems to be present over at ​#3237 (comment) and ​https://github.com/WordPress/wordpress-develop/pull/3204#issuecomment-1248152841.

Superseded by #3237.

[SergeyBiryukov]

In 54183:

Editor: Finalize the theme_json_get_style_nodes hook name.

This consolidates the name of a filter introduced earlier in the 6.1 cycle, renaming it from get_style_nodes to theme_json_get_style_nodes as to be more coherent with the other hooks introduced in 6.1 as well.

This commit backports the original PR from Gutenberg repository:

• ​#44189 Use prefix 'theme_json_' in hooks related to theme.json

Reference: ​#3247 Add hooks to filter theme.json data.

Follow-up to [54118].

Props oandregal, scruffian, bernhard-reiter.
See #56467.

Thanks for the PR! Merged in r54183.

Thanks for the PR! Merged in r54183.

This is another fork of #3218, to attempt to fix the tests that are broken in #3259 (this PR is a direct copy + paste of #3259, with an update to the tests to expect different results depending on the value of SCRIPT_DEBUG).

Original PR desc:

Backporting changes to script-loader that enqueue block support styles stored by the style engine/

See tracking issue: ​https://github.com/WordPress/gutenberg/issues/43440

Backporting the following changes

• ​https://github.com/WordPress/gutenberg/pull/42880

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

A similar issue seems to be present over at ​https://github.com/WordPress/wordpress-develop/pull/3237#issuecomment-1247405947 and ​https://github.com/WordPress/wordpress-develop/pull/3204#issuecomment-1248152841.

I believe the test failure with this one is slightly different to those other two PRs. For the other two PRs, the inline styles tests likely need to be updated to either expect no space between the colon and the value (since the style engine intentionally switched inline style output to remove the space), or for the tests to be more permissive of spaces (i.e. remove spaces between property + colon and value before doing the comparison).

For this one, I think the issue is that (inferring from the test failures) the tests in core appear to be run with SCRIPT_DEBUG set, which switches on prettify for the stored styles output on the followings lines: ​https://github.com/WordPress/wordpress-develop/blob/trunk/src/wp-includes/style-engine/class-wp-style-engine-processor.php#L104, and ​https://github.com/WordPress/wordpress-develop/blob/trunk/src/wp-includes/script-loader.php#L2990

As far as I can tell, for these tests, the SCRIPT_DEBUG value is determined here: ​https://github.com/WordPress/wordpress-develop/blob/trunk/src/wp-includes/default-constants.php#L108 (if I switch that line to $develop_src = false; then the tests pass for me locally).

So, what's the best fix for these particular tests? Given that SCRIPT_DEBUG appears to be set in default-constants.php based on whether or not the current WP version has -src, I was wondering if we should make the tests factor in whether SCRIPT_DEBUG is set to determine which value to expect.

I've opened up (yet another 😅) fork of this changeset in #3262 to try that out. But feel free to close that / copy + paste anything from there if it's helpful.

Thanks for all the feedback @costdev! I believe I've implemented it all, so this should be ready for another look now 🙂

Also, in testing #3254 and #3259 together with this branch, the site editor isn't loading. I'm not seeing any actual errors, so it's very hard to tell what's wrong, but I'm guessing it's one of the not yet commited PHP backports that's missing 😅

@gziolo addressed your feedback.

Thank for you for advancing this one!! 🙇

I'll rebase and fix. Sorry, was out of action last week.

So, what's the best fix for these particular tests? Given that SCRIPT_DEBUG appears to be set in default-constants.php based on whether or not the current WP version has -src, I was wondering if we should make the tests factor in whether SCRIPT_DEBUG is set to determine which value to expect.

Thanks for looking into this folks. Sorry I was out of action last week.

Yeah, while I was running these tests locally SCRIPT_DEBUG was activated and I didn't get time to go deeper.

There was a recent change to wp_style_engine_get_stylesheet_from_context however that adds an options arg, through which we can set prettify => true. Maybe we could update the function signature of wp_enqueue_stored_styles() to be able to pass that down?

Maybe we could update the function signature of wp_enqueue_stored_styles() to be able to pass that down?
Would that be kosher?

Passing options to that function sounds like a good idea to me, given that we're supporting options args for most of the public style engine methods, and it'd make the a bit more explicit (e.g. we could test both prettified and non-prettified if we wanted to) 👍

Passing options to that function sounds like a good idea to me, given that we're supporting options args for most of the public style engine methods, and it'd make the a bit more explicit (e.g. we could test both prettified and non-prettified if we wanted to)

Okey dokey! I'll update this PR, but let's keep ​https://github.com/WordPress/wordpress-develop/pull/3262 just in case there are doubts. 🙇

@costdev fyi there is now some discussion going on about whether the t-shirt size style labels will be dropped for 6.1, so need to wait for a decision on that and will then update this PR accordingly.

Thanks for the update @glendaviesnz!

Unit tests are failing -- apparently because of extra whitespace in the "expected" string. Errors look like this:

@ockham Good to go I think.

There was a recent change to wp_style_engine_get_stylesheet_from_context however that adds an options arg, through which we can set prettify => true/false. Maybe we could update the function signature of wp_enqueue_stored_styles() to be able to pass that down?

@ockham I've added a Gutenberg PR with the proposed changes mentioned in the ​comment above.

​https://github.com/WordPress/gutenberg/pull/44248

Happy to refork this PR with the changes if you don't have the bandwidth to port them across to this PR.

This PR backports the following Gutenberg PR: ​https://github.com/WordPress/gutenberg/pull/41972. Note that box-shadow is already listed in PROPERTIES_METADATA so that line has already been backported.

See tracking issue: ​https://github.com/WordPress/gutenberg/issues/43440

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

🎼 So much, So much clean 🎶

This is combination of of @ockham's changes in ​https://github.com/WordPress/wordpress-develop/pull/3259, which is a fork of @ramonjd's ​https://github.com/WordPress/wordpress-develop/pull/3218.

The purpose here is to

• rebase
• implement the changes in the review: ​https://github.com/WordPress/wordpress-develop/pull/3259#pullrequestreview-1111647799
• allow a way to bypass SCRIPT_DEBUG in tests. See ​comment and the ​Gutenberg PR

Original PR desc:

Backporting changes to script-loader that enqueue block support styles stored by the style engine

See tracking issue: ​https://github.com/WordPress/gutenberg/issues/43440

Backporting the following changes
​https://github.com/WordPress/gutenberg/pull/42880
(​https://github.com/WordPress/gutenberg/pull/4288 has testing instructions.)

Props to @gziolo and @ockham

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

Happy to refork this PR with the changes if you don't have the bandwidth to port them across to this PR.

Update PR here: ​https://github.com/WordPress/wordpress-develop/pull/3273

If you're happy with that, we can close this PR

Thank you @ramonjd! Closing in favor of #3273.

Should we also add it to remove_insecure_properties?

Currently testing and reviewing. When ready, will do the commit.

[hellofromTonya]

In 54204:

Editor: Fix function name case in wp_default_packages_inline_scripts().

Fixes function name typo by changing from uppercase get_current_user_ID() to lowercase get_current_user_id().

Note: Function names are case-insensitive for the ASCII characters A to Z, though it is usually good form to call functions as they appear in their declaration.

​As per the PHP manual, PHP functions are case-insensitive, meaning the code runs. However, this fix is necessary for consistency, maintainability, and future-proofing.

Follow-up to [54182].

Unprop hellofromTonya.
See #56467.

Update: I've created the ​`wp/6.1` branch in Gutenberg with ~35 PRs that were marked for backporting to WP.

Unfortunately, ​my attempt to release a new round of npm packages failed with

Error: lerna ERR! packages/components/src/form-token-field/index.tsx(13,23): error TS2307: Cannot find module '@wordpress/a11y' or its corresponding type declarations.

​241

Error: lerna ERR! packages/components/src/higher-order/with-spoken-messages/index.js(5,23): error TS2307: Cannot find module '@wordpress/a11y' or its corresponding type declarations.

​242

Error: lerna ERR! packages/components/src/tools-panel/tools-panel-header/component.tsx(9,23): error TS2307: Cannot find module '@wordpress/a11y' or its corresponding type declarations.

Investigating now.

[desrosj]

In 54210:

Coding Standards: Various alignment fixes from composer format.

Follow up to [53874], [54097], [54110], [54155], [54162], [54184].

See #39210, #55443, #56288, #56092, #56408, #56467, #55881.

[audrasjb]

In 54211:

Editor: Backport block supports (border, color, elements, spacing) from Gutenberg to WP 6.1.

This changeset backports border, color, elements and spacing block supports changes from Gutenberg to WP 6.1.

See tracking issue on Gutenberg repository: ​gutenberg#43440.

Props ramonopoly, glendaviesnz, bernhard-reiter, audrasjb, costdev.
See #56467.

Committed in https://core.trac.wordpress.org/changeset/54211

cc/ for Components and TS expertise

I've tried building Gutenberg on the wp/6.1 branch and everything seems to work fine there.

Since the problem seems to be about referencing the @wordpress/a11y package, could you try making this change to see if it fixes it?

{{{diff
diff --git a/packages/components/tsconfig.json b/packages/components/tsconfig.json
index 87003dbf56..67c51cc136 100644
--- a/packages/components/tsconfig.json
+++ b/packages/components/tsconfig.json
@@ -18,6 +18,7 @@

"strictNullChecks": true

},
"references": [

+ { "path": "../a11y" },

{ "path": "../compose" },
{ "path": "../date" },
{ "path": "../deprecated" },

}}}

[audrasjb]

In 54214:

Editor: Backport block supports filter callback, registrations and tests to 6.1.

This changeset backports the following changes:

• Implement ​gutenberg#42880: Backport script loader: enqueue stored block supports styles
• Allow a way to bypass SCRIPT_DEBUG in tests. See ​comment and the related ​Gutenberg pull request

Props ramonopoly, gziolo, bernhard-reiter, audrasjb, costdev.
See #56467.

Committed in https://core.trac.wordpress.org/changeset/54214

Thanks for all the help, folks!

@ciampo I've added the fix that you suggested in ​https://github.com/WordPress/gutenberg/pull/44277

I think this also needs to be cherry picked into the wp/6.1 branch if I'm not mistaken for the package publish to work.

spacingScale in this context is the name of the test method's argument rather than the method being tested, which should match $spacing_scale in the test method's signature.

🤦 so it is, doh! fixed.

Alrighty, now that ​https://github.com/WordPress/wordpress-develop/pull/3273 has landed, it looks like this one should be good to commit now CC: @ockham

Closing now that ​https://github.com/WordPress/wordpress-develop/pull/3273 has landed instead.

Thanks for taking a look @scruffian! I double checked, and it looks like we don't need to manually specify it in remove_insecure_properties because when ​`remove_insecure_styles` is called, it'll do the lookup in compute_style_properties to static::PROPERTIES_METADATA which already includes the box-shadow key. So, I believe it's already handled 👍

I've given this a rebase, and confirmed that it's still working correctly on top of trunk 👍

[desrosj]

In 54238:

Coding Standards: Applying an alignment fix from running composer format.

Follow up to [54214].

See #56467.

I think this should be good to merge, pending @costdev double checking the switch to (string) casting

@ciampo I've added the fix that you suggested in ​WordPress/gutenberg#44277

I think this also needs to be cherry picked into the wp/6.1 branch if I'm not mistaken for the package publish to work.

Thank you! Hopefully it will solve the issue flagged above

​Packages have been updated. Nice done!! 🎉 🚀

Amazing! I'll re-sync now.

Amazing! I'll re-sync now.

Didn't work; it seems that the sync script isn't picking up all the wp/6.1 dist-tags (e.g. for @wordpress/block-library, it's using v7.3.14, which corresponds to wp-6.0.

It appears that the reason might be that some packages didn't get their dist-tags added upon publishing. @gziolo is helping me resolve this (likely by a forced re-publishing).

Thank you @spacedmonkey and @ntsekouras!

Unfortunately, it seems like ​unit tests are failing:

1) Tests_REST_WpRestTemplatesController::test_get_template_fallback
Trying to get property 'slug' of non-object

/var/www/tests/phpunit/tests/rest-api/wpRestTemplatesController.php:766
phpvfscomposer:///var/www/vendor/phpunit/phpunit/phpunit:97
/var/www/vendor/bin/phpunit:118

[audrasjb]

In 54251:

Editor: Backport hooks to filter theme.json data from Gutenberg to 6.1.

This changeset ports the work done in Gutenberg (released in 14.1) to add hooks to filter the theme.json data. Specifically, it adds the following filters: theme_json_default, theme_json_blocks, theme_json_theme, and theme_json_user.

For more details, see the following Gutenberg pull requests:

• ​gutenberg#44015: Make global styles data filterable
• ​gutenberg#44109: Prepare WP_Theme_JSON_Data class for backporting
• ​gutenberg#44159: Update hook's names from global_styles_* to theme_json_*

Props oandregal, czapla, gziolo, bernhard-reiter.
See #56467.

Backported in https://core.trac.wordpress.org/changeset/54251

Is there any way that we can write some unit tests for this? I feel like we have not kept up with the new settings and styles allowed in theme.json. Our ​test theme is missing ​quite a few of the items listed in the reference.

I think this fine to merge in as is, but I'd like to open a ticket to expand our theme.json testing.

Okay, this seems to be running without any glaring fatals or errors now. @c4rl0sbr4v0 and I will give it a bit of smoke-testing, and @gziolo has kindly agreed to commit to Core once we've covered that.

[desrosj]

In 54253:

Editor: Add box-shadow support for blocks through theme.json files.

This makes it possible to add box-shadow to specific blocks (such as buttons or groups), allowing this to be configured in block themes without custom CSS.

Props andrewserong, cbravobernal, madhudollu, scruffian, onemaggie.
See #56467.

There were 2 failures:

1) Tests_Theme_wpThemeJson::test_get_stylesheet_support_for_shorthand_and_longhand_values
Failed asserting that two strings are identical.
--- Expected
+++ Actual
@@ @@
-'body { margin: 0; }.wp-site-blocks > .alignleft { float: left; margin-right: 2em; }.wp-site-blocks > .alignright { float: right; margin-left: 2em; }.wp-site-blocks > .aligncenter { justify-content: center; margin-left: auto; margin-right: auto; }.wp-block-group{border-radius: 10px;margin: 1em;padding: 24px;}.wp-block-image{border-top-left-radius: 10px;border-bottom-right-radius: 1em;margin-bottom: 30px;padding-top: 15px;}'
+'body { margin: 0; }.wp-site-blocks > .alignleft { float: left; margin-right: 2em; }.wp-site-blocks > .alignright { float: right; margin-left: 2em; }.wp-site-blocks > .aligncenter { justify-content: center; margin-left: auto; margin-right: auto; }.wp-block-group{border-radius: 10px;margin: 1em;padding: 24px;}.wp-block-image{margin-bottom: 30px;padding-top: 15px;}.wp-block-image img, .wp-block-image .wp-block-image__crop-area{border-top-left-radius: 10px;border-bottom-right-radius: 1em;}'

/var/www/tests/phpunit/tests/theme/wpThemeJson.php:370
phpvfscomposer:///var/www/vendor/phpunit/phpunit/phpunit:97
/var/www/vendor/bin/phpunit:118

2) Tests_Theme_wpThemeJson::test_get_stylesheet
Failed asserting that two strings are identical.
--- Expected
+++ Actual
@@ @@
-'body{--wp--preset--color--grey: grey;--wp--preset--font-family--small: 14px;--wp--preset--font-family--big: 41px;}.wp-block-group{--wp--custom--base-font: 16;--wp--custom--line-height--small: 1.2;--wp--custom--line-height--medium: 1.4;--wp--custom--line-height--large: 1.8;}body { margin: 0; }.wp-site-blocks > .alignleft { float: left; margin-right: 2em; }.wp-site-blocks > .alignright { float: right; margin-left: 2em; }.wp-site-blocks > .aligncenter { justify-content: center; margin-left: auto; margin-right: auto; }body{color: var(--wp--preset--color--grey);}a:where(:not(.wp-element-button)){background-color: #333;color: #111;}.wp-block-group{border-radius: 10px;padding: 24px;}.wp-block-group a:where(:not(.wp-element-button)){color: #111;}h1,h2,h3,h4,h5,h6{color: #123456;}h1 a:where(:not(.wp-element-button)),h2 a:where(:not(.wp-element-button)),h3 a:where(:not(.wp-element-button)),h4 a:where(:not(.wp-element-button)),h5 a:where(:not(.wp-element-button)),h6 a:where(:not(.wp-element-button)){background-color: #333;color: #111;font-size: 60px;}.wp-block-post-date{color: #123456;}.wp-block-post-date a:where(:not(.wp-element-button)){background-color: #777;color: #555;}.wp-block-image{border-top-left-radius: 10px;border-bottom-right-radius: 1em;margin-bottom: 30px;}.has-grey-color{color: var(--wp--preset--color--grey) !important;}.has-grey-background-color{background-color: var(--wp--preset--color--grey) !important;}.has-grey-border-color{border-color: var(--wp--preset--color--grey) !important;}.has-small-font-family{font-family: var(--wp--preset--font-family--small) !important;}.has-big-font-family{font-family: var(--wp--preset--font-family--big) !important;}'
+'body{--wp--preset--color--grey: grey;--wp--preset--font-family--small: 14px;--wp--preset--font-family--big: 41px;}.wp-block-group{--wp--custom--base-font: 16;--wp--custom--line-height--small: 1.2;--wp--custom--line-height--medium: 1.4;--wp--custom--line-height--large: 1.8;}body { margin: 0; }.wp-site-blocks > .alignleft { float: left; margin-right: 2em; }.wp-site-blocks > .alignright { float: right; margin-left: 2em; }.wp-site-blocks > .aligncenter { justify-content: center; margin-left: auto; margin-right: auto; }body{color: var(--wp--preset--color--grey);}a:where(:not(.wp-element-button)){background-color: #333;color: #111;}.wp-block-group{border-radius: 10px;padding: 24px;}.wp-block-group a:where(:not(.wp-element-button)){color: #111;}h1,h2,h3,h4,h5,h6{color: #123456;}h1 a:where(:not(.wp-element-button)),h2 a:where(:not(.wp-element-button)),h3 a:where(:not(.wp-element-button)),h4 a:where(:not(.wp-element-button)),h5 a:where(:not(.wp-element-button)),h6 a:where(:not(.wp-element-button)){background-color: #333;color: #111;font-size: 60px;}.wp-block-post-date{color: #123456;}.wp-block-post-date a:where(:not(.wp-element-button)){background-color: #777;color: #555;}.wp-block-image{margin-bottom: 30px;}.wp-block-image img, .wp-block-image .wp-block-image__crop-area{border-top-left-radius: 10px;border-bottom-right-radius: 1em;}.has-grey-color{color: var(--wp--preset--color--grey) !important;}.has-grey-background-color{background-color: var(--wp--preset--color--grey) !important;}.has-grey-border-color{border-color: var(--wp--preset--color--grey) !important;}.has-small-font-family{font-family: var(--wp--preset--font-family--small) !important;}.has-big-font-family{font-family: var(--wp--preset--font-family--big) !important;}'

/var/www/tests/phpunit/tests/theme/wpThemeJson.php:559
phpvfscomposer:///var/www/vendor/phpunit/phpunit/phpunit:97
/var/www/vendor/bin/phpunit:118

Let's just make those tests pass for now. It's far more important to get Beta 1 out. We can iron out the details later.

Creating and editing a post, page, and template seems to work ✅

I cannot currently add a new template for a specific single post. The console shows

I'm pretty sure that the reason is that we're still missing ​https://github.com/WordPress/wordpress-develop/pull/3221.

Let's just make those tests pass for now. It's far more important to get Beta 1 out. We can iron out the details later.

a48592f

Prepping commit now.

I cannot currently add a new template for a specific single post. [...]
I'm pretty sure that the reason is that we're still missing #3221.

Tested. Confirming that #3221 fixes the issue.

Unit tests are passing. The "Test NPM" job was failing on Windows; re-running.

Unit tests are passing. The "Test NPM" job was failing on Windows; re-running.

FWIW, ​this was the failing test.

{{{diff
diff --git a/src/wp-includes/assets/script-loader-packages.php b/src/wp-includes/assets/script-loader-packages.php
index 928fea9..18391b1 100644
--- a/src/wp-includes/assets/script-loader-packages.php
+++ b/src/wp-includes/assets/script-loader-packages.php
@@ -1 +1 @@
-<?php return array('a11y.js' => array('dependencies' => array('wp-dom-ready', 'wp-i18n', 'wp-polyfill'), 'version' => '244c44f9a93417bf7ee1'), 'annotations.js' => array('dependencies' => array('wp-data', 'wp-hooks', 'wp-i18n', 'wp-polyfill', 'wp-rich-text'), 'version' => '893ac6701ec077e6dcb6'), 'api-fetch.js' => array('dependencies' => array('wp-i18n', 'wp-polyfill', 'wp-url'), 'version' => 'f59d87e74ca8fde7e1cf'), 'autop.js' => array('dependencies' => array('wp-polyfill'), 'version' => '99a75943cc81a0674863'), 'blob.js' => array('dependencies' => array('wp-polyfill'), 'version' => '7bf7275e6b4bcbb1b06b'), 'block-directory.js' => array('dependencies' => array('lodash', 'wp-a11y', 'wp-api-fetch', 'wp-block-editor', 'wp-blocks', 'wp-components', 'wp-compose', 'wp-core-data', 'wp-data', 'wp-edit-post', 'wp-editor', 'wp-element', 'wp-hooks', 'wp-html-entities', 'wp-i18n', 'wp-notices', 'wp-plugins', 'wp-polyfill', 'wp-primitives', 'wp-url'), 'version' => '57b629d7d20895f6feb4'), 'block-editor.js' => array('dependencies' => array('lodash', 'react', 'react-dom', 'wp-a11y', 'wp-api-fetch', 'wp-blob', 'wp-blocks', 'wp-components', 'wp-compose', 'wp-data', 'wp-date', 'wp-deprecated', 'wp-dom', 'wp-element', 'wp-hooks', 'wp-html-entities', 'wp-i18n', 'wp-is-shallow-equal', 'wp-keyboard-shortcuts', 'wp-keycodes', 'wp-notices', 'wp-polyfill', 'wp-primitives', 'wp-rich-text', 'wp-shortcode', 'wp-style-engine', 'wp-token-list', 'wp-url', 'wp-warning', 'wp-wordcount'), 'version' => '330661e04977340703c1'), 'block-library.js' => array('dependencies' => array('lodash', 'wp-a11y', 'wp-api-fetch', 'wp-autop', 'wp-blob', 'wp-block-editor', 'wp-blocks', 'wp-components', 'wp-compose', 'wp-core-data', 'wp-data', 'wp-date', 'wp-deprecated', 'wp-dom', 'wp-element', 'wp-hooks', 'wp-html-entities', 'wp-i18n', 'wp-keycodes', 'wp-notices', 'wp-polyfill', 'wp-primitives', 'wp-reusable-blocks', 'wp-rich-text', 'wp-server-side-render', 'wp-url', 'wp-viewport'), 'version' => '81fc975ecb2f6513563d'), 'block-serialization-default-parser.js' => array('dependencies' => array('wp-polyfill'), 'version' => '43a791a8f65b406dcf6e'), 'blocks.js' => array('dependencies' => array('lodash', 'wp-autop', 'wp-blob', 'wp-block-serialization-default-parser', 'wp-data', 'wp-deprecated', 'wp-dom', 'wp-element', 'wp-hooks', 'wp-html-entities', 'wp-i18n', 'wp-is-shallow-equal', 'wp-polyfill', 'wp-shortcode'), 'version' => '84b31e24a5dcfd9a211a'), 'components.js' => array('dependencies' => array('lodash', 'react', 'react-dom', 'wp-a11y', 'wp-compose', 'wp-date', 'wp-deprecated', 'wp-dom', 'wp-element', 'wp-escape-html', 'wp-hooks', 'wp-i18n', 'wp-is-shallow-equal', 'wp-keycodes', 'wp-polyfill', 'wp-primitives', 'wp-rich-text', 'wp-warning'), 'version' => 'f3eecee8c7cf1dd6fe02'), 'compose.js' => array('dependencies' => array('lodash', 'react', 'wp-deprecated', 'wp-dom', 'wp-element', 'wp-is-shallow-equal', 'wp-keycodes', 'wp-polyfill', 'wp-priority-queue'), 'version' => '2c9864f99e54e6a412fb'), 'core-data.js' => array('dependencies' => array('lodash', 'wp-api-fetch', 'wp-blocks', 'wp-data', 'wp-deprecated', 'wp-element', 'wp-html-entities', 'wp-i18n', 'wp-is-shallow-equal', 'wp-polyfill', 'wp-url'), 'version' => '8986842760ed009336e7'), 'customize-widgets.js' => array('dependencies' => array('lodash', 'wp-a11y', 'wp-block-editor', 'wp-block-library', 'wp-blocks', 'wp-components', 'wp-compose', 'wp-core-data', 'wp-data', 'wp-deprecated', 'wp-dom', 'wp-element', 'wp-hooks', 'wp-i18n', 'wp-is-shallow-equal', 'wp-keyboard-shortcuts', 'wp-keycodes', 'wp-media-utils', 'wp-plugins', 'wp-polyfill', 'wp-preferences', 'wp-primitives', 'wp-viewport', 'wp-widgets'), 'version' => 'b165300535f3582f00a2'), 'data.js' => array('dependencies' => array('lodash', 'react', 'wp-compose', 'wp-deprecated', 'wp-element', 'wp-is-shallow-equal', 'wp-polyfill', 'wp-priority-queue', 'wp-redux-routine'), 'version' => '827e018f15f15503125b'), 'data-controls.js' => array('dependencies' => array('wp-api-fetch', 'wp-data', 'wp-deprecated', 'wp-polyfill'), 'version' => '0cc5547e380ef9f1c7ec'), 'date.js' => array('dependencies' => array('moment', 'wp-deprecated', 'wp-polyfill'), 'version' => 'efa7260f1463958fe21e'), 'deprecated.js' => array('dependencies' => array('wp-hooks', 'wp-polyfill'), 'version' => '7fa61079bfa3bb9e4142'), 'dom.js' => array('dependencies' => array('wp-deprecated', 'wp-polyfill'), 'version' => 'c969c4fa9f781c46a8b7'), 'dom-ready.js' => array('dependencies' => array('wp-polyfill'), 'version' => '6a6a486214dcad1a08d6'), 'edit-post.js' => array('dependencies' => array('lodash', 'wp-a11y', 'wp-api-fetch', 'wp-block-editor', 'wp-block-library', 'wp-blocks', 'wp-components', 'wp-compose', 'wp-core-data', 'wp-data', 'wp-deprecated', 'wp-editor', 'wp-element', 'wp-hooks', 'wp-i18n', 'wp-keyboard-shortcuts', 'wp-keycodes', 'wp-media-utils', 'wp-notices', 'wp-plugins', 'wp-polyfill', 'wp-preferences', 'wp-primitives', 'wp-url', 'wp-viewport', 'wp-warning'), 'version' => '574aa48f83cfec8a7d8d'), 'edit-site.js' => array('dependencies' => array('lodash', 'react', 'wp-a11y', 'wp-api-fetch', 'wp-block-editor', 'wp-block-library', 'wp-blocks', 'wp-components', 'wp-compose', 'wp-core-data', 'wp-data', 'wp-deprecated', 'wp-editor', 'wp-element', 'wp-hooks', 'wp-html-entities', 'wp-i18n', 'wp-keyboard-shortcuts', 'wp-keycodes', 'wp-media-utils', 'wp-notices', 'wp-plugins', 'wp-polyfill', 'wp-preferences', 'wp-primitives', 'wp-reusable-blocks', 'wp-style-engine', 'wp-url', 'wp-viewport'), 'version' => '429c0a044401d5998532'), 'edit-widgets.js' => array('dependencies' => array('wp-a11y', 'wp-api-fetch', 'wp-block-editor', 'wp-block-library', 'wp-blocks', 'wp-components', 'wp-compose', 'wp-core-data', 'wp-data', 'wp-deprecated', 'wp-dom', 'wp-element', 'wp-hooks', 'wp-i18n', 'wp-keyboard-shortcuts', 'wp-keycodes', 'wp-media-utils', 'wp-notices', 'wp-plugins', 'wp-polyfill', 'wp-preferences', 'wp-primitives', 'wp-reusable-blocks', 'wp-url', 'wp-viewport', 'wp-widgets'), 'version' => '69391d0ec3a30136b335'), 'editor.js' => array('dependencies' => array('lodash', 'react', 'wp-a11y', 'wp-api-fetch', 'wp-blob', 'wp-block-editor', 'wp-blocks', 'wp-components', 'wp-compose', 'wp-core-data', 'wp-data', 'wp-date', 'wp-deprecated', 'wp-element', 'wp-hooks', 'wp-html-entities', 'wp-i18n', 'wp-keyboard-shortcuts', 'wp-keycodes', 'wp-media-utils', 'wp-notices', 'wp-polyfill', 'wp-preferences', 'wp-primitives', 'wp-reusable-blocks', 'wp-rich-text', 'wp-server-side-render', 'wp-url', 'wp-wordcount'), 'version' => '2841559daaf3eab166c7'), 'element.js' => array('dependencies' => array('react', 'react-dom', 'wp-escape-html', 'wp-polyfill'), 'version' => '72d791ff772f57f909bc'), 'escape-html.js' => array('dependencies' => array('wp-polyfill'), 'version' => 'f03a1f6b853601ea5727'), 'format-library.js' => array('dependencies' => array('wp-a11y', 'wp-block-editor', 'wp-components', 'wp-data', 'wp-element', 'wp-html-entities', 'wp-i18n', 'wp-polyfill', 'wp-primitives', 'wp-rich-text', 'wp-url'), 'version' => 'c8b9af106157c1ccf597'), 'hooks.js' => array('dependencies' => array('wp-polyfill'), 'version' => 'e98e9677eea626b84eb0'), 'html-entities.js' => array('dependencies' => array('wp-polyfill'), 'version' => 'ce385179f5300ae6db81'), 'i18n.js' => array('dependencies' => array('wp-hooks', 'wp-polyfill'), 'version' => '7c78690c4305ba868cfc'), 'is-shallow-equal.js' => array('dependencies' => array('wp-polyfill'), 'version' => '25dcd1bfd2b5f3c7244a'), 'keyboard-shortcuts.js' => array('dependencies' => array('wp-data', 'wp-element', 'wp-keycodes', 'wp-polyfill'), 'version' => '811bdb5f7e5fd110de7e'), 'keycodes.js' => array('dependencies' => array('lodash', 'wp-i18n', 'wp-polyfill'), 'version' => '66946665aefd82736ddc'), 'list-reusable-blocks.js' => array('dependencies' => array('lodash', 'wp-api-fetch', 'wp-components', 'wp-compose', 'wp-element', 'wp-i18n', 'wp-polyfill'), 'version' => 'bce8311b0458ede2ace6'), 'media-utils.js' => array('dependencies' => array('wp-api-fetch', 'wp-blob', 'wp-element', 'wp-i18n', 'wp-polyfill'), 'version' => '626afea4c4aa9e456a99'), 'notices.js' => array('dependencies' => array('wp-data', 'wp-polyfill'), 'version' => '0f66d57d5cdcaff005c0'), 'nux.js' => array('dependencies' => array('wp-components', 'wp-compose', 'wp-data', 'wp-deprecated', 'wp-element', 'wp-i18n', 'wp-polyfill', 'wp-primitives'), 'version' => '8837d483fb9517ce88f6'), 'plugins.js' => array('dependencies' => array('wp-compose', 'wp-element', 'wp-hooks', 'wp-polyfill', 'wp-primitives'), 'version' => '4cd7b4f6c714e2559cfc'), 'preferences.js' => array('dependencies' => array('wp-a11y', 'wp-components', 'wp-data', 'wp-element', 'wp-i18n', 'wp-polyfill', 'wp-primitives'), 'version' => 'aae5a666f8cfa0d93709'), 'preferences-persistence.js' => array('dependencies' => array('wp-api-fetch', 'wp-polyfill'), 'version' => '44c460ec46ee90712073'), 'primitives.js' => array('dependencies' => array('wp-element', 'wp-polyfill'), 'version' => '38f6e27f8a1e8f693b3e'), 'priority-queue.js' => array('dependencies' => array('wp-polyfill'), 'version' => '5a1fd6a8ae8e953fe1e4'), 'redux-routine.js' => array('dependencies' => array('wp-polyfill'), 'version' => '527db1785e2c14e528f6'), 'reusable-blocks.js' => array('dependencies' => array('wp-block-editor', 'wp-blocks', 'wp-components', 'wp-core-data', 'wp-data', 'wp-element', 'wp-i18n', 'wp-notices', 'wp-polyfill', 'wp-primitives', 'wp-url'), 'version' => '3a0db84366be920dc0c5'), 'rich-text.js' => array('dependencies' => array('lodash', 'wp-a11y', 'wp-compose', 'wp-data', 'wp-deprecated', 'wp-element', 'wp-escape-html', 'wp-i18n', 'wp-keycodes', 'wp-polyfill'), 'version' => 'a41eadb991193e206903'), 'server-side-render.js' => array('dependencies' => array('lodash', 'wp-api-fetch', 'wp-blocks', 'wp-components', 'wp-compose', 'wp-data', 'wp-deprecated', 'wp-element', 'wp-i18n', 'wp-polyfill', 'wp-url'), 'version' => '48a4ea0fec5d64e9cb58'), 'shortcode.js' => array('dependencies' => array('wp-polyfill'), 'version' => 'c1c454988346d2631424'), 'style-engine.js' => array('dependencies' => array('lodash', 'wp-polyfill'), 'version' => 'adcc475b338c87d6c507'), 'token-list.js' => array('dependencies' => array('wp-polyfill'), 'version' => '3b1d1222b29af2b25a3d'), 'url.js' => array('dependencies' => array('wp-polyfill'), 'version' => 'c24becf21dc63719cde9'), 'viewport.js' => array('dependencies' => array('lodash', 'wp-compose', 'wp-data', 'wp-element', 'wp-polyfill'), 'version' => '7fe633c26840e189bfe8'), 'warning.js' => array('dependencies' => array('wp-polyfill'), 'version' => 'd40debb9656e971cde0c'), 'widgets.js' => array('dependencies' => array('lodash', 'wp-api-fetch', 'wp-block-editor', 'wp-blocks', 'wp-components', 'wp-compose', 'wp-core-data', 'wp-data', 'wp-element', 'wp-i18n', 'wp-notices', 'wp-polyfill', 'wp-primitives'), 'version' => '84b61ae6702ee7f94c59'), 'wordcount.js' => array('dependencies' => array('wp-polyfill'), 'version' => '4aeb247ba5c38cf72dde'));
+<?php return array('a11y.js' => array('dependencies' => array('wp-dom-ready', 'wp-i18n', 'wp-polyfill'), 'version' => '244c44f9a93417bf7ee1'), 'annotations.js' => array('dependencies' => array('wp-data', 'wp-hooks', 'wp-i18n', 'wp-polyfill', 'wp-rich-text'), 'version' => '893ac6701ec077e6dcb6'), 'api-fetch.js' => array('dependencies' => array('wp-i18n', 'wp-polyfill', 'wp-url'), 'version' => 'f59d87e74ca8fde7e1cf'), 'autop.js' => array('dependencies' => array('wp-polyfill'), 'version' => '99a75943cc81a0674863'), 'blob.js' => array('dependencies' => array('wp-polyfill'), 'version' => '7bf7275e6b4bcbb1b06b'), 'block-directory.js' => array('dependencies' => array('lodash', 'wp-a11y', 'wp-api-fetch', 'wp-block-editor', 'wp-blocks', 'wp-components', 'wp-compose', 'wp-core-data', 'wp-data', 'wp-edit-post', 'wp-editor', 'wp-element', 'wp-hooks', 'wp-html-entities', 'wp-i18n', 'wp-notices', 'wp-plugins', 'wp-polyfill', 'wp-primitives', 'wp-url'), 'version' => '57b629d7d20895f6feb4'), 'block-editor.js' => array('dependencies' => array('lodash', 'react', 'react-dom', 'wp-a11y', 'wp-api-fetch', 'wp-blob', 'wp-blocks', 'wp-components', 'wp-compose', 'wp-data', 'wp-date', 'wp-deprecated', 'wp-dom', 'wp-element', 'wp-hooks', 'wp-html-entities', 'wp-i18n', 'wp-is-shallow-equal', 'wp-keyboard-shortcuts', 'wp-keycodes', 'wp-notices', 'wp-polyfill', 'wp-primitives', 'wp-rich-text', 'wp-shortcode', 'wp-style-engine', 'wp-token-list', 'wp-url', 'wp-warning', 'wp-wordcount'), 'version' => '330661e04977340703c1'), 'block-library.js' => array('dependencies' => array('lodash', 'wp-a11y', 'wp-api-fetch', 'wp-autop', 'wp-blob', 'wp-block-editor', 'wp-blocks', 'wp-components', 'wp-compose', 'wp-core-data', 'wp-data', 'wp-date', 'wp-deprecated', 'wp-dom', 'wp-element', 'wp-hooks', 'wp-html-entities', 'wp-i18n', 'wp-keycodes', 'wp-notices', 'wp-polyfill', 'wp-primitives', 'wp-reusable-blocks', 'wp-rich-text', 'wp-server-side-render', 'wp-url', 'wp-viewport'), 'version' => '81fc975ecb2f6513563d'), 'block-serialization-default-parser.js' => array('dependencies' => array('wp-polyfill'), 'version' => '43a791a8f65b406dcf6e'), 'blocks.js' => array('dependencies' => array('lodash', 'wp-autop', 'wp-blob', 'wp-block-serialization-default-parser', 'wp-data', 'wp-deprecated', 'wp-dom', 'wp-element', 'wp-hooks', 'wp-html-entities', 'wp-i18n', 'wp-is-shallow-equal', 'wp-polyfill', 'wp-shortcode'), 'version' => '84b31e24a5dcfd9a211a'), 'components.js' => array('dependencies' => array('lodash', 'react', 'react-dom', 'wp-a11y', 'wp-compose', 'wp-date', 'wp-deprecated', 'wp-dom', 'wp-element', 'wp-escape-html', 'wp-hooks', 'wp-i18n', 'wp-is-shallow-equal', 'wp-keycodes', 'wp-polyfill', 'wp-primitives', 'wp-rich-text', 'wp-warning'), 'version' => 'b3679bd0882f16187c16'), 'compose.js' => array('dependencies' => array('lodash', 'react', 'wp-deprecated', 'wp-dom', 'wp-element', 'wp-is-shallow-equal', 'wp-keycodes', 'wp-polyfill', 'wp-priority-queue'), 'version' => '2c9864f99e54e6a412fb'), 'core-data.js' => array('dependencies' => array('lodash', 'wp-api-fetch', 'wp-blocks', 'wp-data', 'wp-deprecated', 'wp-element', 'wp-html-entities', 'wp-i18n', 'wp-is-shallow-equal', 'wp-polyfill', 'wp-url'), 'version' => '8986842760ed009336e7'), 'customize-widgets.js' => array('dependencies' => array('lodash', 'wp-a11y', 'wp-block-editor', 'wp-block-library', 'wp-blocks', 'wp-components', 'wp-compose', 'wp-core-data', 'wp-data', 'wp-deprecated', 'wp-dom', 'wp-element', 'wp-hooks', 'wp-i18n', 'wp-is-shallow-equal', 'wp-keyboard-shortcuts', 'wp-keycodes', 'wp-media-utils', 'wp-plugins', 'wp-polyfill', 'wp-preferences', 'wp-primitives', 'wp-viewport', 'wp-widgets'), 'version' => 'b165300535f3582f00a2'), 'data.js' => array('dependencies' => array('lodash', 'react', 'wp-compose', 'wp-deprecated', 'wp-element', 'wp-is-shallow-equal', 'wp-polyfill', 'wp-priority-queue', 'wp-redux-routine'), 'version' => '827e018f15f15503125b'), 'data-controls.js' => array('dependencies' => array('wp-api-fetch', 'wp-data', 'wp-deprecated', 'wp-polyfill'), 'version' => '0cc5547e380ef9f1c7ec'), 'date.js' => array('dependencies' => array('moment', 'wp-deprecated', 'wp-polyfill'), 'version' => 'efa7260f1463958fe21e'), 'deprecated.js' => array('dependencies' => array('wp-hooks', 'wp-polyfill'), 'version' => '7fa61079bfa3bb9e4142'), 'dom.js' => array('dependencies' => array('wp-deprecated', 'wp-polyfill'), 'version' => 'c969c4fa9f781c46a8b7'), 'dom-ready.js' => array('dependencies' => array('wp-polyfill'), 'version' => '6a6a486214dcad1a08d6'), 'edit-post.js' => array('dependencies' => array('lodash', 'wp-a11y', 'wp-api-fetch', 'wp-block-editor', 'wp-block-library', 'wp-blocks', 'wp-components', 'wp-compose', 'wp-core-data', 'wp-data', 'wp-deprecated', 'wp-editor', 'wp-element', 'wp-hooks', 'wp-i18n', 'wp-keyboard-shortcuts', 'wp-keycodes', 'wp-media-utils', 'wp-notices', 'wp-plugins', 'wp-polyfill', 'wp-preferences', 'wp-primitives', 'wp-url', 'wp-viewport', 'wp-warning'), 'version' => '574aa48f83cfec8a7d8d'), 'edit-site.js' => array('dependencies' => array('lodash', 'react', 'wp-a11y', 'wp-api-fetch', 'wp-block-editor', 'wp-block-library', 'wp-blocks', 'wp-components', 'wp-compose', 'wp-core-data', 'wp-data', 'wp-deprecated', 'wp-editor', 'wp-element', 'wp-hooks', 'wp-html-entities', 'wp-i18n', 'wp-keyboard-shortcuts', 'wp-keycodes', 'wp-media-utils', 'wp-notices', 'wp-plugins', 'wp-polyfill', 'wp-preferences', 'wp-primitives', 'wp-reusable-blocks', 'wp-style-engine', 'wp-url', 'wp-viewport'), 'version' => '429c0a044401d5998532'), 'edit-widgets.js' => array('dependencies' => array('wp-a11y', 'wp-api-fetch', 'wp-block-editor', 'wp-block-library', 'wp-blocks', 'wp-components', 'wp-compose', 'wp-core-data', 'wp-data', 'wp-deprecated', 'wp-dom', 'wp-element', 'wp-hooks', 'wp-i18n', 'wp-keyboard-shortcuts', 'wp-keycodes', 'wp-media-utils', 'wp-notices', 'wp-plugins', 'wp-polyfill', 'wp-preferences', 'wp-primitives', 'wp-reusable-blocks', 'wp-url', 'wp-viewport', 'wp-widgets'), 'version' => '69391d0ec3a30136b335'), 'editor.js' => array('dependencies' => array('lodash', 'react', 'wp-a11y', 'wp-api-fetch', 'wp-blob', 'wp-block-editor', 'wp-blocks', 'wp-components', 'wp-compose', 'wp-core-data', 'wp-data', 'wp-date', 'wp-deprecated', 'wp-element', 'wp-hooks', 'wp-html-entities', 'wp-i18n', 'wp-keyboard-shortcuts', 'wp-keycodes', 'wp-media-utils', 'wp-notices', 'wp-polyfill', 'wp-preferences', 'wp-primitives', 'wp-reusable-blocks', 'wp-rich-text', 'wp-server-side-render', 'wp-url', 'wp-wordcount'), 'version' => '2841559daaf3eab166c7'), 'element.js' => array('dependencies' => array('react', 'react-dom', 'wp-escape-html', 'wp-polyfill'), 'version' => '72d791ff772f57f909bc'), 'escape-html.js' => array('dependencies' => array('wp-polyfill'), 'version' => 'f03a1f6b853601ea5727'), 'format-library.js' => array('dependencies' => array('wp-a11y', 'wp-block-editor', 'wp-components', 'wp-data', 'wp-element', 'wp-html-entities', 'wp-i18n', 'wp-polyfill', 'wp-primitives', 'wp-rich-text', 'wp-url'), 'version' => 'c8b9af106157c1ccf597'), 'hooks.js' => array('dependencies' => array('wp-polyfill'), 'version' => 'e98e9677eea626b84eb0'), 'html-entities.js' => array('dependencies' => array('wp-polyfill'), 'version' => 'ce385179f5300ae6db81'), 'i18n.js' => array('dependencies' => array('wp-hooks', 'wp-polyfill'), 'version' => '7c78690c4305ba868cfc'), 'is-shallow-equal.js' => array('dependencies' => array('wp-polyfill'), 'version' => '25dcd1bfd2b5f3c7244a'), 'keyboard-shortcuts.js' => array('dependencies' => array('wp-data', 'wp-element', 'wp-keycodes', 'wp-polyfill'), 'version' => '811bdb5f7e5fd110de7e'), 'keycodes.js' => array('dependencies' => array('lodash', 'wp-i18n', 'wp-polyfill'), 'version' => '66946665aefd82736ddc'), 'list-reusable-blocks.js' => array('dependencies' => array('lodash', 'wp-api-fetch', 'wp-components', 'wp-compose', 'wp-element', 'wp-i18n', 'wp-polyfill'), 'version' => 'bce8311b0458ede2ace6'), 'media-utils.js' => array('dependencies' => array('wp-api-fetch', 'wp-blob', 'wp-element', 'wp-i18n', 'wp-polyfill'), 'version' => '626afea4c4aa9e456a99'), 'notices.js' => array('dependencies' => array('wp-data', 'wp-polyfill'), 'version' => '0f66d57d5cdcaff005c0'), 'nux.js' => array('dependencies' => array('wp-components', 'wp-compose', 'wp-data', 'wp-deprecated', 'wp-element', 'wp-i18n', 'wp-polyfill', 'wp-primitives'), 'version' => '8837d483fb9517ce88f6'), 'plugins.js' => array('dependencies' => array('wp-compose', 'wp-element', 'wp-hooks', 'wp-polyfill', 'wp-primitives'), 'version' => '4cd7b4f6c714e2559cfc'), 'preferences.js' => array('dependencies' => array('wp-a11y', 'wp-components', 'wp-data', 'wp-element', 'wp-i18n', 'wp-polyfill', 'wp-primitives'), 'version' => 'aae5a666f8cfa0d93709'), 'preferences-persistence.js' => array('dependencies' => array('wp-api-fetch', 'wp-polyfill'), 'version' => '44c460ec46ee90712073'), 'primitives.js' => array('dependencies' => array('wp-element', 'wp-polyfill'), 'version' => '38f6e27f8a1e8f693b3e'), 'priority-queue.js' => array('dependencies' => array('wp-polyfill'), 'version' => '5a1fd6a8ae8e953fe1e4'), 'redux-routine.js' => array('dependencies' => array('wp-polyfill'), 'version' => '527db1785e2c14e528f6'), 'reusable-blocks.js' => array('dependencies' => array('wp-block-editor', 'wp-blocks', 'wp-components', 'wp-core-data', 'wp-data', 'wp-element', 'wp-i18n', 'wp-notices', 'wp-polyfill', 'wp-primitives', 'wp-url'), 'version' => '3a0db84366be920dc0c5'), 'rich-text.js' => array('dependencies' => array('lodash', 'wp-a11y', 'wp-compose', 'wp-data', 'wp-deprecated', 'wp-element', 'wp-escape-html', 'wp-i18n', 'wp-keycodes', 'wp-polyfill'), 'version' => 'a41eadb991193e206903'), 'server-side-render.js' => array('dependencies' => array('lodash', 'wp-api-fetch', 'wp-blocks', 'wp-components', 'wp-compose', 'wp-data', 'wp-deprecated', 'wp-element', 'wp-i18n', 'wp-polyfill', 'wp-url'), 'version' => '48a4ea0fec5d64e9cb58'), 'shortcode.js' => array('dependencies' => array('wp-polyfill'), 'version' => 'c1c454988346d2631424'), 'style-engine.js' => array('dependencies' => array('lodash', 'wp-polyfill'), 'version' => 'adcc475b338c87d6c507'), 'token-list.js' => array('dependencies' => array('wp-polyfill'), 'version' => '3b1d1222b29af2b25a3d'), 'url.js' => array('dependencies' => array('wp-polyfill'), 'version' => 'c24becf21dc63719cde9'), 'viewport.js' => array('dependencies' => array('lodash', 'wp-compose', 'wp-data', 'wp-element', 'wp-polyfill'), 'version' => '7fe633c26840e189bfe8'), 'warning.js' => array('dependencies' => array('wp-polyfill'), 'version' => 'd40debb9656e971cde0c'), 'widgets.js' => array('dependencies' => array('lodash', 'wp-api-fetch', 'wp-block-editor', 'wp-blocks', 'wp-components', 'wp-compose', 'wp-core-data', 'wp-data', 'wp-element', 'wp-i18n', 'wp-notices', 'wp-polyfill', 'wp-primitives'), 'version' => '84b61ae6702ee7f94c59'), 'wordcount.js' => array('dependencies' => array('wp-polyfill'), 'version' => '4aeb247ba5c38cf72dde'));
}}}

If I'm not mistaken, the version for components.js is different: f3eecee8c7cf1dd6fe02 vs b3679bd0882f16187c16. Everything else matches.

I'll commit this branch to trunk 👍🏻

We can fix all the remaining issues in trunk. It's very likely that some other open PRs are tackling those issues.

Merged in https://core.trac.wordpress.org/changeset/54253.

[gziolo]

In 54257:

Editor: Sync changes from the Gutenberg plugin 14.1 release

Updated WordPress packages necessary for releasing WordPress 6.1 Beta 1:

• @wordpress/a11y@3.17.1
  • @wordpress/annotations@2.17.2
  • @wordpress/api-fetch@6.14.1
  • @wordpress/autop@3.17.1
  • @wordpress/babel-plugin-import-jsx-pragma@4.0.1
  • @wordpress/babel-plugin-makepot@5.1.1
  • @wordpress/babel-preset-default@7.1.1
  • @wordpress/base-styles@4.8.1
  • @wordpress/blob@3.17.1
  • @wordpress/block-directory@3.15.2
  • @wordpress/block-editor@10.0.2
  • @wordpress/block-library@7.14.2
  • @wordpress/block-serialization-default-parser@4.17.1
  • @wordpress/block-serialization-spec-parser@4.17.1
  • @wordpress/blocks@11.16.2
  • @wordpress/browserslist-config@5.0.1
  • @wordpress/components@21.0.2
  • @wordpress/compose@5.15.2
  • @wordpress/core-data@5.0.2
  • @wordpress/create-block-tutorial-template@2.5.1
  • @wordpress/create-block@4.1.1
  • @wordpress/custom-templated-path-webpack-plugin@2.1.3
  • @wordpress/customize-widgets@3.14.2
  • @wordpress/data-controls@2.17.2
  • @wordpress/data@7.1.2
  • @wordpress/date@4.17.1
  • @wordpress/dependency-extraction-webpack-plugin@4.0.2
  • @wordpress/deprecated@3.17.1
  • @wordpress/docgen@1.26.1
  • @wordpress/dom-ready@3.17.1
  • @wordpress/dom@3.17.2
  • @wordpress/e2e-test-utils@8.1.1
  • @wordpress/e2e-tests@5.1.2
  • @wordpress/edit-post@6.14.2
  • @wordpress/edit-site@4.14.2
  • @wordpress/edit-widgets@4.14.2
  • @wordpress/editor@12.16.2
  • @wordpress/element@4.15.1
  • @wordpress/env@5.2.1
  • @wordpress/escape-html@2.17.1
  • @wordpress/eslint-plugin@13.1.1
  • @wordpress/format-library@3.15.2
  • @wordpress/hooks@3.17.1
  • @wordpress/html-entities@3.17.1
  • @wordpress/i18n@4.17.1
  • @wordpress/icons@9.8.1
  • @wordpress/interface@4.16.2
  • @wordpress/is-shallow-equal@4.17.1
  • @wordpress/jest-console@6.0.1
  • @wordpress/jest-preset-default@9.0.1
  • @wordpress/jest-puppeteer-axe@5.0.1
  • @wordpress/keyboard-shortcuts@3.15.2
  • @wordpress/keycodes@3.17.1
  • @wordpress/lazy-import@1.4.3
  • @wordpress/library-export-default-webpack-plugin@2.3.3
  • @wordpress/list-reusable-blocks@3.15.2
  • @wordpress/media-utils@4.8.1
  • @wordpress/notices@3.17.2
  • @wordpress/npm-package-json-lint-config@4.2.1
  • @wordpress/nux@5.15.2
  • @wordpress/plugins@4.15.2
  • @wordpress/postcss-plugins-preset@4.1.1
  • @wordpress/postcss-themes@5.0.1
  • @wordpress/preferences-persistence@1.9.1
  • @wordpress/preferences@2.9.2
  • @wordpress/prettier-config@2.0.1
  • @wordpress/primitives@3.15.1
  • @wordpress/priority-queue@2.17.2
  • @wordpress/project-management-automation@1.16.1
  • @wordpress/react-i18n@3.15.1
  • @wordpress/readable-js-assets-webpack-plugin@2.0.1
  • @wordpress/redux-routine@4.17.1
  • @wordpress/reusable-blocks@3.15.2
  • @wordpress/rich-text@5.15.2
  • @wordpress/scripts@24.1.2
  • @wordpress/server-side-render@3.15.2
  • @wordpress/shortcode@3.17.1
  • @wordpress/style-engine@1.0.1
  • @wordpress/stylelint-config@21.0.1
  • @wordpress/token-list@2.17.1
  • @wordpress/url@3.18.1
  • @wordpress/viewport@4.15.2
  • @wordpress/warning@2.17.1
  • @wordpress/widgets@2.15.2
  • @wordpress/wordcount@3.17.1

Props bernhard-reiter, cbravobernal, czapla, oandregal, isabel_brison, andrewserong, mciampini.
See #56467.

Committed with https://core.trac.wordpress.org/changeset/54257. Let's tackle everything else with follow-up tasks.

Created Core-56611 for expanding unit tests.

[hellofromTonya]

In 54260:

Editor: Introduces fluid typography and uses Style Engine.

This commit introduces fluid typography block supports and switches to use the Style Engine for typography and colors.

The motivation for fluid typography block supports:

"Fluid typography" describes how a site's font sizes adapt to every change in screen size, for example, growing larger as the viewport width increases, or smaller as it decreases.

Font sizes can smoothly scale between minimum and maximum viewport widths.

Typography changes introduced from Gutenberg:

• Uses the Style Engine to generate the CSS and classnames in wp_apply_typography_support().
• Introduces wp_typography_get_preset_inline_style_value() for backwards-compatibility.
• Introduces a private internal function called wp_get_typography_value_and_unit(), for checking and getting typography unit and value.
• Introduces a private internal function called wp_get_computed_fluid_typography_value(), for an internal implementation of CSS clamp().
• Deprecates wp_typography_get_css_variable_inline_style().

References:

• ​WordPress/gutenberg PR 40332 Style Engine: add typography and color to backend
• ​WordPress/gutenberg PR 39529 Block supports: add fluid typography

Follow-up to [53076], [52302], [52069], [51089], [50761], [49226].

Props ramonopoly, youknowriad, aristath, oandregal, aaronrobertshaw, cbirdsong, jorgefilipecosta, ironprogrammer, hellofromTonya.
See #56467.

Committed via https://core.trac.wordpress.org/changeset/54260. Thank you everyone for contributions!

Currently reviewing. When ready, will prep the commit.

[gziolo]

In 54261:

Chore: Run browserslits update

Follow-up [54257].
See #56467.

[jorgefilipecosta]

In 54263:

Editor: Add post types property to wp-rest-block-patterns-controller.php.

Backports PHP changes in WordPress/gutenberg#41791 to the core. Adds the post types property to the rest API patterns endpoint.

Props mcsf, ntsekouras, matveb.
See #56467.

Rebased the branch on top of the latest trunk.

[kebbet]

[54263] introduced multiple new strings, and the post_type discription has a leading space, it should be removed.

Line 190 in class-wp-rest-block-patterns-controller.php.

From:
__( ' An array of post types that the pattern is restricted to be used with.' )

To:
__( 'An array of post types that the pattern is restricted to be used with.' )

Note: The npm CI job failure is unrelated to this PR.

[hellofromTonya]

In 54269:

Editor: Adds template types, is_wp_suggestion, and fallback template content.

This commit improves site editor templates by:

• Adds a post meta is_wp_suggestion to templates created from the site editor.

Why? To differentiate the templates created from the post editor in the Template panel in inspector controls and the templates suggested in site editor.

See ​Gutenberg PR 41387 for more details.

• Expands the template types that can be added to the site editor to include single custom post type and specific posts templates.

See ​Gutenberg PR 41189 for more details.

• Adds fallback template content on creation in site editor:
  • Introduces get_template_hierarchy() to get the template hierarchy for a given template slug to be created.
  • Adds a lookup route to WP_REST_Templates_Controller to get the fallback template content.

See ​Gutenberg PR 42520 for more details.

• Fixes a typo in default category template's description within get_default_block_template_types().

See ​Gutenberg PR 42586 for more details.

• Changes field checks from in_array() to rest_is_field_included() in WP_REST_Post_Types_Controller.
• Adds an icon field to WP_REST_Post_Types_Controller

Follow-up to [53129], [52331], [52275], [52062], [51962], [43087].

Props ntsekouras, spacedmonkey, mamaduka, mburridge, jameskoster, bernhard-reiter, mcsf, hellofromTonya.
See #56467.

Committed via changeset https://core.trac.wordpress.org/changeset/54269. Thank you everyone for your contributions!

I'm self-assigning for review and commit.

Tentatively pinging @ramonjd @andrewserong because it might be related to the Style Engine (?)

In relation to your ​comment above, I think it's related to the specific selectors in image/block.json:

​https://github.com/WordPress/gutenberg/blob/fd3b08bef5da71ca02db872ddd57a7a77beaec21/packages/block-library/src/image/block.json#L96-L95

Could it be that the tests weren't pulled across yet? Here is the expected string in the Gutenberg test:

​https://github.com/WordPress/gutenberg/blob/843549495a4b65815ea53b4a7378f893e375ee66/phpunit/class-wp-theme-json-test.php#L425

## Test Report

### Steps to Test

1. Apply the PR.
2. Activate the Twenty Twenty-Two theme. Ensure that there are no header customizations in the Site Editor.
3. Navigate to the frontend.
4. Inspect the header row.

### Expected Results

• ✅ The element should now have the .is-layout-flex class.
• ✅ The styling should match that shown in the screenshot in the PR's description.

### Environment

• Server: Apache (Linux)
• WordPress: 6.1-alpha-53344-src
• Browser: Chrome 105.0.0.0
• OS: Windows 10
• Theme: Twenty Twenty-Two
• Plugins: None activated.

### Actual Results

• ✅ The element has the .is-layout-flex class.
• ✅ The styling matches that shown in the screenshot in the PR description.

### Supplemental Artifacts

For this backport, I'll be reverting the DocBlock changes for wp_get_layout_style(). Why?

• They were not part of the backports from Gutenberg's PR 40875 ​https://github.com/WordPress/gutenberg/pull/40875.
• And they were introduced in 5.9.

Instead, I'll do a follow-up coding standards commit to improve the DocBlock including updating the descriptions for the optional parameters (e.g. adding the word Optional. and adding the default Default is null.).

[audrasjb]

In 54272:

Editor: Introduce spacing presets in global style properties.

This changeset is part of the Gutenberg changes merged into WP 6.1. It adds spacing presets support in global style properties.

Follow-up to [54211].

Props glendaviesnz, andrewserong, costdev, audrasjb, mukesh27.
See #56467.

Committed in https://core.trac.wordpress.org/changeset/54272

[jorgefilipecosta]

In 54273:

Editor: Add has_archive property to the post types REST endpoint.

Backports PHP changes in WordPress/gutenberg#42746 to the core. Adds a has_archive field to the post types endpoint.

Props mcsf, ntsekouras, oandregal.
See #56467.

[hellofromTonya]

In 54274:

Editor: Improves layout block support in wp_get_layout_style().

This commit merges the remaining changes from ​Gutenberg PR 40875. It's Part 2 (see [54162] for Part 1) of a layout improvement initiative and targets wp_get_layout_style() in layout.php.

Context:
The overall initiative is to improve layout block support:

to use centralised layout definitions, output base layout styles from global styles, introduce a layout type semantic classname, reduce duplication of container class and style tag output, and fix blockGap at the block level in global styles.

Changes include:

• Adding an optional parameter $block_spacing to wp_get_layout_style() for setting a custom spacing on the block.
• Adding handle for the block spacing.
• Using the style engine to to enqueue and render layout styles via wp_style_engine_get_stylesheet_from_css_rules().
• Introduces a new test file for wp_get_layout_style().

Follow-up to [54162], [54160], [54159], [53421], [52380], [53085], [52069].

Props andrewserong, isabel_brison, costdev, hellofromTonya.
See #56467.

Committed via changeset https://core.trac.wordpress.org/changeset/54274. Thank you everyone for your contributions!

A follow-up commit is coming to address other changes that were not part of the original GB PR (such as DocBlock improvements).

DocBlock improvements suggestioned in this PR were committed via changeset https://core.trac.wordpress.org/changeset/54275.

Backports PHP changes in WordPress/gutenberg#43862 to the core. Adds a mechanism to dynamically compute names and descriptions of the author, page, single, tag, category, and taxonomy templates.

Props mcsf, ntsekouras, antonvlasenko, jameskoster.
See #56467.

[jorgefilipecosta]

In 54280:

Editor: Make template names and descriptions dynamic.

Backports PHP changes in WordPress/gutenberg#43862 to the core. Adds a mechanism to dynamically compute names and descriptions of the author, page, single, tag, category, and taxonomy templates.

Props mcsf, ntsekouras, antonvlasenko, jameskoster.
See #56467.

Committed in ​https://github.com/WordPress/wordpress-develop/commit/c7574bee178a1963553bbefaee4ee3d5c3fd2412.

I finally managed to get both versions of components.js on my local machine. One of them from Unix, with a f3eecee8c7cf1dd6fe02 hash, the other one from Windows, with a b3679bd0882f16187c16 hash. Verifying the hashes locally with

openssl dgst -md4 < components.js

confirms that the files are real, without any distortions, and that the hashes agree.

The diff is nothing like line endings or Unicode characters. The file contains many JS modules, and in the Windows one some modules are just in a different order, nothing else. Namely, there are two pairs of date-fns modules:

./node_modules/date-fns/esm/_lib/startOfUTCISOWeek/index.js
./node_modules/date-fns/esm/_lib/startOfUTCISOWeekYear/index.js

and

./node_modules/date-fns/esm/_lib/startOfUTCWeek/index.js
./node_modules/date-fns/esm/_lib/startOfUTCWeekYear/index.js

Unix lays them out in this order (first Week, then WeekYear), Windows lay them out in reversed order (first WeekYear, then Week). That's the entire diff.

I think it's a webpack bug in sorting the module names. Try to sort names with a / separator:
{{{js
console.log([ 'WeekYear/index', 'Week/index' ].sort());
}}}
You'll get this result:

[ 'Week/index', 'WeekYear/index' ]

Now try the same with Windows separators (\):
{{{js
console.log([ 'WeekYear
index', 'Week
index' ].sort());
}}}
and you'll get the reverse order:
{{{js
[ 'WeekYear
index', 'Week
index' ]
}}}
Forward slash sorts after letters, but backslash sorts before letters!

Trac ticket: https://core.trac.wordpress.org/ticket/56467
Backports ​https://github.com/WordPress/gutenberg/pull/44363

Hey @oandregal I don't really have the expertise to judge the code itself.

However, I am using the testing instructions from ​https://github.com/WordPress/gutenberg/pull/44363 and I can't reproduce the behaviour mentioned below:

Using a theme without theme.json (for example, Canape):

• Verify that the styles for the pullquote and navigation blocks are still present in the global-styles-inline-css. These blocks are the only ones that use the __experimentalStyle API in its block.json. It should look like this:

{{{css
.wp-block-pullquote{font-size: 1.5em;line-height: 1.6;}
.wp-block-navigation a:where(:not(.wp-element-button)){color: inherit;}
}}}

Here's a video of my issue:

​https://user-images.githubusercontent.com/5417266/191844918-11cf5db7-77d3-4a4e-a751-ed8168d38860.mp4

Interesting, I've tested in trunk and it does not work either (it should).

It seems that we're missing a backport: I cannot find in trunk the filter *_theme_json_get_style_nodes, neither when it's thrown or when is used. This was introduced at ​https://github.com/WordPress/gutenberg/pull/41160 and then the filter updated the name at ​https://github.com/WordPress/gutenberg/pull/44189 Perhaps we're missing some backports?

I think the reason it's not working is that this backport is missing: ​https://github.com/WordPress/wordpress-develop/pull/3319

Backports PHP changes in WordPress/gutenberg#42124 to the core. Adds the missing mechanism to output frontend styles of block level presets to the core. Props mcsf, oandregal, dmsnell, draganescu.
See #56467.

## Testing
Paste the following code on a post:

<div class="wp-block-group">
<p>Leaf paragraph of inner group block.</p>



<ul class="wp-block-social-links has-visible-labels has-icon-background-color"></ul>



<ul class="wp-block-social-links has-visible-labels has-icon-background-color"></ul>



<p class="has-global-aquamarine-background-color has-background">global-aquamarine</p>



<p class="has-global-pink-background-color has-background">global-pink</p>
</div>

Verify the front-end result is:

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

Backports fix to block spacing from ​https://github.com/WordPress/gutenberg/pull/44446

[jorgefilipecosta]

In 54305:

Editor: Fix missing frontend section presets output.

Backports PHP changes in WordPress/gutenberg#42124 to the core. Adds the missing mechanism to output frontend styles of block level presets to the core.

Props mcsf, oandregal, dmsnell, draganescu.
See #56467.

Committed in ​https://github.com/WordPress/wordpress-develop/commit/2b1febd20d77898eb81439a688ea5597da00172a.

Unfortunately, this seems to cause a fatal when the current stable version of the Gutenberg plugin is enabled:

Warning: Declaration of WP_Theme_JSON_6_1::get_stylesheet($types = Array, $origins = NULL) should be compatible with WP_Theme_JSON::get_stylesheet($types = Array, $origins = NULL, $options = Array) in /var/www/src/wp-content/plugins/gutenberg/lib/compat/wordpress-6.1/class-wp-theme-json-6-1.php on line 630

@jorgefilipecosta Could you revert this for now? We need to figure out a way that's compatible with the GB plugin 🙂

Update: Jorge reverted this in decd9468e5b6ad0223c6f7f42fec30d1389cc901. Thank you!

He also mentioned that we'll need to coordinate landing this with a Gutenberg release that includes the updated function signature. I believe that's ​https://github.com/WordPress/gutenberg/pull/42124.

Self-assigning for commit review and prep.

Self-assigning for commit review and prep.

# Test Report

Env:
WordPress: current trunk
Themes: TT2 and TT3
Plugins: none activated
Localhost: wp-env
OS: macOS
Browser: Firefox, Chrome, and Edge

## Test Instructions:

• Step 1: Add a new post and paste this code:

<details>

<summary>Test Columns markup</summary>
{{{html

<div class="wp-block-group has-primary-background-color has-background">
<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nunc tincidunt ex in eros ultrices hendrerit.</p>

<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nunc tincidunt ex in eros ultrices hendrerit.</p>
</div>

<div class="wp-block-columns">
<div class="wp-block-column has-primary-background-color has-background">
<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nunc tincidunt ex in eros ultrices hendrerit.</p>

<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nunc tincidunt ex in eros ultrices hendrerit.</p>
</div>

<div class="wp-block-column has-primary-background-color has-background">
<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nunc tincidunt ex in eros ultrices hendrerit.</p>

<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nunc tincidunt ex in eros ultrices hendrerit.</p>
</div>

<div class="wp-block-column has-primary-background-color has-background">
<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nunc tincidunt ex in eros ultrices hendrerit.</p>

<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nunc tincidunt ex in eros ultrices hendrerit.</p>
</div>
</div>

}}}

</details>

## Results:

Summary:

• Confirmed the bug report of invalid CSS ✅ 🐞
• Confirmed the fix resolves the issue, ie renders valid CSS ✅

### Using TT2:

The PHP Code's $gap_value:

• Before: 'var:preset|spacing|70'
• After: var(--wp--preset--spacing--70)

#### Before applying the patch

{{{css
.wp-block-group.wp-container-7.wp-block-group.wp-container-7 > * + * {

margin-block-start: var:preset|spacing|70;
margin-block-end: 0;

}
}}}

#### After applying the patch

{{{css
.wp-block-group.wp-container-7.wp-block-group.wp-container-7 > * + * {

margin-block-start: var(--wp--preset--spacing--70);
margin-block-end: 0;

}
}}}

### Using TT3:

The PHP Code's $gap_value:

• Before: 'var:preset|spacing|70'
• After: var(--wp--preset--spacing--70)

#### Before applying the patch

{{{css
.wp-block-group.wp-container-7.wp-block-group.wp-container-7 > * + * {

margin-block-start: var:preset|spacing|70;
margin-block-end: 0;

}
}}}

#### After applying the patch

{{{css
.wp-block-group.wp-container-7.wp-block-group.wp-container-7 > * + * {

margin-block-start: var(--wp--preset--spacing--70);
margin-block-end: 0;

}
}}}

Confirmed: This PR does fix the reported bug ​https://github.com/WordPress/gutenberg/issues/44435 ✅

However, there are no tests for this specific expectation. I'll add a dataset to this PR ⚪

[hellofromTonya]

In 54311:

Editor: Fix spacing property generation in flow layout type.

Fixes a bug of invalid CSS value when applying block spacing to a block as reported in ​Gutenberg issue 44435.

Adds logic to convert preset values (i.e. $gap_value) into valid CSS custom properties for the flow ('default') layout type. See the original fix in ​Gutenberg PR 3324.

Also adds a test dataset that fails before the bugfix and passes after the bugix.

Follow-up to [54274].

Props ndiego, isabel_brison, ramonopoly, andrewserong, hellofromTonya.
See #56467.

Merged via changest https://core.trac.wordpress.org/changeset/54311. Thank you everyone for your contributions in identifying and resolving this issue 🎉

I started working on PR #3319 without realizing this PR is dependent upon that one. As they need to be committed together, I'm closing this one in favor of PR #3319 (as I've already made it a complete backport).

Trac ticket: https://core.trac.wordpress.org/ticket/56467
Backports ​https://github.com/WordPress/gutenberg/pull/44363

To test, you can follow the testing instructions on ​https://github.com/WordPress/gutenberg/pull/44363.

This PR adds a missing origin to the code that processes theme.json. It also consolidates its name to blocks to be more reflective of what it affects. If the data coming from the blocks origin contained presets, it would be overriden by the data coming from the theme origin, which is not expected.

# Test Report

Env:

• Localhost: wp-env
• OS: macOS
• Browser: Firefox
• Plugins: none
• Theme: TT2

## Test 1: Test that the styles are enqueued when the blocks are in use

### Instructions

• Step 1: Create a page that uses the pullquote and navigation blocks and publish.
• Step 2: View the page in the front-end
• Step 3: Verify that the styles for the pullquote and navigation blocks are not part of the global-styles-inline-css.
• Step 4: Verify that (a) there's a wp-block-pullquote-inline-css stylesheet and (b) contains .wp-block-pullquote{border-width: 1px 0;font-size: 1.5em;line-height: 1.6;}.
• Step 5: Verify that (a) there's a wp-block-navigation-inline-css stylesheet and (b) it contains .wp-block-navigation a:where(:not(.wp-element-button)){color: inherit;}.

### Results:

Expectations > Results:

• global-styles-inline-css does not include styles for pullquote and navigation blocks > Verified ✅
• <style id="wp-block-pullquote-inline-css">..</style> exists > Verified ✅
• wp-block-pullquote-inline-css contains .wp-block-pullquote{border-width: 1px 0;font-size: 1.5em;line-height: 1.6;} > No, it does not ❌

<details>

<summary>Results: HTML</summary>

{{{html
<style id="wp-block-pullquote-inline-css">

/

• Colors */

/

• Breakpoints & Media Queries */

/

• SCSS Variables. *
• Please use variables from this sheet to ensure consistency across the UI.
• Don't add to this sheet unless you're pretty sure the value will be reused in many places.
• For example, don't add rules to this sheet that affect block visuals. It's purely for UI. */

/

• Colors */

/

• Fonts & basic variables. */

/

• Grid System.
• ​https://make.wordpress.org/design/2019/10/31/proposal-a-consistent-spacing-system-for-wordpress/ */

/

• Dimensions. */

/

• Shadows. */

/

• Editor widths. */

/

• Block & Editor UI. */

/

• Block paddings. */

/

• React Native specific.
• These variables do not appear to be used anywhere else. */

/

• Converts a hex value into the rgb equivalent.

*

• @param {string} hex - the hexadecimal value to convert
• @return {string} comma separated rgb values

*/
/

• Breakpoint mixins */

/

• Long content fade mixin *
• Creates a fading overlay to signify that the content is longer
• than the space allows. */

/

• Focus styles. */

/

• Applies editor left position to the selector passed as argument */

/

• Styles that are reused verbatim in a few places */

/

• Allows users to opt-out of animations via OS-level preferences. */

/

• Reset default styles for JavaScript UI based pages.
• This is a WP-admin agnostic reset */

/

• Reset the WP Admin page styles for Gutenberg-like pages. */

.wp-block-pullquote {

margin: 0 0 1em 0;
padding: 3em 0;
text-align: center;
overflow-wrap: break-word;
box-sizing: border-box;

}
.wp-block-pullquote p,
.wp-block-pullquote blockquote,
.wp-block-pullquote cite {

color: inherit;

}
.wp-block-pullquote.alignleft, .wp-block-pullquote.alignright {

max-width: 420px;

}
.wp-block-pullquote cite,
.wp-block-pullquote footer {

position: relative;

}
.wp-block-pullquote .has-text-color a {

color: inherit;

}

.wp-block-pullquote.has-text-align-left blockquote {

text-align: left;

}

.wp-block-pullquote.has-text-align-right blockquote {

text-align: right;

}

.wp-block-pullquote.is-style-solid-color {

border: none;

}
.wp-block-pullquote.is-style-solid-color blockquote {

margin-left: auto;
margin-right: auto;
max-width: 60%;

}
.wp-block-pullquote.is-style-solid-color blockquote p {

margin-top: 0;
margin-bottom: 0;
font-size: 2em;

}
.wp-block-pullquote.is-style-solid-color blockquote cite {

text-transform: none;
font-style: normal;

}

.wp-block-pullquote cite {

color: inherit;

}
/

• Colors */

/

• Breakpoints & Media Queries */

/

• SCSS Variables. *
• Please use variables from this sheet to ensure consistency across the UI.
• Don't add to this sheet unless you're pretty sure the value will be reused in many places.
• For example, don't add rules to this sheet that affect block visuals. It's purely for UI. */

/

• Colors */

/

• Fonts & basic variables. */

/

• Grid System.
• ​https://make.wordpress.org/design/2019/10/31/proposal-a-consistent-spacing-system-for-wordpress/ */

/

• Dimensions. */

/

• Shadows. */

/

• Editor widths. */

/

• Block & Editor UI. */

/

• Block paddings. */

/

• React Native specific.
• These variables do not appear to be used anywhere else. */

/

• Converts a hex value into the rgb equivalent.

*

• @param {string} hex - the hexadecimal value to convert
• @return {string} comma separated rgb values

*/
/

• Breakpoint mixins */

/

• Long content fade mixin *
• Creates a fading overlay to signify that the content is longer
• than the space allows. */

/

• Focus styles. */

/

• Applies editor left position to the selector passed as argument */

/

• Styles that are reused verbatim in a few places */

/

• Allows users to opt-out of animations via OS-level preferences. */

/

• Reset default styles for JavaScript UI based pages.
• This is a WP-admin agnostic reset */

/

• Reset the WP Admin page styles for Gutenberg-like pages. */

.wp-block-pullquote {

border-top: 4px solid currentColor;
border-bottom: 4px solid currentColor;
margin-bottom: 1.75em;
color: currentColor;

}
.wp-block-pullquote cite,
.wp-block-pullquote footer, .wp-block-pullquotecitation {

color: currentColor;
text-transform: uppercase;
font-size: 0.8125em;
font-style: normal;

}
</style>
}}}

</details>

• <style id="wp-block-navigation-inline-css">..</style> exists > Verified ✅
• wp-block-navigation-inline-css contains .wp-block-navigation a:where(:not(.wp-element-button)){color: inherit;} > Verified ✅

<details>

<summary>Results: HTML</summary>

{{{html
<style id="wp-block-pullquote-inline-css">
.wp-block-navigation a:where(:not(.wp-element-button)){color: inherit;}
</style>
}}}
</details>

## Test 2: Test that the styles are not enqueued when the blocks are not in use:

### Instructions

• Step 1: Create a page that does not use the pullquote and navigation blocks and publish.
• Step 2: View the page in the front-end
• Step 3: Verify that the styles for the pullquote and navigation blocks are not in the global-styles-inline-css styles.
• Step 4: Verify there's no <style id="wp-block-pullquote-inline-css"> in the <head>.
• Step 5: Verify there's no <style id="wp-block-navigation-inline-css"> in the <head>.

### Results

Expectations > Results:

• global-styles-inline-css does not include styles for pullquote and navigation blocks > Verified ✅
• <style id="wp-block-pullquote-inline-css">..</style> does not exist > Verified ✅
• <style id="wp-block-navigation-inline-css">..</style> does not exist > Does exist but likely for the page navigation (not in-page content nav) ❌

## Test 3: Test that themes can opt-out from loading blocks separately even if the post uses the blocks:

### Instructions

• Step 1: Add add_filter( 'should_load_separate_core_block_assets', '__return_false' ); to the functions.php of the theme.
• Step 2: View the Test 1 page in the front-end.
• Verify that styles for all blocks are part of the global-styles-inline-css stylesheet.

### Results

Expectations > Results:

• global-styles-inline-css contains pullquote or wp-block-pullquote styles > Does not contain ❌
• global-styles-inline-css contains wp-block-navigation styles > Verified ✅

@oandregal Can you double check this backport. Using the ​test instructions, notice the ❌ items (in my ​Test Report) that did not meet the expectations.

Committer Note: This PR is not yet ready for commit as it is not meeting the defined testing expectations.

[jrf]

@gziolo Commit [54257] is now the second commit in as many days which I've identified as breaking the WP Core test suite ...

At the top of every test run in GH Actions you can now see the following error messages since this commit:

Creating wordpress-develop_php_run ... 
Creating wordpress-develop_php_run ... done
WordPress database error Table 'wordpress_develop_tests.wptests_posts' doesn't exist for query 
			SELECT   wptests_posts.*
<div id="error"><p class="wpdberror"><strong>WordPress database error:</strong> [Table &#039;wordpress_develop_tests.wptests_posts&#039; doesn&#039;t exist]<br /><code>
			SELECT   wptests_posts.*
			FROM wptests_posts 
			WHERE 1=1  AND ( 
  0 = 1
) AND wptests_posts.post_type = &#039;wp_template_part&#039; AND ((wptests_posts.post_status = &#039;publish&#039;))
			GROUP BY wptests_posts.ID
			ORDER BY wptests_posts.post_date DESC
			
			FROM wptests_posts 
			WHERE 1=1  AND ( 
  0 = 1
) AND wptests_posts.post_type = 'wp_template_part' AND ((wptests_posts.post_status = 'publish'))
			GROUP BY wptests_posts.ID
			ORDER BY wptests_posts.post_date DESC
			
		 made by require_once('wp-settings.php'), do_action('init'), WP_Hook->do_action, WP_Hook->apply_filters, register_block_core_template_part, build_template_part_block_variations, build_template_part_block_instance_variations, get_block_templates, WP_Query->__construct, WP_Query->query, WP_Query->get_posts
		</code></p></div>Installing...
Running as single site... To run multisite, use -c tests/phpunit/multisite.xml

These errors aren't triggering build failures as they are thrown in the test bootstrapping and the test bootstrapping doesn't throw exceptions on errors (while it probably should).

Still not pretty. This needs to be fixed ASAP.

[jrf]

While looking at the tests now, I've found that ​PR 3199 as committed in [54156] introduces four new incompatibilities with PHP 8.2.

The tests committed with that same PR are insufficient and did not flag the problem. The tests committed in [54211] luckily did flag the problem.

The problem is with the following code:

<?php
class WP_Style_Engine {
        const BLOCK_STYLE_DEFINITIONS_METADATA = array(
                /* <snip> */
                'border'     => array(
                        /* <snip> */
                        'top'    => array(
                                'value_func' => 'static::get_individual_property_css_declarations',
                                'path'       => array( 'border', 'top' ),
                                'css_vars'   => array(
                                        'color' => '--wp--preset--color--$slug',
                                ),
                        ),
                        'right'  => array(
                                'value_func' => 'static::get_individual_property_css_declarations',
                                'path'       => array( 'border', 'right' ),
                                'css_vars'   => array(
                                        'color' => '--wp--preset--color--$slug',
                                ),
                        ),
                        'bottom' => array(
                                'value_func' => 'static::get_individual_property_css_declarations',
                                'path'       => array( 'border', 'bottom' ),
                                'css_vars'   => array(
                                        'color' => '--wp--preset--color--$slug',
                                ),
                        ),
                        'left'   => array(
                                'value_func' => 'static::get_individual_property_css_declarations',
                                'path'       => array( 'border', 'left' ),
                                'css_vars'   => array(
                                        'color' => '--wp--preset--color--$slug',
                                ),
                        ),
                ),
                /* <snip> */
        );

        /* <snip> */
}

Each of these definitions use 'value_func' => 'static::get_individual_property_css_declarations'.
That syntax for declaring a callable is deprecated as of PHP 8.2 and will result in a fatal error as of PHP 9.0.

Changing this may require an architectural change to the class.

To explain:

1. The typical PHP-cross-version replacement for 'static::get_individual_property_css_declarations' would be array( static::class, 'get_individual_property_css_declarations' ).
2. However, static::class cannot be used in a constant declaration as constant values have to be constant and how static::class resolves can change at runtime depending on the class hierarchy.

I'd like to understand why the choice was made to use static:: in these declarations.
I currently do not see any class within WP Core which extends the WP_Style_Engine class, so why is static:: being used instead of self:: ?

As for solution directions:

• If static:: was not used intentional and can be replaced with self::, the callables need to be rewritten to array( self::class, 'get_individual_property_css_declarations' ).
• If static:: was used intentionally, an architectural change is needed as the callable cannot be declared like that in the constant.
  • Changing the constant to a private property without the callables and adding them to the array in the class constructor is not an option as the class only contains static methods and does not seem to be intended to be instantiated.
  • Changing the constant to a private static property is not an option either, as same as constants and non-static properties, the initial value for a property needs to be constant.

In other words: If static:: was used intentionally, the class will probably need a rethink...

As this is a new class and any architectural change in it in the future would be considered a breaking change, this MUST be fixed before WP 6.1 is released.

And for the love of code, please, please add better tests to safeguard against these kind of problems and check the PHP 8.1 and 8.2 test logs to prevent introducing new issues like this.

Also see: ​https://wiki.php.net/rfc/deprecate_partially_supported_callables

[SergeyBiryukov]

Replying to jrf:

At the top of every test run in GH Actions you can now see the following error messages since this commit:

Creating wordpress-develop_php_run ... 
Creating wordpress-develop_php_run ... done
WordPress database error Table 'wordpress_develop_tests.wptests_posts' doesn't exist for query 
			SELECT   wptests_posts.*

Thanks for flagging this! It looks like there is already a separate ticket for that particular issue: #56617.

Backport of ​https://github.com/WordPress/gutenberg/pull/43337.

Quoting that PR's description:

## What?
Allow a theme to enable appearanceTools to any theme including classic themes.

## Why?
Appearance tools are options in the block editor and don't require the use of the FSE to take advantage of. However there's no way to enable those tools for themes that don't use theme.json.

## How?
This checks for the 'appearance-tools' support and if present flags settings.appearanceTools as true in the theme portion of Global Styles.

## Testing Instructions
Using a theme that does NOT use a theme.json file enable the 'appearanceTools` theme support.

add_theme_support( 'appearance-tools' );

Add a group block to a new post. Note the block settings panel includes Border settings.

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

Hmm, this is marked as a Feature in the original Gutenberg PR and an enhancement in the Trac ticket (which is not in the 6.1 milestone). Sadly, this one missed the 6.1 feature freeze deadline.

Could it be reclassified? Deferring that decision to 6.1 Core Tech Leads @jeffpaul @dream-encode @getsource.

Includes the latest round of Gutenberg bugfix PRs that were approved for inclusion during ​yesterday’s triage session.

Needed for today's WP 6.1 Beta 2 release (scheduled in ~3 hours from now).

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

I've reverted the original commit and run npm run sync-gutenberg-packages -- --dist-tag=wp-6.1 locally now. I've pushed the commits to this branch but don't see them yet here 😕

FWIW, ​GitHub Status is showing some issue with GH Actions (but no other GH components).

[SergeyBiryukov]

In 54329:

Users: Correctly pass the context property for persisted preferences.

The user meta context property in wp_register_persisted_preferences_meta() was incorrectly configured. It should be part of the schema array, not the show_in_rest array.

Follow-up to [54182].

Props talldanwp, dd32.
Fixes #56665. See #56467.

Closing. This PR has been flaky, and we've decided that we don't want to include ​https://github.com/WordPress/gutenberg/pull/43862, so we'll need to revert that on GB's wp/6.1 branch.

[davidbaumwald]

After discussions with the Editor Tech leads for 6.1(@bernhard-reiter, @cbravobernal, and @ndiego) and additional guidance from @hellofromtonya, the decision has been made to exclude ​Gutenberg PR #43862 from the pre-Beta 2 Gutenberg sync PR and revert [54280]. Why? [54280] added the feature's PHP code, but the JS package updates were not included before feature freeze(Beta 1), meaning the feature was incomplete. As the PHP code does not work without the JS package update, the feature is incomplete and missed the feature freeze deadline.

Leaving the PHP code was discussed. However, there is a risk of it needing to change which could complicate backwards compatibility in 6.2 when the feature is eventually introduced.

Revert commit to follow.

[davidbaumwald]

In 54333:

Editor: Revert dynamic template names and descriptions.

After discussions with the Editor Tech leads for 6.1(@bernhard-reiter, @cbravobernal, and @ndiego) and additional guidance from @hellofromtonya, the decision has been made to exclude ​Gutenberg PR #43862 from the pre-Beta 2 Gutenberg sync PR and revert [54280]. Why? [54280] added the feature's PHP code, but the JS package updates were not included before feature freeze(Beta 1), meaning the feature was incomplete. As the PHP code does not work without the JS package update, the feature is incomplete and missed the feature freeze deadline.

Leaving the PHP code was discussed. However, there is a risk of it needing to change which could complicate backwards compatibility in 6.2 when the feature is eventually introduced.

Follow-up to [54280].

Props hellofromTonya, bernhard-reiter, cbravobernal.
See #56467.

Includes the latest round of Gutenberg bugfix PRs that were approved for inclusion during ​yesterday’s triage session, minus ​https://github.com/WordPress/gutenberg/pull/43862, which we ​reverted.

Needed for today's WP 6.1 Beta 2 release.

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

New sync PR: ​https://github.com/WordPress/wordpress-develop/pull/3345

[hellofromTonya]

In 54335:

Editor: Update packages for 6.1 Beta 2.

Package updates for bug and regression fixes:

• @wordpress/block-directory: 3.15.3
• @wordpress/block-editor: 10.0.3
• @wordpress/block-library: 7.14.3
• @wordpress/block-serialization-default-parser: 4.17.1
• @wordpress/blocks: 11.16.3
• @wordpress/components: 21.0.3
• @wordpress/compose: 5.15.2
• @wordpress/core-data: 5.0.3
• @wordpress/customize-widgets: 3.14.3
• @wordpress/edit-post: 6.14.3
• @wordpress/edit-site: 4.14.4
• @wordpress/edit-widgets: 4.14.3
• @wordpress/editor: 12.16.3
• @wordpress/format-library: 3.15.3
• @wordpress/interface: 4.16.3
• @wordpress/list-reusable-blocks: 3.15.3
• @wordpress/nux: 5.15.3
• @wordpress/preferences: 2.9.3
• @wordpress/reusable-blocks: 3.15.3
• @wordpress/server-side-render: 3.15.3
• @wordpress/style-engine: 1.0.2
• @wordpress/widgets: 2.15.3

References:

• ​Gutenberg PR 44233 – Blocks: Fix searching of blocks when description is non-string
• ​Gutenberg PR 44301 – Block Toolbar: update position when moving blocks
• ​Gutenberg PR 44334 – Global Styles: Re-add styles that were removed, for classic themes
• ​Gutenberg PR 44351 – Comments block: Support nested comments settings in the comments blocks
• ​Gutenberg PR 44448 – Add a correct TS signature for useEntityRecords
• ​Gutenberg PR 44315 – Pullquote: fix transform to quote crash
• ​Gutenberg PR 44446 – Fix spacing property generation in flow layout type.
• ​Gutenberg PR 44408 – Upgrade react-easy-crop to bring in fix for site editor iframe
• ​Gutenberg PR 44406 – Style engine: kebab case preset slugs in the editor
• ​Gutenberg PR 44209 – Fixing padding on the post editor when RootPaddingAwareAlignments setting is enabled
• ​Gutenberg PR 42950 – Popover: fix limitShift logic by adding iframe offset correctly (and a custom shift limiter)
• ​Gutenberg PR 44337 – Submenu block href only if url is not empty
• ​Gutenberg PR 44291 – Add role=application to list view to prevent browse mode triggering in NVDA
• ​Gutenberg PR 44283 – Navigation block: Fix submenu colors for imported classic menus
• ​Gutenberg PR 44282 – Fix popover stacking in the customize widgets editor
• ​Gutenberg PR 44247 – Spacing presets: switch to using numbers instead of t-shirt sizes for labels
• ​Gutenberg PR 44299 – Backport template creation changes from core
• ​Gutenberg PR 44294 – [Block Library - Query Loop]: Fix broken preview in specific category template
• ​Gutenberg PR 44287 – [Block Library]: Rename Comments pagination inner blocks
• ​Gutenberg PR 44256 – Avoid showing the recursion warning in previews when replacing template parts
• ​Gutenberg PR 44265 – Blocks: officially deprecated the children and node matchers
• ​Gutenberg PR 44251 – Global styles: Remove the beta label from global styles header

Props bernhard-reiter, cbravobernal.
See #56467.

Committed via changeset https://core.trac.wordpress.org/changeset/54335.

From Trac:
​@hellofromTonya Thanks for the ping. In reading the discussion above it seems that testing is needed for each theme before adding the support. I really respect ​@poena's opinion as she's much more plugged in to FSE development.
Moving this to 6.2.

@hellofromtonya @ockham I can confirm I got the same results as Tonya when I tried this PR without the commit ​https://github.com/WordPress/wordpress-develop/pull/3319/commits/48c8feacb4b67daed3ddf7a026adfac2a1bfe1d3 that ported ​https://github.com/WordPress/gutenberg/pull/44363 So probably the root cause is not that.

I've noticed that the other PR we're porting ​https://github.com/WordPress/gutenberg/pull/42005 had a few follow-ups so I wonder if we're missing something else.

Thank you @dream-encode! I'll move the PR to "Bumped to 6.2" on our project board 👍

Hi there!

I don't agree this should be punted to 6.2, as bundled themes in 6.1 ​are already using this feature. Therefore, one could argue this is not shipping a new feature but fixing something that is not properly working as intended; otherwise, functionality would need to be removed from the bundled themes.

Hi there!

I don't agree this should be punted to 6.2, as bundled themes in 6.1 ​are already using this feature. Therefore, one could argue this is not shipping a new feature but fixing something that is not properly working as intended; otherwise, functionality would need to be removed from the bundled themes.

Backport of ​https://github.com/WordPress/gutenberg/pull/44314.

Props @kebbet.

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

The string syntax for callables will be deprecated in 8.2

See: ​https://wiki.php.net/rfc/deprecate_partially_supported_callables

This PR switches to use to array( self::class, '*' ) and makes the WP_Style_Engine class final with the understanding that we won't need to, nor should we, extend it.

See comment: https://core.trac.wordpress.org/ticket/56467#comment:242 for a description of the deprecation notice and explanation.

Check the tests running on the 8.2 on ubuntu-latest job and ensure that the deprecation notice does not appear:

For example:

1) Test_Block_Supports_Border::test_border_color_slug_with_numbers_is_kebab_cased_properly
Use of "static" in callables is deprecated

Props to @jrfnl

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

[ramonopoly]

While looking at the tests now, I've found that PR 3199 as committed in [54156] introduces four new incompatibilities with PHP 8.2.
As this is a new class and any architectural change in it in the future would be considered a breaking change, this MUST be fixed before WP 6.1 is released.

Thanks again @jrf

Patch here: ​https://github.com/WordPress/wordpress-develop/pull/3363
Synching to Gutenberg here: ​https://github.com/WordPress/gutenberg/pull/44561

[davidbaumwald]

In 54356:

Editor: Remove leading whitespace from some translated strings.

Merges ​Gutenberg PR #44314 into trunk.

Follow-up to [54263] and [54269].

Props kebbet, bernhard-reiter.
See #56467.

Merged into core in https://core.trac.wordpress.org/changeset/54356.

Thank you @hellofromtonya and @oandregal! Apologies, this has been on my list for a while, but I haven't gotten around to look into it yet.

I'll be AFK on Friday and Monday; maybe @c4rl0sbr4v0 and @michalczaplinski can help figure this out? 😊

[davidbaumwald]

In 54357:

Editor: Remove deprecated callable in WP_Style_Engine class.

Resolves a Use of "static" in callables is deprecated notice in = PHP 8.2 and mark WP_Style_Engine as a final class that will not be extended.

Follow-up to [54156].

Props ramonopoly, jrf, andrewserong.
See #56467.

Merged into core in https://core.trac.wordpress.org/changeset/54357.

[davidbaumwald]

In 54358:

Editor: Reintroduce styles that were removed for classic themes.

After block CSS was merged with theme.json styles in ​Gutenberg PR #34180, this removed some existing, default styling for some elements, including buttons. This change re-adds the removed styles by enqueueing classic.css for classic themes.

Merges ​Gutenberg PR #44334 into trunk.

Follow-up to [54257].

Props scruffian, oandregal, ramonopoly, aristath, andrewserong, get_dave, bernhard-reiter.
See #56467.

[kebbet]

Shouldn't wp_enqueue_classic_theme_styles in [54358] have a @since-tag?

Solved with [54359]

Thanks for the quick turn around on this, everyone! 🍺

[davidbaumwald]

In 54370:

Editor: Make template names and descriptions dynamic, again.

In the lead up to 6.1 Beta 2, dynamic titles and descriptions for site editor templates was deemed "feature incomplete" and [54280] was reverted. After further consideration, this code is being re-merged in preparation for Beta 3, reverting the revert in [54333].

Follow-up to [54280] and [54333].

Props bernie, ntsekouras, jorgefilipecosta, jameskoster, cbravobernal.
See #56467.

Includes the latest round of Gutenberg bugfix PRs that were approved for inclusion during ​yesterday’s triage session. See ​https://github.com/WordPress/gutenberg/pull/44656 for the list of PRs that were cherry-picked.

Needed for today's WP 6.1 Beta 3 release.

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

[davidbaumwald]

In 54383:

Editor: Update packages for 6.1 Beta 3.

Package updates for bug and regression fixes:

• @wordpress/annotations: 2.17.3
• @wordpress/block-directory: 3.15.4
• @wordpress/block-editor: 10.0.4
• @wordpress/block-library: 7.14.4
• @wordpress/blocks: 11.16.4
• @wordpress/components: 21.0.4
• @wordpress/core-data: 5.0.4
• @wordpress/customize-widgets: 3.14.4
• @wordpress/data: 7.1.3
• @wordpress/data-controls: 2.17.3
• @wordpress/edit-post: 6.14.4
• @wordpress/edit-site: 4.14.5
• @wordpress/edit-widgets: 4.14.4
• @wordpress/editor: 12.16.4
• @wordpress/format-library: 3.15.4
• @wordpress/interface: 4.16.3
• @wordpress/keyboard-shortcuts: 3.15.3
• @wordpress/list-reusable-blocks: 3.15.4
• @wordpress/notices: 3.17.3
• @wordpress/nux: 5.15.4
• @wordpress/preferences: 2.9.4
• @wordpress/reusable-blocks: 3.15.4
• @wordpress/rich-text: 5.15.3
• @wordpress/server-side-render: 3.15.4
• @wordpress/style-engine: 1.0.3
• @wordpress/viewport: 4.15.3
• @wordpress/widgets: 2.15.4

References:

• ​Gutenberg PR 44634 – Quote block: stop slash inserter popup showing in citation
• ​Gutenberg PR 44630 – Query Loop: Fix condition for displaying 'parents' control
• ​Gutenberg PR 44554 – Hide the Classic block in the Site Editor
• ​Gutenberg PR 44594 – Fix navigation block console error
• ​Gutenberg PR 44555 – Theme export: Fix broken spacingScale export
• ​Gutenberg PR 44580 – Code Block: Add box-sizing to fix inconsistent layout
• ​Gutenberg PR 44556 – Remove border from Global Styles previews
• ​Gutenberg PR 44141 – Spacing presets: Modify the styling of the input controls when in unlinked mode in order to better differentiate sides
• ​Gutenberg PR 44453 – Preserve the generic signature of getEntityRecord and getEntityRecords through currying
• ​Gutenberg PR 44504 – Theme.json: fix some outline properties doesn't work properly on the editor
• ​Gutenberg PR 44516 – Add style engine to editor tsconfig references
• ​Gutenberg PR 44523 – Query Loop Block: Rename Query Loop variations allowControls to allowedControls
• ​Gutenberg PR 44520 – Post Featured Image: Fix application of default border style in editor
• ​Gutenberg PR 44286 – Post Featured Image: Fix borders after addition of overlay feature
• ​Gutenberg PR 44482 – Template Editor: Fix crashes due to undefined variables
• ​Gutenberg PR 44480 – Template Parts: Prevent adding block in post editor or inside post template or content blocks
• ​Gutenberg PR 44425 – Fix rotated image crop area aspect ratio
• ​Gutenberg PR 44485 – Fix padding/margin visualizer accuracy
• ​Gutenberg PR 44569 – Theme.json: Fix some shadow properties that do not work properly in the site editor
• ​Gutenberg PR 44575 – ToggleGroupControl: Fix unselected icon color
• ​Gutenberg PR 44526 – TokenInput Field: Try alternative approach to fix screen reader focus issue
• ​Gutenberg PR 44506 – Edit Post: Optimize legacy post content layout
• ​Gutenberg PR 44258 – Add layout styles from Post Content block to post editor

Follow-up to [54257] and [54335].

Props czapla, isabel_brison, wildworks, bernhard-reiter, hellofromTonya.
See #56467.

Merged into core in https://core.trac.wordpress.org/changeset/54383.

Suggestions from @spacedmonkey in ​https://github.com/WordPress/gutenberg/pull/44645.

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

[davidbaumwald]

In 54387:

Editor: Fix server-side attribute registration via typography support.

Ensures the fontFamily attribute is registered for block types on the server side. This change resolves a 400 error when attempting to change the font family for a server-side rendered block in the editor.

Props aaronrobertshaw, mamaduka, wildworks, upadalavipul.
See #56467.

Includes one more change that was just merged into Gutenberg -- the dynamic template names PR, ​https://github.com/WordPress/gutenberg/pull/44645.

Needed for today's WP 6.1 Beta 3 release.

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

Testing:

• Created a post titled "Hello World".
• Created a template for it (automatically named "Post: Hello World".
• Renamed the post to "Hello Universe".
• Checked the template; it is now named "Post: Hello Universe".

✅

[davidbaumwald]

In 54388:

Editor: Sync latest @wordpress/edit-site package to include dynamic template names updates.

Updates @wordpress/edit-site from version 4.14.5 to version 4.14.6.

Follow-up to [54280], [54333], and [54370].

Props bernhard-reiter.
See #56467.

Merged into core in https://core.trac.wordpress.org/changeset/54388.

Rebased.

@michalczaplinski Could you re-test this and see if the re-base fixed the ​items that didn't work ❌ for @hellofromtonya?

If things still don't work, also try with the following patch:

{{{diff
diff --git a/src/wp-includes/class-wp-theme-json-resolver.php b/src/wp-includes/class-wp-theme-json-resolver.php
index 344ad3ed99..0520fbd1d6 100644
--- a/src/wp-includes/class-wp-theme-json-resolver.php
+++ b/src/wp-includes/class-wp-theme-json-resolver.php
@@ -178,7 +178,7 @@ class WP_Theme_JSON_Resolver {

$options = wp_parse_args( $options, array( 'with_supports' => true ) );

• if ( null === static::$theme ) {

+ if ( null === static::$theme ) {

$theme_json_data = static::read_json_file( static::get_file_path_from_theme( 'theme.json' ) );
$theme_json_data = static::translate( $theme_json_data, wp_get_theme()->get( 'TextDomain' ) );
/

@@ -203,7 +203,7 @@ class WP_Theme_JSON_Resolver {

$parent_theme->merge( static::$theme );
static::$theme = $parent_theme;

}

• }

+ }

if ( ! $optionswith_supports? ) {

return static::$theme;

}}}

And if that still doesn't do the trick -- any help to investigate this and track it down is appreciated 😅

Investigating this now 👀

I've tested locally by reproducing the ​testing instructions from above and I can still confirm the same results.

The result is the same with and without ​the patch.

[SergeyBiryukov]

In 54394:

Tests: Ignore EOL differences in Style Engine API tests.

Unix vs. Windows EOL style mismatches can cause misleading failures in tests using the heredoc syntax (<<<) or multiline strings as the expected result.

This resolves two failures when running the test suite on Windows along the lines of:

1) Tests_Style_Engine_wpStyleEngineCSSRule::test_should_prettify_css_rule_output
Failed asserting that two strings are identical.
--- Expected
+++ Actual
@@ @@
 #Warning: Strings contain different line endings!
-'.baptiste {
-       margin-left: 0;
-       font-family: Detective Sans;
+'.baptiste {
+       margin-left: 0;
+       font-family: Detective Sans;
}'

/var/www/tests/phpunit/tests/style-engine/wpStyleEngineCssRule.php:159

Follow-up to [46612], [48443], [48466], [49691], [51135], [53282], [53319], [54156].

See #56467, #55652.

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

## What

This PR fixes an issue by which the styles of cite element declared via theme.json are not enqueued.

## Why

All element's styles should work.

## How

By registering the element into the proper allowed list array.

## Test

• Add the following snippet to your theme's theme.json (I've tested with TwentyTwentyTwo):

{{{json
{

"elements": {

"cite": {

"color": {

"background": "hotpink"

}

}

}

}
}}}

• Go to the post editor and add a quote block. Fill it with text and a cite.

The expected result is that in the editors and the frontend the cite of the quote should have hotpink as background color.

## Notes

Note this works as expected with the Gutenberg plugin active but not in core without the plugin because ​it's part of the registry.

The failures all stem from the same issue:

Error: Can't use 'tar -xzf' extract archive file: /home/runner/work/_actions/_temp_32a0853a-9104-4759-ba7c-68850ae844d4/ee071250-5379-4bec-b7ae-dc7e0befd324.tar.gz. return code: 2.

According to the ​tar manual, this is because it could not process the file. Perhaps because there was some issue and wasn't downloaded properly? I can't re-run the tests, which should probably fix this. Can anybody help with this?

[oandregal]

Filed a PR to fix an issue with the cite element ​https://github.com/WordPress/wordpress-develop/pull/3411

@oandregal I re-ran the failed jobs, and they are OK now.

@dream-encode Thanks for that. I still see one failure for ​this job.

I've rebased and tested this and it works as expected. Coordinating with Ben to see who can rebase it.

[audrasjb]

In 54408:

Editor: Add missing blocks origin to theme.json.

This changeset updates the blocks origin name from core to blocks and adds it to the list of valid origins for theme.json.
(See the original fix in ​Gutenberg's PR 44363).

Why?

• This new origin was missing from the list.
• The core name is not reflective of what it does, as this data origin is related to block styles, whether they come with WordPress or third-party blocks.
• The existing filter for this piece of data is called theme_json_blocks, to reflect it filters "block" data.
• Though core origin was used in the past for default, this commit reverts it. Why? It was confusing. The goal is to use names that communicate what part of the pipeline are processing (default > blocks > theme > custom).

How?

• Renames the string, from core to blocks.
• Adds blocks to the list of valid origins.
• Verifies that the $theme_json->get_stylesheet() call uses the proper $origins at all times.

Follow-up to [54162], [54251].

Props oandregal, czapla, jorgefilipecosta, scruffian, bernhard-reiter hellofromTonya.
See #56467.

As asked by @oandregal, this was committed in https://core.trac.wordpress.org/changeset/54408

[jorgefilipecosta]

In 54409:

Fix: cite styles declared via theme.json not working.

Fixes an issue where cite elements declared on theme.json are not being output on the front end of the website.

Props oandregal, carolinan, scruffian.
See #56467.

Committed at ​https://github.com/WordPress/wordpress-develop/commit/f3c0f743b373c2cae4239b3dd05b7d429067c37e.

Suggestions from @spacedmonkey in ​https://github.com/WordPress/gutenberg/pull/44645.

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

Replacement for ​https://github.com/WordPress/wordpress-develop/pull/3404

[davidbaumwald]

In 54445:

Editor: Dynamic site editor template names performance improvements.

This change updates get_(posts|terms)() to direct WP_Query calls and adds additional parameters to each query to improve performance.

Follow-up to [54280], [54333], [54370], and [54388].

Props spacedmonkey, peterwilsoncc.
See #56467.

Closed in favor of ​https://github.com/WordPress/wordpress-develop/pull/3424/ and merged into core in https://core.trac.wordpress.org/changeset/54445.

Merged into core in https://core.trac.wordpress.org/changeset/54445.

Backport of Gutenberg PR 44807's PHP code ​https://github.com/WordPress/gutenberg/pull/44807

Converts incoming raw font size values that are numbers to a "value + pixel" string.

So 30 will be treated as '30px' for the purposes of fluid font size calculations 🤖

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

Work In Progress.

Related:

• Gutenberg report ​https://github.com/WordPress/gutenberg/issues/44772
• Trac ticket https://core.trac.wordpress.org/ticket/56467

## What

This PR tries to address some performance regressions introduced in WordPress 6.1.

We had to remove some of the existing caching for theme.json processing (see ​https://github.com/WordPress/wordpress-develop/pull/3408 and ​https://github.com/WordPress/wordpress-develop/pull/3359) because they're now used before all the blocks are registered (aka get template data, etc.). This resulted in the caching mechanism not working well, which was raised during the beta cycle (see ​https://github.com/WordPress/gutenberg/issues/44434 and ​https://github.com/WordPress/gutenberg/issues/44619).

## Why

It's a very noticeable degradation that stems from changes done in this cycle.

## How

• Caches the raw theme.json data for core and theme: read from file system, translation, and run filters. We only need to run these tasks once and the data won't change.
• Caches the calculated data for core and theme based on the blocks that are registered.

## Performance improvements

The test I'm doing for profiling performance is loading the "Hello World" post as a logged-out user. These are the numbers in the different setups.

| Method | WordPress 6.0 | WordPress trunk (rev 54449) | This PR |
| ---------------------------------------------------------- | ----------------- | --------------------------- | ---------------- |
| total time | 760ms | 1336ms | 787ms |
| wp_get_global_settings | 0.2ms (24 calls) | 1.2ms (72 calls) | 0.9ms (72 calls) |
| wp_get_global_stylesheet | 1ms (1 call) | 0.09ms (1 call) | 0.03ms (1 call) |
| wp_get_global_styles_svg_filters | 0.05ms (1 call) | 0.06ms (1 call) | 0.04ms (1 call) |
| wp_add_global_styles_for_blocks | - | 1.2ms (1 call) | 0.09ms (1 call) |
| WP_Theme_JSON_Resolver::get_core_data | 0.3ms (27 calls) | 53.9ms (76 calls) | 2.7ms (76 calls) |
| WP_Theme_JSON_Resolver::get_block_data | - | 20ms (76 calls) | 1.2ms (76 calls) |
| WP_Theme_JSON_Resolver::get_theme_data | 17ms (49 calls) | 264ms (98 calls) | 74ms (98 calls) |
| WP_Theme_JSON_Resolver::get_user_data | 0.08ms (27 calls) | 12.8ms (76 calls) | 0.9ms (76 calls) |
| WP_Theme_JSON_Resolver::get_merged_data | 12ms (27 calls) | 121ms (76 calls) | 108ms (76 calls) |

These numbers can be seen in the cachegrind data that follows:

• WordPress 6.0: ​cachegrind.out.6-0.gz
• Trunk at rev 54449: ​cachegrind.out.6-1-trunk-54449.gz
• This PR: ​cachegrind.out.6-1-pr-3418.gz

You can take this data and open it with any visualizer of your choice (kcachegrind, webgrind, etc.). As with the client performance numbers, the exact ms are not as important as the variance between them. I also share below how to reproduce this for anyone interested.

## How to reproduce the performance results

Enable xdebug profiling:

• Clone the ​https://github.com/WordPress/wordpress-develop repo. Apply this patch to the configuration:
• Configure the environment so xdebug profiles the application by URL:
  • Edit the .env file and set LOCAL_PHP_XDEBUG=true, and LOCAL_PHP_XDEBUG_MODE=develop,debug,profile. For WordPress 6.0, copy XDEBUG_MODE=develop,debug,profile in the docker-compose.yml file instead (see below).
  • Edit the docker-compose.yml file and add XDEBUG_CONFIG=profiler_output_name=cachegrind.out.%R.
• Open the browser and visit http://localhost:8889/?p=1 (this loads the "Hello World" post).
• As a result of this configuration, the docker container should have created a few files named /tmp/cachegrind.out.*. Verify those files exist. You may use this command <pre> docker exec -it \docker ps -f name=wordpress-develop_php -q\ ls -l /tmp</pre>

Read the profiling reports using webgrind:

• Download or clone ​https://github.com/jokkedk/webgrind in wp-content/plugins/webgrind of the wordpress-develop repo.
• Start the wordpress-develop environment normally.
• Visit ​http://localhost:8889/wp-content/plugins/webgrind/ and check the results for this branch. You'll have to do the same for checking the results in trunk and in the 6.0 branch.

Alternatively, you can read the profiling reports using kcachegrind (linux, probably qcachegrind can do the same for mac & windows?), which allows for loading the xdebug files directly so you can easily compare branches:

• Copy the files generated by xdebug for this branch (/tmp/cachegrind.out.*) somewhere outside the docker container. Do the same for the files generated for trunk and 6.0 (be aware that the files will overwrite each other, so copy before changing branches).
• For example, I copy the files by doing:

{{{sh
docker cp docker ps -f name=wordpress-develop_php -q:'/tmp/cachegrind.out.p=1.gz' /tmp/cachegrind.out.<6-0 or trunk or this-branch>.gz
}}}

• Open the app and check the results.

## How to test

Make sure automated test pass.

Manually test that global styles still works as expected by using the TT2 or TT3 themes and updating some block styles via the global styles sidebar.

Trac ticket: [](https://core.trac.wordpress.org/ticket/56467)

This PR backports changes from ​https://github.com/WordPress/gutenberg/pull/44660 to fix legacy Group block inner containers.

I forgot to test the latest changes manually per the issue instructions:

Manually test that global styles still works as expected by using the TT2 or TT3 themes and updating some block styles via the global styles sidebar.

Probably some other random tests related to global styles won't hurt. I'm now far from the computer and can't do it myself, but wanted to leave this note for reviewers.

Backports the following Fluid Typography bug fixes from Gutenberg:

• ​https://github.com/WordPress/gutenberg/pull/44762
• ​https://github.com/WordPress/gutenberg/pull/44764
• ​https://github.com/WordPress/gutenberg/pull/44761

Note: from the above PRs, any changes to files in block-library have _not_ been included, as they will form part of a backport PR for the JS/npm packages changes.

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

Gutenberg tracking issue: ​https://github.com/WordPress/gutenberg/issues/44758

To test:

• With a theme with settings.typography.fluid set to true (e.g. tests with TT3 theme), create a post and set a custom font size on a heading or paragraph block. Save the post and view on the site frontend, if you inspect the markup, the font-size inline style for those blocks should be a clamp() value with the fluid rules applied.
• In global styles, set the Typography H1 setting to a custom font-size (e.g. 4rem). Save the global styles, then on the site frontend, inspect the markup for the post or page title. The h1 element should have a styling rule associated with it with the clamp() based rules applied.

Should we add the changes from ​https://github.com/WordPress/gutenberg/pull/44807/files too?
We'll probably also want to add ​https://github.com/WordPress/gutenberg/pull/44847 once it's merged.

Yes, it'd be good to add those in. It overlaps a little with ​https://github.com/WordPress/wordpress-develop/pull/3428, but since ​https://github.com/WordPress/gutenberg/pull/44847 appears to supersede 3428, I think once the latter has landed we can pull both changes into this PR. I'll take a look once 44847 has merged.

Forgot to mention, but I also tested these changes on TT3 with both global and block-level custom font sizes, on static and dynamic blocks, and everything works as expected! (Except for the dynamic blocks with exceptional behaviour that require block-library changes, those will only work after the package updates.)

Thanks for reviewing @tellthemachines!

In ​https://github.com/WordPress/wordpress-develop/pull/3431/commits/05f88988f0945395753d22e1cf011834d2dec1cf, I've had a go at adding in changes from the following:

• ​https://github.com/WordPress/gutenberg/pull/44807
• The adjustments to the above change proposed in ​https://github.com/WordPress/wordpress-develop/pull/3428
• The PHP changes from ​https://github.com/WordPress/gutenberg/pull/44847

Please let me know if I missed anything @ramonjd!

To try to consolidate things (and avoid potential merge conflicts), I've rolled the changes in this PR and ​https://github.com/WordPress/gutenberg/pull/44847 into ​https://github.com/WordPress/wordpress-develop/pull/3431 which seeks to backport all the current / recently merged PHP changes for fluid typography (excluding changes to the block-library directory, which I believe will be handled as part of the npm packages updates).

This is working well for me. Custom and preset fluid sizes are appearing as expected in the frontend, including:

• theme.json fontsize presets
• global style changes to elements and blocks
• block support styles (inline)

Also checked the PHP unit tests for 8.2 compat warnings ;)

Please let me know if I missed anything @ramonjd!

Awesome stuff @andrewserong, thank you!

I think you've covered all the backend changes and PHP unit tests.

Tested in Chrome, Safari and Firefox

​https://user-images.githubusercontent.com/6458278/195006750-73fc1a0c-deed-4e2b-9d35-6ed4593cfb4a.mp4

@oandregal Please check ​https://github.com/WordPress/wordpress-develop/pull/3418#pullrequestreview-1136795378

I tested this myself manually using TT2 and TT3 themes. I tested empty state for each theme and updating the user values from the global styles' sidebar (selecting a style variation, specific changes to some blocks, etc.). It's working as expected.

Includes the latest round of Gutenberg bugfix PRs that were approved for inclusion during ​yesterday’s triage session. The following Gutenberg PRs were cherry-picked:

• ​https://github.com/WordPress/gutenberg/pull/44640
• ​https://github.com/WordPress/gutenberg/pull/44652
• ​https://github.com/WordPress/gutenberg/pull/44584
• ​https://github.com/WordPress/gutenberg/pull/43181
• ​https://github.com/WordPress/gutenberg/pull/44650
• ​https://github.com/WordPress/gutenberg/pull/44731
• ​https://github.com/WordPress/gutenberg/pull/44660
• ​https://github.com/WordPress/gutenberg/pull/44718
• ​https://github.com/WordPress/gutenberg/pull/44721
• ​https://github.com/WordPress/gutenberg/pull/44463
• ​https://github.com/WordPress/gutenberg/pull/44415
• ​https://github.com/WordPress/gutenberg/pull/44676
• ​https://github.com/WordPress/gutenberg/pull/44150
• ​https://github.com/WordPress/gutenberg/pull/44098
• ​https://github.com/WordPress/gutenberg/pull/44637

Needed for today's WP 6.1 RC 1 release.

_Note that this does not include the Fluid Typography fixes (see ​https://github.com/WordPress/gutenberg/issues/44758 and ​https://github.com/WordPress/wordpress-develop/pull/3431). For those, I will file a separate PR, in order to de-risk things -- allowing us to merge this PR and consider those changes separately._

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

Unit tests where would be useful.

Unit tests where would be useful.

To get a change this big merged in at the last minute, then unit tests are must. We do not want a regression at this late stage.

To get a change this big merged in at the last minute, then unit tests are must. We do not want a regression at this late stage.

We have dozens of unit tests for this code already that cover the existing behavior. I've been using them to drive changes in this PR as they were failing at the beginning.

Having "more test" sounds good to me. At the same time, I also want to be mindful of the time and resources we all have to move this forward, so in the name of efficiency I'd like to ask: what additional tests do we need that are a blocker for merging?

_Alternative to #3434. It's also possible to merge #3434 first, and then merge this PR, which contains all the changes from #3434, plus the Fluid Typography fixes (see ​https://github.com/WordPress/gutenberg/issues/44758 and ​https://github.com/WordPress/wordpress-develop/pull/3431)._

Includes the latest round of Gutenberg bugfix PRs that were approved for inclusion during ​yesterday’s triage session. The following Gutenberg PRs were cherry-picked:

• ​https://github.com/WordPress/gutenberg/pull/44640
• ​https://github.com/WordPress/gutenberg/pull/44652
• ​https://github.com/WordPress/gutenberg/pull/44584
• ​https://github.com/WordPress/gutenberg/pull/43181
• ​https://github.com/WordPress/gutenberg/pull/44650
• ​https://github.com/WordPress/gutenberg/pull/44731
• ​https://github.com/WordPress/gutenberg/pull/44660
• ​https://github.com/WordPress/gutenberg/pull/44718
• ​https://github.com/WordPress/gutenberg/pull/44721
• ​https://github.com/WordPress/gutenberg/pull/44463
• ​https://github.com/WordPress/gutenberg/pull/44415
• ​https://github.com/WordPress/gutenberg/pull/44676
• ​https://github.com/WordPress/gutenberg/pull/44150
• ​https://github.com/WordPress/gutenberg/pull/44098
• ​https://github.com/WordPress/gutenberg/pull/44637

Furthermore, this includes the Fluid Typography fixes listed in ​https://github.com/WordPress/gutenberg/issues/44758.

Needed for today's WP 6.1 RC 1 release.

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

There are not unit tests for the following methods.

• get_core_data
• has_same_registered_blocks
• get_theme_data
• get_user_data

I don't think we have enough coverage to merge this change. Tests to prove that methods above do as expected. Check cleaning caches was as expected and code is not being run again after cache working as expected.

There are basically no changes to WordPress that should not come along with a unit test. Something this important NEEDS them before the mege.

Currently looking at test coverage for the changes in this PR.

I think this code is mostly OK as-is, aside from updating the function prefix from gutenberg to wp.

Good catch! Since this is dynamic block PHP, we'll have to do that in Gutenberg, as that code is sync'ed from the @wordpress/block-library package during Core's build process.

[davidbaumwald]

In 54483:

Editor: Update packages for 6.1 Release Candidate 1.

Package updates for bug and regression fixes:
@wordpress/block-directory: 3.15.6
@wordpress/block-editor: 10.0.6
@wordpress/block-library: 7.14.6
@wordpress/components: 21.0.5
@wordpress/customize-widgets: 3.14.6
@wordpress/edit-post: 6.14.6
@wordpress/edit-site: 4.14.8
@wordpress/edit-widgets: 4.14.6
@wordpress/editor: 12.16.6
@wordpress/format-library: 3.15.6
@wordpress/interface: 4.16.5
@wordpress/list-reusable-blocks: 3.15.5
@wordpress/nux: 5.15.5
@wordpress/preferences: 2.9.5
@wordpress/reusable-blocks: 3.15.6
@wordpress/server-side-render: 3.15.5
@wordpress/widgets: 2.15.6

References:

• ​Gutenberg PR 43181 - Merge inner blocks if wrappers are equal
• ​Gutenberg PR 44098 - Fix content blocks with nested blocks always appear as top level
• ​Gutenberg PR 44150 - Refresh selection styles
• ​Gutenberg PR 44415 - Removes __unstableMaxPages attribute from Page List and Nav blocks
• ​Gutenberg PR 44463 - Follow discussion settings in the comments block edit
• ​Gutenberg PR 44584 - Avoid querying block templates during installation
• ​Gutenberg PR 44637 - Resizable editor: Fix height setting bug
• ​Gutenberg PR 44640 - Only include theme.css if the theme declares support for wp-block-styles
• ​Gutenberg PR 44650 - Fix empty links being created for the author's name comment
• ​Gutenberg PR 44652 - Block Editor: Fix block search for non-Latin characters
• ​Gutenberg PR 44660 - Legacy Group inner block wrapper should work with constrained layout
• ​Gutenberg PR 44676 - Hide list items from content area of content locked blocks
• ​Gutenberg PR 44718 - Margin visualizer: Apply negative value to margins with calc()
• ​Gutenberg PR 44721 - Remove anchor support from the navigation block
• ​Gutenberg PR 44731 - Buttons: Add specificity for the editor

Follow-up to [54257], [54335], and [54383].

Props bernhard-reiter, czapla, annezazu, cbravobernal, ndiego, bjorsch, nendeb55.
See #56467.

Merged into core in https://core.trac.wordpress.org/changeset/54483.

[davidbaumwald]

In 54486:

Editor: Change gutenberg_get_typography_font_size_value() calls to wp_get_typography_font_size_value().

Merged Gutenberg functions should be prefixed with wp_.

Follow-up to [54483].

Props spacedmonkey.
See #56467.

Merged into core in https://core.trac.wordpress.org/changeset/54483.

I believe @dream-encode merged the version without the Fluid Typography changes (​https://github.com/WordPress/wordpress-develop/pull/3434). Reopening 😅

[davidbaumwald]

In 54487:

Editor: Remove extra line break in build_template_part_block_instance_variations().

This extra break was causing a QUnit failure check validating version controlled file contents.

Follow-up to [54483].

See #56467.

Merged into core by @davidb in https://core.trac.wordpress.org/changeset/54483.

Okay, here's what I've done:

• Tested it manually (though not as thorough as I'd like) - not seeing any issues
• Added _some_ additional PHPUnit tests for this PR including:
  • WP_Theme_JSON_Resolver::has_same_registered_blocks() - though this is a non-public method, it's the heart of the changes here. So test coverage helps to validate it works as expected.
  • WP_Theme_JSON_Resolver::get_core_data()

What else is needed?

• More tests are needed.
• The test class needs a lot of love (though out of scope for this PR).
• A lot more manual testing is needed.
• A lot more performance testing is needed.

IMO Though this PR is ready "enough" for RC1 with the condition that more tests and testing will happen by 6.1 RC2. Why? It's a significant enough performance regression to warrant getting it fixed. More extenders typically test during the RC cycle. So releasing as part of RC1 gives more testing and feedback exposure for any additional unknowns or work that may be needed.

@ockham ,I m not inconvénients into this project. Maybe wrong @ into your comment.

I think this code is mostly OK as-is, aside from updating the function prefix from gutenberg to wp.

Good catch! Since this is dynamic block PHP, we'll have to do that in Gutenberg, as that code is sync'ed from the @wordpress/block-library package during Core's build process.

​https://github.com/WordPress/gutenberg/pull/44876

Amazing, thank you very much for testing, @hellofromtonya!

• WP_Theme_JSON_Resolver::has_same_registered_blocks() - though this is a non-public method, it's the heart of the changes here. So test coverage helps to validate it works as expected.

Awesome, exactly my thinking 👍

IMO This PR is ready "enough" for RC1 with the condition that more tests and testing will happen by 6.1 RC2. Why? It's a significant enough performance regression to warrant getting it fixed. More extenders typically test during the RC cycle. So releasing as part of RC1 gives more testing and feedback exposure for any additional unknowns or work that may be needed.

I agree 100%.

I wish I could've helped more getting this across the finish line, but I'm very very grateful we got this ready for RC1. Thanks again also to @oandregal for this fix, and your thorough profiling!

I'll make a note to add more test coverage before RC2.

@ockham ,I m not inconvénients into this project. Maybe wrong @ into your comment.

My bad! I meant @dream-encode. Sorry for the mixup!

To include ​https://github.com/WordPress/gutenberg/pull/44876. From the PR desc:

In dynamic blocks, use a wp_ prefixed wp_get_typography_font_size_value rather than its gutenberg_ counterpart, gutenberg_get_typography_font_size_value.

See ​https://github.com/WordPress/wordpress-develop/pull/3437#issuecomment-1274846664 for the rationale.

## Testing Instructions
Insert one of the affected blocks (Navigation Link, Navigation Submenu, Page List, Search) and set its font size.
Save and view on the frontend. Confirm that it works, and no fatals are thrown.

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

Merged into core in https://core.trac.wordpress.org/changeset/54483.

I believe @dream-encode merged the version without the Fluid Typography changes (#3434). Reopening 😅

Ah, looks like it _was_ actually this one that was merged! Apologies for the confusion. Closing again; ​https://github.com/WordPress/wordpress-develop/pull/3439 is the follow-up to prevent the gutenberg_ prefix from being re-written during build.

(FWIW, looks like it was actually #3437 that was merged. Since that PR includes the changes made in this one, we can keep in closed.)

[davidbaumwald]

In 54490:

Editor: Bump @wordpress packages for 6.1 Release Candidate 1.

Package updates for bug and regression fixes:
@wordpress/block-directory: 3.15.7
@wordpress/block-library: 7.14.7
@wordpress/customize-widgets: 3.14.7
@wordpress/edit-post: 6.14.7
@wordpress/edit-site: 4.14.9
@wordpress/edit-widgets: 4.14.7

Follow-up to [54257], [54335], [54383], [54483], and [54486].

Props bernhard-reiter.
See #56467.

[hellofromTonya]

In 54491:

Editor: Fix version in WP_Theme_JSON_Resolver::get_block_data().

Introduced during the WP 6.1 alpha cycle, this commit fixes the version number from 1 to 2.

Follow-up to [54162].

Props oandregal.
See #56467.

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

Follow-up to ​https://github.com/WordPress/wordpress-develop/pull/3424/.

[hellofromTonya]

In 54493:

Editor: Fix performance regression in WP_Theme_JSON_Resolver.

A significant performance regression was added late in WP 6.1 beta cycle when some of the existing caching for theme.json processing was removed. The rationale for removing the caching was this code was now used before all the blocks are registered (aka get template data, etc.) and resulted in stale cache that created issues (see ​Gutenberg Issue 44434 and ​Gutenberg Issue 44619). The changes were limited to only reads from the file system. However, it introduced a big impact in performance.

This commit adds caching and checks for blocks with different origins. How? It add caching for the calculated data for core, theme, and user based on the blocks that are registered. If the blocks haven't changed since the last time they were calculated for the origin, the cached data is returned. Otherwise, the data is recalculated and cached.

Essentially, this brings back the previous cache, but refreshing it when the blocks change.

It partially adds unit tests for these changes. Additional tests will be added.

References:

• ​Performance regression in WP 6.1 for theme.json processing

Follow-up to [54251], [54399].

Props aristath, oandregal, bernhard-reiter, spacedmonkey, hellofromTonya.
See #56467.

Committed via changeset https://core.trac.wordpress.org/changeset/54493.

[davidbaumwald]

In 54494:

Editor: Ensure WP_Query and WP_Term_Query results are referenced properly when creating dynamic template names for use in the site editor.

[54445] updated the new dynamic template name functions used by the site editor in 6.1 to use WP_Query and WP_Term_Query instances in place of get_posts and get_terms respectively. However, the latter functions return an array of results whereas WP_Query instances store their found results in a class property. This change updates the code to reference either $posts_query->posts or $terms_query->terms where necessary.

Follow-up to [54280], [54333], [54370], [54388], and [54445].

Props bernhard-reiter, spacedmonkey, davidbaumwald.
See #56467.

See:

• Performance issue ​https://github.com/WordPress/gutenberg/issues/44772
• Trac ticket https://core.trac.wordpress.org/ticket/56467

## What

Follow up to ​https://github.com/WordPress/wordpress-develop/pull/3418

## Why

We want to squeeze as many ms as possible.

## How

In the WordPress 6.1 cycle, WP_Theme_JSON_Resolver::get_merged_data method has become a hot path that is called many times. By improving small things that are repeated multiple times, we get more performance wins. This PR changes this code:

{{{php
public static function get_merged_data( $origin = 'custom' ) {

...

$result = new WP_Theme_JSON();
$result->merge( static::get_core_data() );
$result->merge( static::get_block_data() );
$result->merge( static::get_theme_data() );

...

}
}}}

to:

{{{php
public static function get_merged_data( $origin = 'custom' ) {

...

$result = static::get_core_data();
$result->merge( static::get_block_data() );
$result->merge( static::get_theme_data() );

...

}
}}}

As a result, this reduces from 402 to 326 the number of calls of the low-level WP_Theme_JSON->merge method.

## Performance improvements

| Method | WordPress 6.0 | WordPress trunk (rev 54449) | This PR |
| ----------------------------------------- | ---------------- | --------------------------- | ---------------- |
| total time | 760ms | 1336ms | 726ms |
| wp_get_global_settings | 0.2ms (24 calls) | 1.2ms (72 calls) | 0.8ms (72 calls) |
| wp_get_global_stylesheet | 1ms (1 call) | 0.09ms (1 call) | 0.03ms (1 call) |
| wp_add_global_styles_for_blocks | - | 1.2ms (1 call) | 1ms (1 call) |
| WP_Theme_JSON_Resolver::get_merged_data | 12ms (27 calls) | 121ms (76 calls) | 41ms (76 calls) |
| WP_Theme_JSON->merge | 26ms (130 calls) | 107ms (402) | 59ms (326 calls) |

See ​https://github.com/WordPress/wordpress-develop/pull/3418 for instruction on how to reproduce these numbers yourself. You can also use the following cachegrind files to visualize:

• WordPress 6.0: ​cachegrind.out.6-0.gz
• Trunk at rev 54449: ​cachegrind.out.6-1-trunk-54449.gz
• This PR:

## Test

• Make sure automated test pass.
• Manually test that global styles still works as expected by using the TT2 or TT3 themes and updating some block styles via the global styles sidebar.
• Use a localized WordPress and verify that translations for colors are still applied.

I'm still investigating this for further improvement and have created ​https://github.com/WordPress/wordpress-develop/pull/3441 as a follow-up.

[davidbaumwald]

In 54497:

Editor: Merge latest fluid typography bugfixes for 6.1 Release Candidate 1.

Merges the following:

• ​Gutenberg PR 44761 - Fluid Typography: Fix bug in global styles where fluid clamp() rules were not calculated for custom values
• ​Gutenberg PR 44762 - Fluid Typography: Convert server-side block support values
• ​Gutenberg PR 44764 - Fluid Typography: Convert font size inline style attributes to fluid values
• ​Gutenberg PR 44807 - Fluid Typography: Covert font size number values to pixels
• ​Gutenberg PR 44847 - Fluid Typography: ensure font sizes are strings or integers

Follow-up to [54280].

Props andrewserong, isabel_brison, ramonopoly.
See #56467.

[davidbaumwald]

In 54500:

Editor: Add test data for Fluid Typography.

Follow-up to [54280] and [54497].

Props desrosj, hellofromTonya, SergeyBiryukov.
See #56467.

Thank you so much for the reviews and feedback everyone, and for all the updates and landing this one in time @dream-encode! Much appreciated 🙇

Since these changes have been committed in ​https://github.com/WordPress/wordpress-develop/commit/a874e5fe5e0d894eea57ece5a847828f6f29552f#diff-5a0816c84e79d4906f109a954660c8548243cf0aad0f0aa06fadf1f204d608c4, I'll close out this PR now.

I think we can close this one now that ​https://github.com/WordPress/wordpress-develop/pull/3431 has landed?

Merged into core by @dream-encode in https://core.trac.wordpress.org/changeset/54490.

I think we can close this one now that #3431 has landed?

Yeah, should be fine 👍

Merged into core by @dream-encode in https://core.trac.wordpress.org/changeset/54494.

I've rebased this PR to be based on trunk@54506 and recalculated data for WordPress 6.0, WordPress 6.1 RC1 and this PR.

Testing as follows:

• On trunk, switch to a Classic Theme (e.g. TT1).
• Create a new post, and insert the Group block.
• Inside the Group block, insert the Columns block. Choose e.g. a 33/66 two-column layout.
• In each column, insert a paragraph block, and enter some text.
• Publish the post, and view on the frontend.
• Check the page source for the Group block: There's no div with class wp-block-group__inner-container.

Then, switch to this branch, re-install npms and rebuild.

• Reload the post. While there is no visual difference compared to trunk, the page source now _has_ a div with class wp-block-group__inner-container.

| trunk | This branch |

|

| | |

A ​quick search of wp-block-group__inner-container in this repo reveals that it is indeed used for styling in Classic Themes, e.g. in Twenty Nineteen, Twenty Twenty, or Twenty Twenty One ✅

---

@tellthemachines Please don't forget to include testing instructions in PRs like this. I'm not very familiar with the Group block myself, and testing instructions in the originating Gutenberg ​PR and ​issue were rather sparse, and they didn't make it abundantly clear _why_ this is an issue that warrants a fix during the RC phase.

It'd be great to have step-by-step instructions and before/after visuals that illustrate how badly this would break existing themes -- ideally in a more compelling way than my little frontend page source screenshots.

cc @ockham @hellofromtonya this is ready for review/merge.

There are some failures in the PHPUnit Tests / 8.2 on ubuntu-latest job. These are totally unrelated to this PR and I don't know why they fail. They say things such as:

{{{bash
For automated test runs, this test is only run on trunk
This test requires the index to be truncated.
Rendering PDFs is not supported on this system.
The image editor engine WP_Image_Editor_Imagick is not supported on this system.
}}}

I'd appreciate if someone could re-run these or provide help on what's happening to unblock this PR.

I am happy to merge this since it's a very tightly scoped fix and appears to remedy a bug introduced during the 6.1 cycle. I agree with @ockham that I'd like to see some more testing to ensure this resolves the known issue, but, more importantly, doesn't have any unintended side effects.

@c4rl0sbr4v0 @michalczaplinski Since I'll be AFK tomorrow, would y'all mind working with @hellofromtonya to add unit test coverage (see ​https://github.com/WordPress/wordpress-develop/pull/3418#issuecomment-1274539686 and ​https://github.com/WordPress/wordpress-develop/pull/3418#issuecomment-1274916922) in a follow-up PR? (Let's maybe also file a Trac ticket targeting 6.1 to have it on file.)

@tellthemachines Please don't forget to include testing instructions in ​https://github.com/WordPress/gutenberg/pull/44660s like this. I'm not very familiar with the Group block myself, and testing instructions in the originating Gutenberg PR and ​https://github.com/WordPress/gutenberg/issues/44636 were rather sparse, and they didn't make it abundantly clear why this is an issue that warrants a fix during the RC phase.

Ok, but this is not usual procedure for backports, and please remember this is only being committed during RC because it was left out of the pre-RC backports even though it was linked to the correct Trac ticket.

Thanks @oandregal This change improve the performance in my test.

Rebased from trunk to address the ​environment failures. I've seen some test have been disabled since this was reported.

[jorgefilipecosta]

In 54517:

Global Styles: Improve performance of WP_Theme_JSON::get_merged_data method.

In the WordPress 6.1 cycle, WP_Theme_JSON_Resolver::get_merged_data method has become a hot path that is called many times. By improving small things that are repeated multiple times, we get more performance wins.
This commit reduces the number of calls of the low-level WP_Theme_JSON->merge method, with the corresponding performance improvements.

Props oandregal, aristath, mukeshpanchal27.
See #56467.

Committed to trunk in ​https://github.com/WordPress/wordpress-develop/commit/cb98544ed1fe76e62823a9397087433215f8f3f2. We should leave the PR open until there is a 6.1 branch and we confirm the commit is there (because the branch was created after the commit) or the commit is not there, but we do the backport.

No need to leave this open. The 6.1 branch will be copied from the latest state of trunk, and the changeset will be included.

[davidbaumwald]

I'm happy to commit the fix in ​https://github.com/WordPress/wordpress-develop/pull/3430.

Can I get a second review before doing so?

Includes the latest round of Gutenberg bugfix PRs that were approved for inclusion during ​yesterday’s triage session. The following Gutenberg PRs were cherry-picked (see the corresponding ​GB PR):

• ​https://github.com/WordPress/gutenberg/pull/45041
• ​https://github.com/WordPress/gutenberg/pull/45045
• ​https://github.com/WordPress/gutenberg/pull/44999
• ​https://github.com/WordPress/gutenberg/pull/44972
• ​https://github.com/WordPress/gutenberg/pull/44858
• ​https://github.com/WordPress/gutenberg/pull/44878
• ​https://github.com/WordPress/gutenberg/pull/44809
• ​https://github.com/WordPress/gutenberg/pull/44864
• ​https://github.com/WordPress/gutenberg/pull/44853
• ​https://github.com/WordPress/gutenberg/pull/45050
• ​https://github.com/WordPress/gutenberg/pull/44887

Needed for today's WP 6.1 RC 2 release.

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

[SergeyBiryukov]

In 54632:

Editor: Update packages for 6.1 Release Candidate 2.

Package updates for bug and regression fixes:

• @wordpress/block-directory: 3.15.8
• @wordpress/block-editor: 10.0.7
• @wordpress/block-library: 7.14.8
• @wordpress/components: 21.0.6
• @wordpress/customize-widgets: 3.14.8
• @wordpress/edit-post: 6.14.8
• @wordpress/edit-site: 4.14.10
• @wordpress/edit-widgets: 4.14.8
• @wordpress/editor: 12.16.7
• @wordpress/format-library: 3.15.7
• @wordpress/interface: 4.16.6
• @wordpress/list-reusable-blocks: 3.15.6
• @wordpress/nux: 5.15.6
• @wordpress/preferences: 2.9.6
• @wordpress/reusable-blocks: 3.15.7
• @wordpress/server-side-render: 3.15.6
• @wordpress/widgets: 2.15.7

Original PRs from Gutenberg repository:

• ​#45041 Font Size Picker Hint: Fallback to font size `slug` if `name` is undefined
• ​#45045 Add: Missing output escaping on some blocks
• ​#44999 Escape comment author URL
• ​#44972 Navigator: restore focus only once per location
• ​#44858 Spacing Sizes Control: Try improving layout spacing
• ​#44878 Fix: Inspector is usable on the top level block even if it is content locked
• ​#44809 Fix list outdents on Enter in quote block
• ​#44864 List v2: fix selection when creating paragraph from empty list item
• ​#44853 Fix overflowing patterns
• ​#45050 Fix visibility of nested Group block appender
• ​#44887 wp-env: Use case insensitive regex when checking WP version string

Follow-up to [54257], [54335], [54383], [54483], [54486], [54490].

Props bernhard-reiter, audrasjb.
See #56467.

Thanks for the PR! Merged in r54632.

[desrosj]

Resetting the action-based keywords so the status is accurately depicted in ticket reports.

[Bernhard Reiter]

Noting that I've reviewed and ​approved ​https://github.com/WordPress/wordpress-develop/pull/3430.

[davidbaumwald]

In 54633:

Editor: Fix legacy group inner block wrappers in constrained layouts.

Reviewed by bernhard-reiter.

Props isabel_brison, noisysocks, andrewserong, poena, bernhard-reiter.
See #56467.

Merged into core in https://core.trac.wordpress.org/changeset/54633.

[davidbaumwald]

Resetting the keywords after r54633.

This PR backports the typography bugfix from ​https://github.com/WordPress/gutenberg/pull/44993

It:

• adds default minimum font size limits so that min font size, where provided, does not become smaller than 14px/0.875rem/0.875em.
• For font sizes of < 14px that have no defined minimum sizes, uses the font size to set the floor of the clamp() value.

Reasons for backporting:

This bugfix prevents converting existing small font sizes to clamp values that will reduce their font size even further in narrow widths. It therefore improves backwards compatibility and accessibility.

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

Gutenberg bug issue: ​https://github.com/WordPress/gutenberg/issues/44957
Gutenberg PR: ​https://github.com/WordPress/gutenberg/pull/44993

### Testing

See ​https://github.com/WordPress/gutenberg/pull/44993 for comprehensive testing instructions.

❗ This only affects the frontend.

Enable TT3 theme

In the editor reduce a text block's font size to 10px

Publish and inspect the element on the frontend. The font-size should be font-size: clamp(10px, 0.625rem + ((1vw - 7.68px) * 0.601), 15px);

Edit the theme.json to include a font size preset whose min font size is <14px/0.875rem

{{{json

{

"fluid": {

"min": "0.3rem",
"max": "40px"

},
"size": "1rem",
"slug": "small"

},

}}}

The generated preset's min value in the clamp() function should not be <14px/0.875rem:

--wp--preset--font-size--small: clamp(0.875rem, 0.875rem + ((1vw - 0.48rem) * 3.125), 40px);

cc @tellthemachines @noisysocks @andrewserong to check things out and make sure there's nothing missing 😄

[SergeyBiryukov]

In 54646:

Editor: Add font size constraints for fluid typography.

This commit:

• Adds default minimum font size limits so that min font size, where provided, does not become smaller than 14px/0.875rem/0.875em.
• For font sizes of < 14px that have no defined minimum sizes, uses the font size to set the floor of the clamp() value.

This bugfix prevents converting existing small font sizes to clamp values that will reduce their font size even further in narrow widths. It therefore improves backward compatibility and accessibility.

Original PR from Gutenberg repository:

• ​#44993 Fluid typography: add font size constraints

Follow-up to [54260], [54360], [54497], [54500].

Props ramonopoly, andrewserong, isabel_brison, Joen, bernhard-reiter.
See #56467.

[SergeyBiryukov]

In 54647:

Editor: Add font size constraints for fluid typography.

This commit:

• Adds default minimum font size limits so that min font size, where provided, does not become smaller than 14px/0.875rem/0.875em.
• For font sizes of < 14px that have no defined minimum sizes, uses the font size to set the floor of the clamp() value.

This bugfix prevents converting existing small font sizes to clamp values that will reduce their font size even further in narrow widths. It therefore improves backward compatibility and accessibility.

Original PR from Gutenberg repository:

• ​#44993 Fluid typography: add font size constraints

Follow-up to [54260], [54360], [54497], [54500].

Props ramonopoly, andrewserong, isabel_brison, Joen, bernhard-reiter.
Reviewed by bernhard-reiter, SergeyBiryukov.
Merges [54646] to the 6.1 branch.
See #56467.

Thanks for the PR! Merged in r54646, backported to the 6.1 branch in r54647.

I'm very grateful for the quick reviews and commit. Thank you!

[Bernhard Reiter]

In 54687:

Editor: Correctly apply Button block styles for classic themes

In [54358], styling for Button blocks that had been removed from classic themes was reintroduced. However, it was added with a global scope, whereas editor styles are usually added with a .editor-styles-wrapper selector, which makes them more specific.

This change modifies the way that classic theme styles are added so that they also get wrapped in an .editor-styles-wrapper selector to match specificity.

Furthermore, adjust specificity for some Button block related styling in the editor for the Twenty Twelve and Twenty Twenty themes.

Merges ​Gutenberg PR 44731 into trunk.

Follow-up to [54358].
Props scruffian, cbravobernal, sabernhardt, audrasjb.
See #56467.

[Bernhard Reiter]

Can I get a second review for backporting [54687] to the 6.1 branch please? :)

[SergeyBiryukov]

[54687] looks good to backport to the 6.1 branch.

Backporting ​https://github.com/WordPress/gutenberg/pull/45275

Just adding a type check to prevent warnings or fatal errors.

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

[Bernhard Reiter]

In 54688:

Editor: Correctly apply Button block styles for classic themes

In [54358], styling for Button blocks that had been removed from classic themes was reintroduced. However, it was added with a global scope, whereas editor styles are usually added with a .editor-styles-wrapper selector, which makes them more specific.

This change modifies the way that classic theme styles are added so that they also get wrapped in an .editor-styles-wrapper selector to match specificity.

Furthermore, adjust specificity for some Button block related styling in the editor for the Twenty Twelve and Twenty Twenty themes.

Merges ​Gutenberg PR 44731 into trunk.

Follow-up to [54358].
Props scruffian, cbravobernal, sabernhardt, audrasjb.
Merges [54687] to the 6.1 branch.
See #56467.

[desrosj]

Resetting the action-based keywords.

To put this into context -- @scruffian has shared with Carlos and I that he encountered ​this issue in the wild. It has so far however proven somewhat hard to reproduce (​see).

Carrying over ​my comment on the GB PR:

FWIW, I don't mind adding the in_array check, since it seems like it can't have any negative side effects.

Ideally, I'd like to be able to reproduce the issue (​see) and verify the fix.

Finally, I'd like to understand which code path leads to $user_cpt being null here? Seems like ​`get_user_data_from_wp_global_styles` would ​fall back to an empty array pretty much always 🤔

I've removed my approval. why?

See the discussion in Slack ​https://wordpress.slack.com/archives/C02RQBWTW/p1666706883839909. The root cause is not yet known. While I lean into type checking to ensure the expected data type exists (which is why I initially approved it), without knowing the root cause, the type check could be masking a problem by skipping over the expected logic. A better approach would be:

• First, identify the root cause. If expected, then add the type check; else, resolve the issue where the root cause exists.
• If this should always be an array, then a data type check _with a notice_ (when not an array) can be considered. Why? To alert developers rather than quietly skipping the logic.

I think more information is needed before attempting to fix.

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

Includes:
​https://github.com/WordPress/gutenberg/pull/45163

Take two of ​https://github.com/WordPress/wordpress-develop/pull/3524. Originally based on ​yesterday’s triage session, the list of PRs to include was pruned following a ​discussion of each PR.

The following Gutenberg PRs are included in this update:

• ​https://github.com/WordPress/gutenberg/pull/45189
• ​https://github.com/WordPress/gutenberg/pull/45234
• ​https://github.com/WordPress/gutenberg/pull/45161
• ​https://github.com/WordPress/gutenberg/pull/45159
• ​https://github.com/WordPress/gutenberg/pull/45169
• ​https://github.com/WordPress/gutenberg/pull/45166
• ​https://github.com/WordPress/gutenberg/pull/45173
• ​https://github.com/WordPress/gutenberg/pull/44854
• ​https://github.com/WordPress/gutenberg/pull/45074
• ​https://github.com/WordPress/gutenberg/pull/45163
• ​https://github.com/WordPress/gutenberg/pull/45118

The following PRs were _excluded_:

• ~​https://github.com/WordPress/gutenberg/pull/45143~ ​_(Discussion)_
• ~​https://github.com/WordPress/gutenberg/pull/44213~ ​_(Discussion)_
• ~​https://github.com/WordPress/gutenberg/pull/44993~ ​_(Discussion)_

Furthermore, we're not including the following PRs in the above list since they only affect Gutenberg’s own test environment but have no impact on Core:

• ~​https://github.com/WordPress/gutenberg/pull/45087~
• ~​https://github.com/WordPress/gutenberg/pull/45265~

Needed for today's WP 6.1 RC 3 release.

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

[Bernhard Reiter]

In 54693:

Editor: Update packages for 6.1 Release Candidate 3.

Package updates for bug and regression fixes:

• @wordpress/block-directory: 3.15.10
• @wordpress/block-editor: 10.0.9
• @wordpress/block-library: 7.14.10
• @wordpress/customize-widgets: 3.14.10
• @wordpress/edit-post: 6.14.10
• @wordpress/edit-site: 4.14.12
• @wordpress/edit-widgets: 4.14.10
• @wordpress/editor: 12.16.9
• @wordpress/format-library: 3.15.9
• @wordpress/reusable-blocks: 3.15.9
• @wordpress/widgets: 2.15.9

Original PRs from Gutenberg repository:

• [WordPress/gutenberg#45189 Gutenberg PR 45189] - Fix resizeable editor scrolling
• [WordPress/gutenberg#45234 Gutenberg PR 45234] - Reset background-image property for outline button style
• [WordPress/gutenberg#45161 Gutenberg PR 45161] - Table Block: Add a deprecation for the figcaption element class name
• [WordPress/gutenberg#45159 Gutenberg PR 45159] - File Block: Add a deprecation for the button element class name
• [WordPress/gutenberg#45169 Gutenberg PR 45169] - Video: Add a deprecation for the caption element
• [WordPress/gutenberg#45166 Gutenberg PR 45166] - Embed: Add deprecation for the caption element
• [WordPress/gutenberg#45173 Gutenberg PR 45173] - Gallery: Add a deprecation for captions in the gallery block
• [WordPress/gutenberg#44854 Gutenberg PR 44854] - Embed Block: Add support for Tumblr Dashboard URLs
• [WordPress/gutenberg#45074 Gutenberg PR 45074] - Post editor: Rename view to Preview
• [WordPress/gutenberg#45163 Gutenberg PR 45163] - Featured Image Block: Add missing output escaping
• [WordPress/gutenberg#45118 Gutenberg PR 45118] - [WP6.1] Site editor clips body background style

Follow-up to [54257], [54335], [54383], [54483], [54486], [54490], and [54632].
Props czapla, cbravobernal, ndiego, annezazu, davidbaumwald, desrosj, mikeschroder, hellofromtonya, ocean90.
See #56467.

Thank you, folks!

Committed to Core trunk in r59693.

[davidbaumwald]

Tagging for a second committer review.

[hellofromTonya]

[54693] LGTM for backport to 6.1 branch.

[desrosj]

[54693] looks good to me as well!

[davidbaumwald]

In 54694:

Editor: Update packages for 6.1 Release Candidate 3.

Package updates for bug and regression fixes since 6.1 RC 2:

• @wordpress/block-directory: 3.15.10
• @wordpress/block-editor: 10.0.9
• @wordpress/block-library: 7.14.10
• @wordpress/customize-widgets: 3.14.10
• @wordpress/edit-post: 6.14.10
• @wordpress/edit-site: 4.14.12
• @wordpress/edit-widgets: 4.14.10
• @wordpress/editor: 12.16.9
• @wordpress/format-library: 3.15.9
• @wordpress/reusable-blocks: 3.15.9
• @wordpress/widgets: 2.15.9

Original PRs from Gutenberg repository:

• [WordPress/gutenberg#45189 Gutenberg PR 45189] - Fix resizeable editor scrolling
• [WordPress/gutenberg#45234 Gutenberg PR 45234] - Reset background-image property for outline button style
• [WordPress/gutenberg#45161 Gutenberg PR 45161] - Table Block: Add a deprecation for the figcaption element class name
• [WordPress/gutenberg#45159 Gutenberg PR 45159] - File Block: Add a deprecation for the button element class name
• [WordPress/gutenberg#45169 Gutenberg PR 45169] - Video: Add a deprecation for the caption element
• [WordPress/gutenberg#45166 Gutenberg PR 45166] - Embed: Add deprecation for the caption element
• [WordPress/gutenberg#45173 Gutenberg PR 45173] - Gallery: Add a deprecation for captions in the gallery block
• [WordPress/gutenberg#44854 Gutenberg PR 44854] - Embed Block: Add support for Tumblr Dashboard URLs
• [WordPress/gutenberg#45074 Gutenberg PR 45074] - Post editor: Rename view to Preview
• [WordPress/gutenberg#45163 Gutenberg PR 45163] - Featured Image Block: Add missing output escaping
• [WordPress/gutenberg#45118 Gutenberg PR 45118] - [WP6.1] Site editor clips body background style

Follow-up to [54257], [54335], [54383], [54483], [54486], [54490], and [54632].

Props czapla, cbravobernal, ndiego, annezazu, davidbaumwald, desrosj, mikeschroder, hellofromtonya, ocean90.
Reviewed by desrosj, hellofromTonya, SergeyBiryukov.
Merges [54693] to the 6.1 branch.
See #56467.

[hellofromTonya]

Resetting keywords as all approved work as been committed and backported.

@dream-encode merged to the 6.1 branch in r54694. Closing.

[hellofromTonya]

Closing this ticket. Why? All work is now committed and backported. 6.1 RC3 is happening in a few minutes and is the last scheduled RC before the final release next week.

If additional updates are needed between RC3 and Dry Run, this ticket can be reopened.

[flixos90]

@bernhard-reiter @oandregal @andraganescu @audrasjb Apologies for commenting on this already closed ticket, but I am reaching out here since I wanted to follow up on one of the (many) changes committed as part of this ticket. I'm happy to have the conversation in another place, just let me know.

My question concretely is in regards to a change in [54408], also see ​https://github.com/WordPress/gutenberg/pull/42005: Why was the condition from ​https://github.com/WordPress/gutenberg/pull/42005/files#diff-b1ef1993e7cfe79d570605ca1ac4abf130500170bc33ae7361a16833aec461bcL91 removed?

As far as I can tell, the logic within the condition used to only run for sites using FSE themes (or any theme that has a theme.json), however now this logic runs unconditionally. To be completely transparent, I am not very familiar with this part of the codebase, but I would think this logic is pointless to run for classic themes without a theme.json? I don't see any discussion on the PR about this change either, so I would like to understand why it was made and whether it is really needed.

The original reason why I am even looking at this is that I recently conducted a comprehensive performance analysis for WordPress 6.1 (planning to publish a summary soon, some time after 6.1 launch), and this particular change is causing a notable slowdown in the wp_head action for classic themes.

For future reference, this PR bundles two different things that are unrelated to each other. The SVN commit and issue description does not reflect that well.

• ​https://github.com/WordPress/gutenberg/pull/42005 the original Gutenberg PR this initially tried to backport.
• ​https://github.com/WordPress/gutenberg/pull/44363 was bundled into this one later.

[oandregal]

Felix, ​https://github.com/WordPress/wordpress-develop/pull/3319 bundles a couple of things, and it's not clear by the commit message what it does. I can't speak about the code you mention, but in case it helps, the original PR is at ​https://github.com/WordPress/gutenberg/pull/42005

[scruffian]

I would think this logic is pointless to run for classic themes without a theme.json

One of the changes introduced in 6.1 is that some blocks now load their styles using the experimentalStyles property in their block.json, as well as from their CSS file. Given that blocks and their styles are loaded for both classic and block themes, it is necessary for us to output these rules into CSS in both types of themes. Hope that makes sense!

Closing in favor of ​https://github.com/WordPress/wordpress-develop/pull/3527 😊

[flixos90]

Replying to scruffian:

I would think this logic is pointless to run for classic themes without a theme.json

One of the changes introduced in 6.1 is that some blocks now load their styles using the experimentalStyles property in their block.json, as well as from their CSS file. Given that blocks and their styles are loaded for both classic and block themes, it is necessary for us to output these rules into CSS in both types of themes. Hope that makes sense!

Thanks for clarifying, that makes sense. However, if for classic themes this is only needed to add those block styles, why are we running all the other logic that is invoked by wp_add_global_styles_for_blocks()? I took a bit of time to dive into the WP_Theme_JSON_Resolver code, and it does a whole lot of things that appear to only relate to FSE themes without any checks for theme_has_support().

For example:

• wp_add_global_styles_for_blocks() calls WP_Theme_JSON_Resolver::get_merged_data().
• From there, it calls get_core_data(), get_block_data(), get_theme_data(), and get_user_data(). Based on what you're saying, for a classic theme it would make more sense to only call get_block_data(), not the other 3.
• By doing that, we would avoid several expensive actions which seem unnecessary for classic themes:
  • Read, parse, and translate, WP core's own theme.json
  • Load the translation schema even though the theme has no theme.json
  • Run a database query to get global styles

Of the above points, the only thing that changes anything in the relevant data is not parsing core's theme.json. However, the data in that is not really used for classic themes anyways, so that should also be fine.

I've done a first test, and it appears that removing these calls does not result in any missing functionality for classic themes. You can see this issue first-hand in action with Twenty Twenty-One:

1. Set up a site with Twenty Twenty-One.
2. Modify WP_Theme_JSON_Resolver::get_core_data() to just set $config to an empty array instead of parsing core's theme.json.
3. Modify WP_Theme_JSON::set_spacing_sizes() to include an ! isset( $spacing_scale['steps'] ) check, since that key may not be present now, to avoid a PHP warning.
4. Inspect the frontend of the site before and after the change. There is no change in any of the CSS included, except that a single CSS rule :where(.wp-block-columns.is-layout-flex){gap: 2em;} is now gone. To be fair, I'm a bit unclear why that was there in the first place, since the is-layout-flex class is not used anywhere on the page.

I've opened ​https://github.com/WordPress/wordpress-develop/pull/3536 for consideration.

• A performance analysis for WordPress 6.1 has shown that there is a performance regression in wp_head due to additional logic focused on FSE, which particularly for classic themes appears to be unnecessary.
• See relevant Trac ticket comments discussing this so far:
  • https://core.trac.wordpress.org/ticket/56467#comment:408
  • https://core.trac.wordpress.org/ticket/56467#comment:411
  • https://core.trac.wordpress.org/ticket/56467#comment:413
• This PR improves median wp_head execution time from 16.45ms to 11.92ms (~28% faster) for classic themes, while apparently not missing any actual functionality needed. See ​this spreadsheet for the test results.
• At this point this PR is for initial consideration, there is no Trac ticket yet as the conversation is currently happening on the (massive) Trac ticket as part of which the change causing the regression was introduced. The original Gutenberg PR is ​https://github.com/WordPress/gutenberg/pull/42005.

cc @scruffian @oandregal @draganescu

Trac ticket:

cc @oandregal

:wave: I've seen the changes and this is what I can share:

• get_core_data: this data needs to be available both for classic and block themes. It loads the default editor configuration (for example, the default color palettes)
• get_block_data: this data is necessary for both classic and block themes. It loads style information from blocks.
• get_theme_data: this data is required for both classic and block themes. For classic, it takes it from the theme supports and returns it as if it was a theme.json. There may be some opportunities to micro-optimize here, such as do not load the i18n schema if the theme and its parent do not have a theme.json (we'd need to measure how impactful that single change is, that´d be a nice single PR).
• get_user_data: this is safe to skip for classic themes. There are edge cases, such as a theme that has theme.json and then it removes it, though I'm inclined to think user styles are safe to ignore in that case. Coincidentally, I've done the same thing in a ​prototype I'm working on. It can be extracted as a small, focused PR.

Coincidentally, for the area of "theme.json APIs", I'm compiling a list of tasks I find most pressing at ​https://github.com/WordPress/gutenberg/issues/45171 I'm very optimistic about how those will impact the performance and code quality. For example, I've just published a ​prototype that reduces the total time of a request from 514.44ms to 343.71ms, a 33% performance increase.

Another thing that it'd be useful is to work in these PRs in Gutenberg directly. That way, they can be tested widely and bugs will be raised earlier than the WordPress RC cycles, which is always a lot less stressful and give time to developers to figure out long-term solutions rather than patches for the RC.

This PR improves median wp_head execution time from 16.45ms to 11.92ms (~28% faster) for classic themes (concretely tested with Twenty Twenty-One

Felix, would you share the steps you did to test this, so it can be replicated in a variety of environments?

As a side note, it'd be great to track some statistics across WordPress versions and watch its evolution, like we do for the editor (see live at ​https://codehealth.vercel.app/).

@oandregal Thank you for providing additional context on why (parts of) these methods are needed for classic themes as well. Based on what you're saying, I still think there are a number of performance optimizations to make here to avoid running FSE-only logic for classic themes. Here are some of the high-level ideas I'm thinking:

• In get_core_data(), parsing WP's own theme.json is a rather wasteful implementation in itself, more so with the additional translation parsing. Since this file is shipped by core (and thus never changes between core updates), we should find a more efficient solution. For example, how about we generate a fully PHP-ready parsed version including i18n strings of WP's theme.json at build time? I see how theme.json is certainly more portable than the same data in PHP array format, but we could create an autogenerated version of that file, like a theme-json.php file that can then simply be required by PHP, no JSON parsing and i18n schema parsing necessary at runtime.
• In get_block_data(), everything looks fine as is to me.
• In get_theme_data(), we should simply not parse the i18n schema and try to parse the theme's theme.json if it doesn't exist, like you're saying and like this PR already does.
• get_user_data() can bail early if in a classic theme, also like you're saying and like this PR already does.

I'll make some updates to the proposed code here accordingly, the main thing though that requires some more work would be to generate some version of a theme-json.php file as part of the build process. If we build something like that, we could even share it with e.g. theme developers so they can run it on their theme.json files too.

Felix, would you share the steps you did to test this, so it can be replicated in a variety of environments?

It was a fairly basic process, here's what I did:

• Modify WP core's wp_head() function directly, to measure microtime( true ) before the do_action( 'wp_head' ) call and after it, then get the difference to know how long the action took.
• I did this with trunk and with this PR branch, using a site with Twenty Twenty-One on just the regular basic "Hello world" singular post URL.
• I ran both tests 9 times each (to account for variance) and calculated the median.

If we wanted to dive in more deeply, it would also be interesting to see what the difference would be on a more complex piece of content, e.g. the Gutenberg demo page.

@oandregal I've pushed some updates here as mentioned above, please have a look. I have included what the theme-json.php file could look like in principle, although of course this would need to be auto-generated by a build process eventually.

One additional concern/question I have: Why is the condition around whether to reuse the previously "cached" theme data only present around parsing the (child) theme's theme.json (see ​https://github.com/WordPress/wordpress-develop/pull/3536/files#diff-d6b86476eed058e7cf8b6e57fa52c4fd75b1f0907e1a9ccb0149528a24f7578bR254)? Are there any problems if we change it to apply to the entire method, similar to how it is for the other get_*_data() methods? Otherwise some of that logic is still run on every single method call over and over again. cc @hellofromtonya

This PR is heavily related - ​https://github.com/WordPress/wordpress-develop/pull/3556.

This is hard to code review the code to generate theme-php.php, fix the unit test and coding standards.

@spacedmonkey

This is hard to code review the code to generate theme-php.php, fix the unit test and coding standards.

No point to review the theme-json.php file, as eventually it will be auto-generated. There's also no point in fixing the WPCS etc violations in that file - see the TODO comment and the issue comments above outlining that. :)

I'll work on further polishing here today.

@draganescu @hellofromtonya Any chance I could get your thoughts on the changes and proposed approach from this draft PR? Please make sure to review my above issue comments for context.

No point to review the theme-json.php file, as eventually it will be auto-generated. There's also no point in fixing the WPCS etc violations in that file - see the TODO comment and the issue comments above outlining that. :)

I don't think we should merge this without the automatic generation code, in JS grunt.

I think we should consider making this out to another PR, where we have more time to review / test.

@spacedmonkey

I don't think we should merge this without the automatic generation code, in JS grunt.

That's exactly what I'm saying.

I think we should consider making this out to another PR, where we have more time to review / test.

Sounds good, I've opened ​https://github.com/WordPress/gutenberg/issues/45616 for that.

Will remove the theme-json.php part from here and get this PR ready for 6.1.1.

@spacedmonkey @draganescu @hellofromtonya This PR is now ready for a full review, including test coverage. Would be great to get your feedback so that we can aim to get this into 6.1.1.

:wave: I've run some local profiling tests using TwentyTwentyOne. My test was loading the "hello world" post as a logged-out user. These are the numbers (median of 9 tries): it takes 393.98ms with this request and 411.04ms without these changes. This improves 17.06ms, a 4.15% improvement for that theme.

This improves 17.06ms, a 4.15% improvement for that theme.

For reference, block themes also improve in 12.47ms.

This PR does three changes:

​1. remove is_readable for theme.json check (both themes with and without theme.json)
​2. avoid looking up the parent if the theme data is already set (both themes with and withouth theme.json)
​3. remove one query for themes without theme.json
​4. do not load the translation for themes with no theme.json

I've done my testing with TwentyTwentyOne and TwentyTwentyThree (none is a child theme). Given the changes and the numbers are so close (-12ms vs -17ms for themes with and without theme.json), it sounds like the most impactful change was actually 1 (the only code that both themes have in common in my testing). Removing the query for classic themes is a 5ms improvement at best. I'm time-bounded at the moment and could not dig deeper. My impression is that the results are not lined up with the initial expectations (we are doing _more_ work for classic themes). Would that be a fair statement?

As I said, I won't have much time to look into this in the following days, though it looks like a safe change. Hope this is helpful.

I also want to share the two things that I consider more impactful at the moment to focus on:

1) Review and ​cache the public API methods. An initial investigation I did resulted in ​this PR, which provides a 200ms reduction, a 33% improvement. Every ms counts, so squeezing all of them at the maximum is always helpful. Though there are so many things to work on that I think it'd be helpful to look at performance strategically: intervene for the bigger wins first, then look at the smaller bits. I'll continue to look into this more when I'm back at full speed.

2) Having an automated and way to look at numbers and define what's important for us. At the moment, everyone is tracking things manually, and it takes a lot of time from the PR author and from the reviewers. It's also a bit inconsistent: should we measure the full time-to-request as logged-out users or is it best tracking particular actions such as wp_head? Having a common understanding of what to improve and tracking automatically instead of manually is a huge win that would help us to move forward faster. Unfortunately, I don't think I'll be able to help in this area much. It'd be lovely if people with more experience and background in setting these things up would take the lead.

In trunk

In this branch.

In trunk

In this branch.

@oandregal Thank you for running additional performance benchmarks on the latest code here! This is super helpful.

I've also run the latest iteration of the PR through the same methodology that I originally used, and posted results in an updated PR description. Of course the benefit is much less than originally, now that I've broken out fixing the core theme.json parsing piece into ​https://github.com/WordPress/gutenberg/issues/45616. Nevertheless, at a ~10% wp_head performance improvement I think this is a worthwhile change especially as they look straightforward from a code perspective - baby steps so to speak, but together they'll add up eventually, and doing the work here is particularly relevant to allow for the above Gutenberg issue to actually have the intended impact.

I don't think there is a need for this PR. See ​https://github.com/WordPress/gutenberg/issues/45240#issuecomment-1304757932.

I'm going to remove it from WP 6.1.1 board.

@SergeyBiryukov, do you know if r54647 was reverted from 6.1 branch?

Good, the commit hasn't been reverted. We'll ship the client-side code in 6.1.1.

Good, the commit hasn't been reverted. We'll ship the client-side code in 6.1.1.

Yeah, I remember a ​Slack discussion about this with the consensus to revert, but it looks like the code is still in the branch, so I guess the revert was missed somehow 😅

That saves us work for the minor release 😄

Thanks folks. There are (potentially) incoming changes for 6.1.1 stemming from ​https://github.com/WordPress/gutenberg/pull/45536... I'll create a core patch and see how far we get 😄

Thank you, @ramonjd. I've already cherry-picked ​https://github.com/WordPress/gutenberg/pull/44993 for 6.1.1.

PHP backport for ​https://github.com/WordPress/gutenberg/pull/45536 here:

​https://github.com/WordPress/wordpress-develop/pull/3602

This updates the logic and tests since the changes in ​https://github.com/WordPress/gutenberg/pull/44993

Committed in https://core.trac.wordpress.org/changeset/54799.

@hellofromtonya @azaozz @ironprogrammer Here's another PR that didn't make the cut for WP 6.1 -- for y'all's consideration for (early) inclusion in 6.2 😊

The earlier, the more time there is to test using the theme support in the bundled themes.

@ockham In ​https://github.com/WordPress/wordpress-develop/pull/3846 I've added a unit test for this support, and opened an early backport ticket in Trac 57460. ("Early" as in before 6.2 crunch time 😅)

Perfect, thank you very much @ironprogrammer! Closing this in favor of ​https://github.com/WordPress/wordpress-develop/pull/3846 (which I see has already been merged :tada:)

I'm proposing we revert this change at ​https://github.com/WordPress/wordpress-develop/pull/4145 as it introduced a bug.

[audrasjb]

In 55448:

Editor: Ensure Global styles values are reset in the site editor.

This changeset fixes a bug by which the reset function of the global styles sidebar would not work as expected in the site editor. It reverts [54517] and adds related unit tests.

Props oandregal, ntsekouras, youknowriad, hellofromTonya.
Fixes #57824
See #56467