Make WordPress Core

Opened 15 months ago

Closed 14 months ago

Last modified 9 months ago

#56467 closed task (blessed) (fixed)

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

Reported by: bernhard-reiter's profile Bernhard Reiter Owned by: bernhard-reiter's profile Bernhard Reiter
Milestone: 6.1 Priority: normal
Severity: normal Version:
Component: Editor Keywords: has-patch has-unit-tests fixed-major
Focuses: Cc:

Description (last modified by davidbaumwald)

* Update @wordpress packages with packages published from Gutenberg.

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

Change History (446)

This ticket was mentioned in PR #3154 on WordPress/wordpress-develop by ockham.


15 months ago
#1

  • Keywords has-patch has-unit-tests added

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

gziolo commented on PR #3154:


15 months ago
#2

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.

ockham commented on PR #3154:


15 months ago
#3

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

ockham commented on PR #3154:


15 months ago
#4

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

gziolo commented on PR #3154:


15 months ago
#5

(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 👍🏻

ockham commented on PR #3154:


15 months ago
#6

(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!

ockham commented on PR #3154:


15 months ago
#7

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 😕

Mamaduka commented on PR #3156:


15 months ago
#9

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.

This ticket was mentioned in PR #3157 on WordPress/wordpress-develop by Mamaduka.


15 months ago
#10

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

ockham commented on PR #3157:


15 months ago
#11

Thank you very much, @Mamaduka! 🙌

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

https://i0.wp.com/user-images.githubusercontent.com/96308/187624770-3d2c738c-7181-45bc-88e3-d715bebd5479.png

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

Mamaduka commented on PR #3157:


15 months ago
#12

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.

This ticket was mentioned in PR #3158 on WordPress/wordpress-develop by ockham.


15 months ago
#13

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:

cc/ @glendaviesnz @ramonjd for review 😊

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

TimothyBJacobs commented on PR #3157:


15 months ago
#14

May make sense to move this logic into add_site_icon_to_index.

ockham commented on PR #3158:


15 months ago
#15

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

ockham commented on PR #3158:


15 months ago
#16

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.

#17 @SergeyBiryukov
15 months ago

  • Milestone changed from Awaiting Review to 6.1

#18 @desrosj
15 months ago

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.

Mamaduka commented on PR #3157:


15 months ago
#20

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

michalczaplinski commented on PR #3154:


15 months ago
#21

I ran into another problem:

https://i0.wp.com/user-images.githubusercontent.com/5417266/188518357-2440d830-b53f-49b3-b9d7-8b6d529db423.png

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.

#22 @noisysocks
15 months ago

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.

gziolo commented on PR #3154:


15 months ago
#23

I ran into another problem:

https://i0.wp.com/user-images.githubusercontent.com/5417266/188518357-2440d830-b53f-49b3-b9d7-8b6d529db423.png

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.

#24 @SergeyBiryukov
15 months ago

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:

Follow-up to [52080].

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

SergeyBiryukov commented on PR #3157:


15 months ago
#25

Thanks for the PR! Merged in r54083.

#26 @SergeyBiryukov
15 months ago

In 54084:

Block Editor: Preload settings and templates permissions.

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

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

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

SergeyBiryukov commented on PR #3156:


15 months ago
#27

Thanks for the PR! Merged in r54084.

This ticket was mentioned in PR #3204 on WordPress/wordpress-develop by ramonjd.


15 months ago
#29

❗ 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

This ticket was mentioned in PR #3215 on WordPress/wordpress-develop by c4rl0sbr4v0.


15 months ago
#31

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

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

#32 @SergeyBiryukov
15 months ago

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:

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

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

SergeyBiryukov commented on PR #3210:


15 months ago
#33

Thanks for the PR! Merged in r54101.

#34 @SergeyBiryukov
15 months ago

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:

Follow-up to [50973].

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

SergeyBiryukov commented on PR #3215:


15 months ago
#35

Thanks for the PR! Merged in r54105.

This ticket was mentioned in PR #3199 on WordPress/wordpress-develop by ramonjd.


15 months ago
#36

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

This ticket was mentioned in PR #3218 on WordPress/wordpress-develop by ramonjd.


15 months ago
#37

❗ 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

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

This ticket was mentioned in PR #3219 on WordPress/wordpress-develop by talldan.


15 months ago
#38

## 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

ramonjd commented on PR #3199:


15 months ago
#39

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

Thanks for the reviews, folks.

ramonjd commented on PR #3199:


15 months ago
#41

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 😱

ramonjd commented on PR #3199:


15 months ago
#43

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 👍

MaggieCabrera commented on PR #3206:


15 months ago
#45

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

SergeyBiryukov commented on PR #3206:


15 months ago
#46

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.

#47 @SergeyBiryukov
15 months ago

In 54118:

Editor: Backport Elements API updates.

This commit backports the original PRs from Gutenberg repository:

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

SergeyBiryukov commented on PR #3206:


15 months ago
#48

Thanks for the PR! Merged in r54118.

ockham commented on PR #3206:


15 months ago
#49

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 ticket was mentioned in PR #3205 on WordPress/wordpress-develop by andrewserong.


15 months ago
#50

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

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

aaronrobertshaw commented on PR #3205:


15 months ago
#51

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.

ockham commented on PR #3206:


15 months ago
#52

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

ockham commented on PR #3206:


15 months ago
#53

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

talldan commented on PR #3219:


15 months ago
#55

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?

andrewserong commented on PR #3205:


15 months ago
#56

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.

costdev commented on PR #3219:


15 months ago
#57

@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'
    );
}

This ticket was mentioned in PR #3234 on WordPress/wordpress-develop by Mamaduka.


15 months ago
#58

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.

ockham commented on PR #3199:


15 months ago
#59

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

costdev commented on PR #3199:


15 months ago
#60

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.

This ticket was mentioned in PR #3237 on WordPress/wordpress-develop by ironprogrammer.


15 months ago
#61

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

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

Props @ramonjd.

ramonjd commented on PR #3199:


15 months ago
#62

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.

andrewserong commented on PR #3199:


15 months ago
#63

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.

andrewserong commented on PR #3205:


15 months ago
#64

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

aristath commented on PR #3199:


15 months ago
#65

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 👍

ockham commented on PR #3154:


15 months ago
#66

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.

gziolo commented on PR #3154:


15 months ago
#67

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?

gziolo commented on PR #3154:


15 months ago
#68

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.

gziolo commented on PR #3154:


15 months ago
#69

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.

This ticket was mentioned in PR #3244 on WordPress/wordpress-develop by ockham.


15 months ago
#70

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

#71 @audrasjb
15 months ago

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.

hellofromtonya commented on PR #3234:


15 months ago
#73

@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 commented on PR #3234:


15 months ago
#74

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

ockham commented on PR #3154:


15 months ago
#75

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

#76 @audrasjb
15 months ago

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.

This ticket was mentioned in PR #3247 on WordPress/wordpress-develop by oandregal.


15 months ago
#77

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.

#78 @hellofromTonya
15 months ago

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.

hellofromtonya commented on PR #3205:


15 months ago
#79

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.

ockham commented on PR #3205:


15 months ago
#80

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.

ockham commented on PR #3205:


15 months ago
#81

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:

hellofromtonya commented on PR #3234:


15 months ago
#82

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)

https://i0.wp.com/user-images.githubusercontent.com/7284611/190215448-ceacb484-1898-4f84-85a0-6b522d4e5b28.png

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.

https://i0.wp.com/user-images.githubusercontent.com/7284611/190215705-1b2bd9e4-e90e-4d1a-a636-48ea4c20f3b5.png

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

ockham commented on PR #3237:


15 months ago
#83

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

hellofromtonya commented on PR #3205:


15 months ago
#84

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.

ockham commented on PR #3244:


15 months ago
#85

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

#86 @hellofromTonya
15 months ago

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.

This ticket was mentioned in PR #3253 on WordPress/wordpress-develop by ironprogrammer.


15 months ago
#88

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

ironprogrammer commented on PR #3219:


15 months ago
#89

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

ironprogrammer commented on PR #3237:


15 months ago
#90

@ockham Done!

CC @ramonjd.

ironprogrammer commented on PR #3237:


15 months ago
#91

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.

michalczaplinski commented on PR #3247:


15 months ago
#92

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

This ticket was mentioned in PR #3254 on WordPress/wordpress-develop by andrewserong.


15 months ago
#94

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

https://i0.wp.com/user-images.githubusercontent.com/14988353/190320279-786e94d4-7ffc-4d56-96c7-48e41644c6ba.png

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

andrewserong commented on PR #3254:


15 months ago
#95

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

talldan commented on PR #3253:


15 months ago
#96

Props noisysocks costdev talldan

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

andrewserong commented on PR #3237:


15 months ago
#97

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)

andrewserong commented on PR #3154:


15 months ago
#98

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 🙂

oandregal commented on PR #3247:


15 months ago
#99

perhaps @jorgefilipecosta or @gziolo can help?

ockham commented on PR #3234:


15 months ago
#100

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

This ticket was mentioned in PR #3258 on WordPress/wordpress-develop by ockham.


15 months ago
#101

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

ockham commented on PR #3234:


15 months ago
#102

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

ockham commented on PR #3258:


15 months ago
#103

@fabiankaegy Would you mind approving this PR? 😊

fabiankaegy commented on PR #3258:


15 months ago
#104

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

#105 @audrasjb
15 months ago

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.

audrasjb commented on PR #3244:


15 months ago
#106

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

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

audrasjb commented on PR #3244:


15 months ago
#107

Oops, I closed it accidentally :D

hellofromtonya commented on PR #3258:


15 months ago
#108

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 ✅

https://i0.wp.com/user-images.githubusercontent.com/7284611/190216065-ad9da9fc-f7eb-41da-8d8f-1d24f72887c2.png

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)

https://i0.wp.com/user-images.githubusercontent.com/7284611/190215448-ceacb484-1898-4f84-85a0-6b522d4e5b28.png

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.

#109 @audrasjb
15 months ago

In 54175:

Editor: Backport build_query_vars_from_query_block changes from Gutenberg repository.

This changeset backports changes from the following Gutenberg pull requests:

Props ntsekouras, bernhard-reiter.
See #56467.

ockham commented on PR #3244:


15 months ago
#111

Oops, I closed it accidentally :D

No worries @audrasjb 😄 Thank you for committing!

ockham commented on PR #3218:


15 months ago
#112

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

This ticket was mentioned in PR #3259 on WordPress/wordpress-develop by ockham.


15 months ago
#113

🎼 _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

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

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

#114 @hellofromTonya
15 months ago

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.

hellofromtonya commented on PR #3258:


15 months ago
#115

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

hellofromtonya commented on PR #3234:


15 months ago
#116

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

ockham commented on PR #3218:


15 months ago
#117

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

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

ockham commented on PR #3259:


15 months ago
#118

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
+    '

This ticket was mentioned in PR #3261 on WordPress/wordpress-develop by oandregal.


15 months ago
#119

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

ockham commented on PR #3204:


15 months ago
#122

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

hellofromtonya commented on PR #3221:


15 months ago
#124

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

hellofromtonya commented on PR #3219:


15 months ago
#125

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

hellofromtonya commented on PR #3253:


15 months ago
#126

# 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 ✅

https://i0.wp.com/user-images.githubusercontent.com/7284611/190455421-8b43a58b-5a10-41e5-b0d2-6a861782e79d.gif

### 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 ✅

https://i0.wp.com/user-images.githubusercontent.com/7284611/190455548-4eeaea83-502f-429d-9716-695f83085bf2.gif

### Test 3: Should not change other UIs

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

https://i0.wp.com/user-images.githubusercontent.com/7284611/190455835-4fe1fd5c-238e-4286-9a32-8fb1a0c8a5df.gif

#127 @hellofromTonya
15 months ago

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.

hellofromtonya commented on PR #3253:


15 months ago
#128

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

hellofromtonya commented on PR #3219:


15 months ago
#129

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

ockham commented on PR #3203:


15 months ago
#131

Superseded by #3237.

#132 @SergeyBiryukov
15 months ago

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:

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

Follow-up to [54118].

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

SergeyBiryukov commented on PR #3261:


15 months ago
#133

Thanks for the PR! Merged in r54183.

SergeyBiryukov commented on PR #3261:


15 months ago
#134

Thanks for the PR! Merged in r54183.

This ticket was mentioned in PR #3262 on WordPress/wordpress-develop by andrewserong.


15 months ago
#135

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

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

andrewserong commented on PR #3259:


15 months ago
#136

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.

andrewserong commented on PR #3254:


15 months ago
#137

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

tellthemachines commented on PR #3154:


15 months ago
#138

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 😅

oandregal commented on PR #3247:


15 months ago
#139

@gziolo addressed your feedback.

#140 @desrosj
15 months ago

  • Type changed from enhancement to task (blessed)

ramonjd commented on PR #3237:


15 months ago
#141

Thank for you for advancing this one!! 🙇

ramonjd commented on PR #3204:


15 months ago
#142

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

ramonjd commented on PR #3259:


15 months ago
#143

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?

andrewserong commented on PR #3259:


15 months ago
#144

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

ramonjd commented on PR #3259:


15 months ago
#145

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

glendaviesnz commented on PR #3255:


15 months ago
#146

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

costdev commented on PR #3255:


15 months ago
#147

Thanks for the update @glendaviesnz!

ramonjd commented on PR #3204:


15 months ago
#148

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

@ockham Good to go I think.

ramonjd commented on PR #3259:


15 months ago
#149

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 ticket was mentioned in PR #3274 on WordPress/wordpress-develop by andrewserong.


15 months ago
#150

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

This ticket was mentioned in PR #3273 on WordPress/wordpress-develop by ramonjd.


15 months ago
#151

🎼 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

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

ramonjd commented on PR #3259:


15 months ago
#152

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

ockham commented on PR #3259:


15 months ago
#153

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

scruffian commented on PR #3274:


15 months ago
#154

Should we also add it to remove_insecure_properties?

hellofromtonya commented on PR #3237:


15 months ago
#155

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

#156 @hellofromTonya
15 months ago

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.

ockham commented on PR #3154:


15 months ago
#157

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.

#158 @desrosj
15 months ago

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.

#159 follow-up: @audrasjb
15 months ago

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.

ciampo commented on PR #3154:


15 months ago
#161

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" },

}}}

#162 @audrasjb
15 months ago

In 54214:

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

This changeset backports the following changes:

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

ramonjd commented on PR #3204:


15 months ago
#164

Thanks for all the help, folks!

michalczaplinski commented on PR #3154:


15 months ago
#165

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

glendaviesnz commented on PR #3255:


15 months ago
#166

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.

andrewserong commented on PR #3254:


15 months ago
#167

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

andrewserong commented on PR #3274:


15 months ago
#169

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 👍

andrewserong commented on PR #3254:


15 months ago
#170

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

#171 @desrosj
15 months ago

In 54238:

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

Follow up to [54214].

See #56467.

glendaviesnz commented on PR #3255:


15 months ago
#172

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

ciampo commented on PR #3154:


15 months ago
#173

@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

c4rl0sbr4v0 commented on PR #3154:


15 months ago
#174

Packages have been updated. Nice done!! 🎉 🚀

ockham commented on PR #3154:


15 months ago
#175

Amazing! I'll re-sync now.

ockham commented on PR #3154:


15 months ago
#176

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

ockham commented on PR #3221:


15 months ago
#177

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

#178 @audrasjb
15 months ago

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:

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

desrosj commented on PR #3274:


15 months ago
#180

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.

ockham commented on PR #3154:


15 months ago
#181

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.

#182 @desrosj
15 months ago

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.

ockham commented on PR #3154:


15 months ago
#183

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

gziolo commented on PR #3154:


15 months ago
#184

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.

ockham commented on PR #3154:


15 months ago
#185

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

https://i0.wp.com/user-images.githubusercontent.com/96308/191280453-5ecb0379-438e-416a-9e7e-9084cec33552.png

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

ockham commented on PR #3154:


15 months ago
#186

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

hellofromtonya commented on PR #3237:


15 months ago
#187

Prepping commit now.

ockham commented on PR #3154:


15 months ago
#188

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.

ockham commented on PR #3154:


15 months ago
#189

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

ockham commented on PR #3154:


15 months ago
#190

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.

gziolo commented on PR #3154:


15 months ago
#191

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.

#193 follow-up: @gziolo
15 months ago

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.

gziolo commented on PR #3154:


15 months ago
#194

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

desrosj commented on PR #3274:


15 months ago
#195

Created Core-56611 for expanding unit tests.

#196 @hellofromTonya
15 months ago

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:

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

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

hellofromtonya commented on PR #3237:


15 months ago
#197

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

hellofromtonya commented on PR #3221:


15 months ago
#198

Currently reviewing. When ready, will prep the commit.

#199 @gziolo
15 months ago

In 54261:

Chore: Run browserslits update

Follow-up [54257].
See #56467.

#200 @jorgefilipecosta
15 months ago

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.

hellofromtonya commented on PR #3221:


15 months ago
#201

Rebased the branch on top of the latest trunk.

#202 @kebbet
15 months ago

[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.' )

hellofromtonya commented on PR #3221:


15 months ago
#203

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

#204 @hellofromTonya
15 months ago

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.

hellofromtonya commented on PR #3221:


15 months ago
#205

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

hellofromtonya commented on PR #3254:


15 months ago
#206

I'm self-assigning for review and commit.

ramonjd commented on PR #3154:


15 months ago
#207

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

costdev commented on PR #3254:


15 months ago
#208

## 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
https://i0.wp.com/user-images.githubusercontent.com/79332690/191379850-27f9519f-e809-443a-b061-3d923fb77415.jpg

hellofromtonya commented on PR #3254:


15 months ago
#209

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

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

#210 @audrasjb
15 months ago

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.

#212 @jorgefilipecosta
15 months ago

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.

#213 @hellofromTonya
15 months ago

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.

hellofromtonya commented on PR #3254:


15 months ago
#214

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

hellofromtonya commented on PR #3254:


15 months ago
#215

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

This ticket was mentioned in PR #3305 on WordPress/wordpress-develop by jorgefilipecosta.


15 months ago
#216

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.

#217 @jorgefilipecosta
15 months ago

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.

jsnajdr commented on PR #3154:


15 months ago
#219

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!

michalczaplinski commented on PR #3313:


15 months ago
#221

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

oandregal commented on PR #3313:


15 months ago
#222

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?

scruffian commented on PR #3313:


15 months ago
#223

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

This ticket was mentioned in PR #3322 on WordPress/wordpress-develop by jorgefilipecosta.


15 months ago
#224

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:
https://i0.wp.com/user-images.githubusercontent.com/11271197/192069376-1f0a101a-d64c-4e7a-8853-c7ec2c36fbc8.png

#226 @jorgefilipecosta
14 months ago

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.

ockham commented on PR #3322:


14 months ago
#228

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 🙂

ockham commented on PR #3322:


14 months ago
#229

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.

hellofromtonya commented on PR #3324:


14 months ago
#230

Self-assigning for commit review and prep.

hellofromtonya commented on PR #3324:


14 months ago
#231

Self-assigning for commit review and prep.

hellofromtonya commented on PR #3324:


14 months ago
#232

# 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
https://i0.wp.com/user-images.githubusercontent.com/7284611/192278773-65abf3e3-a4aa-44cc-8abd-2c165955af96.png

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

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

}
}}}
https://i0.wp.com/user-images.githubusercontent.com/7284611/192281362-f8afcd4d-9066-4971-b30e-bb70344dc703.png

#### After applying the patch

https://i0.wp.com/user-images.githubusercontent.com/7284611/192280152-220c32c1-01c6-4a42-83b4-4b7833a74ca0.png

https://i0.wp.com/user-images.githubusercontent.com/7284611/192280903-b14e75c1-7ade-4a37-878a-d251f535ac87.png

{{{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
https://i0.wp.com/user-images.githubusercontent.com/7284611/192282351-54eb339e-2f21-4838-aeea-0f61e92d13cd.png
https://i0.wp.com/user-images.githubusercontent.com/7284611/192282379-c344400a-8218-4407-b3fc-afb6b6d72f0f.png

{{{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

https://i0.wp.com/user-images.githubusercontent.com/7284611/192282741-a7a2ce09-8181-4226-b9f9-4cd5adf8e98e.png
https://i0.wp.com/user-images.githubusercontent.com/7284611/192282767-e5555f39-0e41-4712-9361-b1ee8a732722.png

{{{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;

}
}}}

hellofromtonya commented on PR #3324:


14 months ago
#233

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 ⚪

#234 @hellofromTonya
14 months ago

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.

hellofromtonya commented on PR #3324:


14 months ago
#235

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

hellofromtonya commented on PR #3313:


14 months ago
#236

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

This ticket was mentioned in PR #3319 on WordPress/wordpress-develop by scruffian.


14 months ago
#237

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.

hellofromtonya commented on PR #3319:


14 months ago
#238

# 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. */

/

/

  • 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. */

/

/

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

hellofromtonya commented on PR #3319:


14 months ago
#239

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

hellofromtonya commented on PR #3319:


14 months ago
#240

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

#241 in reply to: ↑ 193 ; follow-up: @jrf
14 months ago

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

#242 in reply to: ↑ 159 @jrf
14 months ago

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

Last edited 14 months ago by jrf (previous) (diff)

#243 in reply to: ↑ 241 @SergeyBiryukov
14 months ago

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.

This ticket was mentioned in PR #3337 on WordPress/wordpress-develop by ockham.


14 months ago
#244

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

hellofromtonya commented on PR #3337:


14 months ago
#245

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.

This ticket was mentioned in PR #3342 on WordPress/wordpress-develop by ockham.


14 months ago
#246

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

ockham commented on PR #3342:


14 months ago
#247

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

#248 @SergeyBiryukov
14 months ago

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.

ockham commented on PR #3342:


14 months ago
#249

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.

#250 @davidbaumwald
14 months ago

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.

#251 @davidbaumwald
14 months ago

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.

This ticket was mentioned in PR #3345 on WordPress/wordpress-develop by ockham.


14 months ago
#252

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

#254 @hellofromTonya
14 months ago

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:

Props bernhard-reiter, cbravobernal.
See #56467.

dream-encode commented on PR #3337:


14 months ago
#256

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.

oandregal commented on PR #3319:


14 months ago
#257

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

ockham commented on PR #3337:


14 months ago
#258

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

priethor commented on PR #3337:


14 months ago
#259

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.

priethor commented on PR #3337:


14 months ago
#260

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.

This ticket was mentioned in PR #3363 on WordPress/wordpress-develop by ramonjd.


14 months ago
#262

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

#263 @ramonopoly
14 months ago

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

#264 @davidbaumwald
14 months ago

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.

ockham commented on PR #3319:


14 months ago
#266

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

#267 @davidbaumwald
14 months ago

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.

#269 @davidbaumwald
14 months ago

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.

#270 @kebbet
14 months ago

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

Solved with [54359]

Last edited 14 months ago by kebbet (previous) (diff)

ramonjd commented on PR #3363:


14 months ago
#271

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

#272 @davidbaumwald
14 months ago

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.

This ticket was mentioned in PR #3402 on WordPress/wordpress-develop by ockham.


14 months ago
#273

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

#274 @davidbaumwald
14 months ago

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:

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

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

#277 @davidbaumwald
14 months ago

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.

This ticket was mentioned in PR #3405 on WordPress/wordpress-develop by ockham.


14 months ago
#278

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

ockham commented on PR #3405:


14 months ago
#279

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


#280 @davidbaumwald
14 months ago

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.

ockham commented on PR #3319:


14 months ago
#282

Rebased.

ockham commented on PR #3319:


14 months ago
#283

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

michalczaplinski commented on PR #3319:


14 months ago
#284

Investigating this now 👀

michalczaplinski commented on PR #3319:


14 months ago
#285

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.

#286 @SergeyBiryukov
14 months ago

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.

This ticket was mentioned in PR #3411 on WordPress/wordpress-develop by oandregal.


14 months ago
#287

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.

oandregal commented on PR #3411:


14 months ago
#288

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?

#289 @oandregal
14 months ago

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

dream-encode commented on PR #3411:


14 months ago
#290

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

oandregal commented on PR #3411:


14 months ago
#291

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

oandregal commented on PR #3319:


14 months ago
#292

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

#293 @audrasjb
14 months ago

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.

audrasjb commented on PR #3319:


14 months ago
#294

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

#295 @jorgefilipecosta
14 months ago

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.

#298 @davidbaumwald
14 months ago

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.

This ticket was mentioned in PR #3428 on WordPress/wordpress-develop by hellofromtonya.


14 months ago
#301

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

This ticket was mentioned in PR #3418 on WordPress/wordpress-develop by oandregal.


14 months ago
#302

Work In Progress.

Related:

## 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:

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:

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.

This ticket was mentioned in PR #3430 on WordPress/wordpress-develop by tellthemachines.


14 months ago
#303

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.

oandregal commented on PR #3418:


14 months ago
#304

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.

This ticket was mentioned in PR #3431 on WordPress/wordpress-develop by andrewserong.


14 months ago
#305

Backports the following Fluid Typography bug fixes from Gutenberg:

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.

andrewserong commented on PR #3431:


14 months ago
#306

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.

tellthemachines commented on PR #3431:


14 months ago
#307

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

andrewserong commented on PR #3431:


14 months ago
#308

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:

Please let me know if I missed anything @ramonjd!

andrewserong commented on PR #3428:


14 months ago
#309

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

ramonjd commented on PR #3431:


14 months ago
#310

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

ramonjd commented on PR #3431:


14 months ago
#311

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.

oandregal commented on PR #3418:


14 months ago
#314

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.

spacedmonkey commented on PR #3418:


14 months ago
#316

Unit tests where would be useful.

spacedmonkey commented on PR #3418:


14 months ago
#317

Unit tests where would be useful.

spacedmonkey commented on PR #3418:


14 months ago
#318

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.

oandregal commented on PR #3418:


14 months ago
#319

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?

This ticket was mentioned in PR #3437 on WordPress/wordpress-develop by ockham.


14 months ago
#320

spacedmonkey commented on PR #3418:


14 months ago
#321

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.

hellofromtonya commented on PR #3418:


14 months ago
#322

Currently looking at test coverage for the changes in this PR.

ockham commented on PR #3437:


14 months ago
#323

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.

#324 @davidbaumwald
14 months ago

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:

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

Props bernhard-reiter, czapla, annezazu, cbravobernal, ndiego, bjorsch, nendeb55.
See #56467.

#326 @davidbaumwald
14 months ago

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.

ockham commented on PR #3437:


14 months ago
#327

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 😅

#328 @davidbaumwald
14 months ago

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.

ockham commented on PR #3434:


14 months ago
#329

Merged into core by @davidb in https://core.trac.wordpress.org/changeset/54483.

hellofromtonya commented on PR #3418:


14 months ago
#330

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.

davidB commented on PR #3434:


14 months ago
#331

@ockham ,I m not inconvénients into this project. Maybe wrong @ into your comment.

ockham commented on PR #3437:


14 months ago
#332

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

ockham commented on PR #3418:


14 months ago
#333

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 commented on PR #3434:


14 months ago
#334

@ockham ,I m not inconvénients into this project. Maybe wrong @ into your comment.

My bad! I meant @dream-encode. Sorry for the mixup!

This ticket was mentioned in PR #3439 on WordPress/wordpress-develop by ockham.


14 months ago
#335

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

ockham commented on PR #3437:


14 months ago
#336

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.

ockham commented on PR #3434:


14 months ago
#337

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

#338 @davidbaumwald
14 months ago

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.

#339 @hellofromTonya
14 months ago

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.

#341 @hellofromTonya
14 months ago

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:

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

Props aristath, oandregal, bernhard-reiter, spacedmonkey, hellofromTonya.
See #56467.

#343 @davidbaumwald
14 months ago

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.

This ticket was mentioned in PR #3441 on WordPress/wordpress-develop by oandregal.


14 months ago
#344

See:

## 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:

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

oandregal commented on PR #3418:


14 months ago
#345

I'm still investigating this for further improvement and have created https://github.com/WordPress/wordpress-develop/pull/3441 as a follow-up.

This ticket was mentioned in Slack in #core by desrosj. View the logs.


14 months ago

#347 @davidbaumwald
14 months ago

In 54497:

Editor: Merge latest fluid typography bugfixes for 6.1 Release Candidate 1.

Merges the following:

Follow-up to [54280].

Props andrewserong, isabel_brison, ramonopoly.
See #56467.

#348 @davidbaumwald
14 months ago

In 54500:

Editor: Add test data for Fluid Typography.

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

Props desrosj, hellofromTonya, SergeyBiryukov.
See #56467.

This ticket was mentioned in Slack in #core by jeffpaul. View the logs.


14 months ago

andrewserong commented on PR #3431:


14 months ago
#350

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.

ramonjd commented on PR #3428:


14 months ago
#351

I think we can close this one now that https://github.com/WordPress/wordpress-develop/pull/3431 has landed?

@Bernhard Reiter commented on PR #3439:


14 months ago
#352

Merged into core by @dream-encode in https://core.trac.wordpress.org/changeset/54490.

@Bernhard Reiter commented on PR #3428:


14 months ago
#353

I think we can close this one now that #3431 has landed?

Yeah, should be fine 👍

This ticket was mentioned in Slack in #core-editor by bph. View the logs.


14 months ago

This ticket was mentioned in Slack in #core by chaion07. View the logs.


14 months ago

@Bernhard Reiter commented on PR #3440:


14 months ago
#356

Merged into core by @dream-encode in https://core.trac.wordpress.org/changeset/54494.

@oandregal commented on PR #3441:


14 months ago
#357

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.

@Bernhard Reiter commented on PR #3430:


14 months ago
#358

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 |

|

| https://i0.wp.com/user-images.githubusercontent.com/96308/195569493-ebfffde1-ba6d-4129-8ca0-d96c5f25dbca.png | https://i0.wp.com/user-images.githubusercontent.com/96308/195569426-5efceeed-f41a-429d-953f-15e6f6623f3f.png |

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.

@oandregal commented on PR #3441:


14 months ago
#359

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.

@davidbaumwald commented on PR #3430:


14 months ago
#360

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.

@Bernhard Reiter commented on PR #3418:


14 months ago
#361

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

@isabel_brison commented on PR #3430:


14 months ago
#362

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

@mukesh27 commented on PR #3441:


14 months ago
#363

Thanks @oandregal This change improve the performance in my test.

@oandregal commented on PR #3441:


14 months ago
#364

Rebased from trunk to address the environment failures. I've seen some test have been disabled since this was reported.

#365 @jorgefilipecosta
14 months ago

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.

@jorgefilipecosta commented on PR #3441:


14 months ago
#366

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.

@desrosj commented on PR #3441:


14 months ago
#367

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.

#368 @davidbaumwald
14 months ago

  • Keywords dev-feedback commit added

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?

#370 @SergeyBiryukov
14 months ago

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:

Follow-up to [54257], [54335], [54383], [54483], [54486], [54490].

Props bernhard-reiter, audrasjb.
See #56467.

@SergeyBiryukov commented on PR #3485:


14 months ago
#371

Thanks for the PR! Merged in r54632.

#372 @desrosj
14 months ago

  • Keywords dev-feedback commit removed

Resetting the action-based keywords so the status is accurately depicted in ticket reports.

#373 @Bernhard Reiter
14 months ago

  • Keywords dev-reviewed added

#374 @davidbaumwald
14 months ago

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.

#376 @davidbaumwald
14 months ago

  • Description modified (diff)
  • Keywords dev-reviewed removed

Resetting the keywords after r54633.

This ticket was mentioned in PR #3489 on WordPress/wordpress-develop by @ramonopoly.


14 months ago
#377

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

https://i0.wp.com/user-images.githubusercontent.com/6458278/196566281-88078297-cc7b-4f73-832a-f4c8cef78264.png

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

@ramonopoly commented on PR #3489:


14 months ago
#378

cc @tellthemachines @noisysocks @andrewserong to check things out and make sure there's nothing missing 😄

#379 @SergeyBiryukov
14 months ago

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:

Follow-up to [54260], [54360], [54497], [54500].

Props ramonopoly, andrewserong, isabel_brison, Joen, bernhard-reiter.
See #56467.

#380 @SergeyBiryukov
14 months ago

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:

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.

@SergeyBiryukov commented on PR #3489:


14 months ago
#381

Thanks for the PR! Merged in r54646, backported to the 6.1 branch in r54647.

@ramonopoly commented on PR #3489:


14 months ago
#382

I'm very grateful for the quick reviews and commit. Thank you!

This ticket was mentioned in Slack in #core by audrasjb. View the logs.


14 months ago

This ticket was mentioned in Slack in #core by chaion07. View the logs.


14 months ago

#385 @Bernhard Reiter
14 months ago

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.

This ticket was mentioned in Slack in #core by bernhardreiter. View the logs.


14 months ago

#387 @Bernhard Reiter
14 months ago

  • Keywords commit dev-feedback added

Can I get a second review for backporting [54358] to the 6.1 branch please? :)

Version 0, edited 14 months ago by Bernhard Reiter (next)

This ticket was mentioned in Slack in #core by bernhardreiter. View the logs.


14 months ago

#389 @SergeyBiryukov
14 months ago

  • Keywords dev-reviewed added; dev-feedback removed

[54687] looks good to backport to the 6.1 branch.

This ticket was mentioned in Slack in #core by bernhardreiter. View the logs.


14 months ago

This ticket was mentioned in PR #3525 on WordPress/wordpress-develop by @cbravobernal.


14 months ago
#391

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

#392 @Bernhard Reiter
14 months ago

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.

#393 @desrosj
14 months ago

  • Keywords commit dev-reviewed removed

Resetting the action-based keywords.

@Bernhard Reiter commented on PR #3525:


14 months ago
#394

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 🤔

@hellofromTonya commented on PR #3525:


14 months ago
#395

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.

This ticket was mentioned in PR #3527 on WordPress/wordpress-develop by @Bernhard Reiter.


14 months ago
#397

#398 @Bernhard Reiter
14 months ago

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.

@Bernhard Reiter commented on PR #3527:


14 months ago
#399

Thank you, folks!

Committed to Core trunk in r59693.

#400 @davidbaumwald
14 months ago

  • Keywords fixed-major commit dev-feedback added

Tagging for a second committer review.

#401 @hellofromTonya
14 months ago

  • Keywords dev-reviewed added; dev-feedback removed

[54693] LGTM for backport to 6.1 branch.

#402 @desrosj
14 months ago

[54693] looks good to me as well!

#403 @davidbaumwald
14 months ago

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.

#404 @hellofromTonya
14 months ago

  • Keywords commit dev-reviewed removed

Resetting keywords as all approved work as been committed and backported.

@Bernhard Reiter commented on PR #3527:


14 months ago
#405

@dream-encode merged to the 6.1 branch in r54694. Closing.

This ticket was mentioned in Slack in #core by hellofromtonya. View the logs.


14 months ago

#407 @hellofromTonya
14 months ago

  • Resolution set to fixed
  • Status changed from assigned to closed

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.

#408 @flixos90
13 months ago

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

@oandregal commented on PR #3319:


13 months ago
#409

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.

#410 @oandregal
13 months ago

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

Last edited 13 months ago by oandregal (previous) (diff)

#411 follow-up: @scruffian
13 months ago

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!

Last edited 13 months ago by sabernhardt (previous) (diff)

#413 in reply to: ↑ 411 @flixos90
13 months ago

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.

Last edited 13 months ago by flixos90 (previous) (diff)

This ticket was mentioned in PR #3536 on WordPress/wordpress-develop by @flixos90.


13 months ago
#414

cc @scruffian @oandregal @draganescu

Trac ticket:

@spacedmonkey commented on PR #3536:


13 months ago
#415

cc @oandregal

@oandregal commented on PR #3536:


13 months ago
#416

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

@oandregal commented on PR #3536:


13 months ago
#417

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

@flixos90 commented on PR #3536:


13 months ago
#418

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

@flixos90 commented on PR #3536:


13 months ago
#419

@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

@spacedmonkey commented on PR #3536:


13 months ago
#421

This is hard to code review the code to generate theme-php.php, fix the unit test and coding standards.

@flixos90 commented on PR #3536:


13 months ago
#422

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

@spacedmonkey commented on PR #3536:


13 months ago
#423

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.

@flixos90 commented on PR #3536:


13 months ago
#424

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

@flixos90 commented on PR #3536:


13 months ago
#425

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

@oandregal commented on PR #3536:


13 months ago
#426

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

@oandregal commented on PR #3536:


13 months ago
#427

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.

@oandregal commented on PR #3536:


13 months ago
#428

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.

@spacedmonkey commented on PR #3536:


13 months ago
#429

In trunk
https://i0.wp.com/user-images.githubusercontent.com/237508/200811706-f2959f29-46a0-4f35-a2ed-5de5efb8e3c1.png
In this branch.
https://i0.wp.com/user-images.githubusercontent.com/237508/200811711-36dea048-d168-4c25-b115-0596928a117b.png

@spacedmonkey commented on PR #3536:


13 months ago
#430

In trunk
https://i0.wp.com/user-images.githubusercontent.com/237508/200811706-f2959f29-46a0-4f35-a2ed-5de5efb8e3c1.png
In this branch.
https://i0.wp.com/user-images.githubusercontent.com/237508/200811711-36dea048-d168-4c25-b115-0596928a117b.png

@flixos90 commented on PR #3536:


13 months ago
#431

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

@Mamaduka commented on PR #3525:


13 months ago
#432

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.

@Mamaduka commented on PR #3489:


13 months ago
#433

@SergeyBiryukov, do you know if r54647 was reverted from 6.1 branch?

@Mamaduka commented on PR #3489:


13 months ago
#434

Good, the commit hasn't been reverted. We'll ship the client-side code in 6.1.1.

@SergeyBiryukov commented on PR #3489:


13 months ago
#435

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 😅

@Mamaduka commented on PR #3489:


13 months ago
#436

That saves us work for the minor release 😄

@ramonopoly commented on PR #3489:


13 months ago
#437

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 😄

@Mamaduka commented on PR #3489:


13 months ago
#438

Thank you, @ramonjd. I've already cherry-picked https://github.com/WordPress/gutenberg/pull/44993 for 6.1.1.

@Bernhard Reiter commented on PR #3337:


11 months ago
#441

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

@poena commented on PR #3337:


11 months ago
#442

The earlier, the more time there is to test using the theme support in the bundled themes.

@ironprogrammer commented on PR #3337:


11 months ago
#443

@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 😅)

@Bernhard Reiter commented on PR #3337:


11 months ago
#444

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

@oandregal commented on PR #3441:


9 months ago
#445

I'm proposing we revert this change at https://github.com/WordPress/wordpress-develop/pull/4145 as it introduced a bug.

#446 @audrasjb
9 months ago

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

Note: See TracTickets for help on using tickets.