Update the Gutenberg plugin to require at least the WP 6.1 version

[Mamaduka]

What?

WordPress 6.2 was released a month ago. It's time to bump the minimum required version for the Gutenberg plugin and remove the compat layer.

It also fixes #45870.

How?

• I removed all the files from the compat/wordpress-6.1 directory.
• Fixed all the PHP notices and fatal errors.
• Updated client-asset.php to handle preferences API (7337428). Props to @talldan for leaving detailed instructions 🦸

Testing Instruction

• Run the Gutenberg plugin with WP 6.1, and confirm editors work as before.
• Run the Gutenberg plugin with WP 6.2, and confirm editors work as before.

[github-actions]

Flaky tests detected in 9e2575bbcc84984ca2d6dfb379be570fd56368ee.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/4804708630
📝 Reported issues:

• [Flaky Test] allows rotating using the crop tools #36904 in /test/e2e/specs/editor/blocks/image.spec.js
• [Flaky Test] should not allow blocks to be inserted in inner blocks #44341 in specs/editor/plugins/cpt-locking.test.js

[youknowriad]

Thanks for starting this PR, nice to see. There might be a few more cleanup tasks to do:

• Update the layout block support

  gutenberg/lib/block-supports/layout.php

  Line 86 in df35418

  // TODO: Use `safecss_filter_attr` instead when the minimum required WP version is >= 6.1.

• Remove typography deprecated function

  gutenberg/lib/block-supports/typography.php

  Lines 214 to 250 in df35418

  	/**
  	* This method is no longer used and has been deprecated in Core since 6.1.0.
  	*
  	* It can be deleted once Gutenberg's minimum supported WordPress version is >= 6.1
  	*
  	* Generates an inline style for a typography feature e.g. text decoration,
  	* text transform, and font style.
  	*
  	* @since 5.8.0
  	* @deprecated 6.1.0
  	*
  	* @param array $attributes Block's attributes.
  	* @param string $feature Key for the feature within the typography styles.
  	* @param string $css_property Slug for the CSS property the inline style sets.
  	*
  	* @return string CSS inline style.
  	*/
  	function gutenberg_typography_get_css_variable_inline_style( $attributes, $feature, $css_property ) {
  	// Retrieve current attribute value or skip if not found.
  	$style_value = _wp_array_get( $attributes, array( 'style', 'typography', $feature ), false );
  	if ( ! $style_value ) {
  	return;
  	}
  	// If we don't have a preset CSS variable, we'll assume it's a regular CSS value.
  	if ( ! str_contains( $style_value, "var:preset|{$css_property}|" ) ) {
  	return sprintf( '%s:%s;', $css_property, $style_value );
  	}
  	// We have a preset CSS variable as the style.
  	// Get the style value from the string and return CSS style.
  	$index_to_splice = strrpos( $style_value, '|' ) + 1;
  	$slug = substr( $style_value, $index_to_splice );
  	// Return the actual CSS inline style e.g. `text-decoration:var(--wp--preset--text-decoration--underline);`.
  	return sprintf( '%s:var(--wp--preset--%s--%s);', $css_property, $css_property, $slug );
  	}

• Some routing back compat code to remove

  gutenberg/lib/compat/plugin/edit-site-routes-backwards-compat.php

  Line 1 in df35418

  <?php

• Some cleanup in the style engine

  gutenberg/packages/style-engine/class-wp-style-engine-css-declarations.php

  Lines 20 to 31 in df35418

  	/**
  	* An array of valid CSS custom properties.
  	* CSS custom properties are permitted by safecss_filter_attr()
  	* since WordPress 6.1. See: https://core.trac.wordpress.org/ticket/56353.
  	*
  	* This whitelist exists so that the Gutenberg plugin maintains
  	* backwards compatibility with versions of WordPress < 6.1.
  	*
  	* It does not need to be backported to future versions of WordPress.
  	*
  	* @var array
  	*/

  (cc @ramonjd )

These are the things I found, there might be other stuff that I missed.

[Mamaduka]

@fullofcaffeine, can we remove site editor route backward compatibility - lib/compat/plugin/edit-site-routes-backwards-compat.php? Introduced here, #42643.

[ramonjd]

Some cleanup in the style engine

Thanks for the ping. I've done a quick smoke test, removing the 6.1 compat code in gutenberg/packages/style-engine/class-wp-style-engine-css-declarations.php. Editor and unit tests are good to go.

Below is the diff. I'm happy to throw up a separate PR if it's not included in this one:

diff

diff --git a/packages/style-engine/class-wp-style-engine-css-declarations.php b/packages/style-engine/class-wp-style-engine-css-declarations.php
index 6e7fdfc58e..a91bcab520 100644
--- a/packages/style-engine/class-wp-style-engine-css-declarations.php
+++ b/packages/style-engine/class-wp-style-engine-css-declarations.php
@@ -17,22 +17,6 @@ if ( class_exists( 'WP_Style_Engine_CSS_Declarations' ) ) {
  * @access private
  */
 class WP_Style_Engine_CSS_Declarations {
-	/**
-	 * An array of valid CSS custom properties.
-	 * CSS custom properties are permitted by safecss_filter_attr()
-	 * since WordPress 6.1. See: https://core.trac.wordpress.org/ticket/56353.
-	 *
-	 * This whitelist exists so that the Gutenberg plugin maintains
-	 * backwards compatibility with versions of WordPress < 6.1.
-	 *
-	 * It does not need to be backported to future versions of WordPress.
-	 *
-	 * @var array
-	 */
-	protected static $valid_custom_declarations = array(
-		'--wp--style--unstable-gallery-gap' => 'gap',
-	);
-
 	/**
 	 * An array of CSS declarations (property => value pairs).
 	 *
@@ -140,23 +124,6 @@ class WP_Style_Engine_CSS_Declarations {
 	 */
 	protected static function filter_declaration( $property, $value, $spacer = '' ) {
 		$filtered_value = wp_strip_all_tags( $value, true );
-
-		/**
-		 * Allows a specific list of CSS custom properties starting with `--wp--`.
-		 *
-		 * CSS custom properties are permitted by safecss_filter_attr()
-		 * since WordPress 6.1. See: https://core.trac.wordpress.org/ticket/56353.
-		 *
-		 * This condition exists so that the Gutenberg plugin maintains
-		 * backwards compatibility with versions of WordPress < 6.1.
-		 *
-		 * It does not need to be backported to future versions of WordPress.
-		 */
-		if ( '' !== $filtered_value && isset( static::$valid_custom_declarations[ $property ] ) ) {
-			return safecss_filter_attr( static::$valid_custom_declarations[ $property ] . ":{$spacer}{$value}" ) ?
-				"{$property}:{$spacer}{$value}" : '';
-		}
-
 		if ( '' !== $filtered_value ) {
 			return safecss_filter_attr( "{$property}:{$spacer}{$filtered_value}" );
 		}

[Mamaduka]

Thank you, @ramonjd! I'll include Style Engine cleanup here 👍

[Mamaduka]

I removed the remaining compat code beside edit-site-routes-backward-compat.php. I'm going to wait for @fullofcaffeine feedback on this one first.

[ntsekouras]

Thanks for handling this George! In my testing everything looked good. We can probably remove some PHP tests too, but we can do it later too.

[Mamaduka]

Thanks for testing, Nik!

I'm thinking of merging this, and then I can do a follow-up for the edit-site-routes-backward-compat.php and PHP test files.

[noahtallen]

Just a heads up -- the "End-to-End Tests / Puppeteer - 3 (push)" seems to be permafailing since this was merged 🤔

[Mamaduka]

@noahtallen, failure is caused by the core change. See #50185

[tellthemachines]

Hi! This PR has caused a regression in layout styles, due to the core class_wp_theme_json being used instead of lib/class-wp-theme-json-gutenberg.php. Adding back the gutenberg_enqueue_global_styles function from the 6.1 script loader seems to fix it.

[ramonjd]

This PR has caused a regression in layout styles, due to the core class_wp_theme_json being used instead of lib/class-wp-theme-json-gutenberg.php. Adding back the gutenberg_enqueue_global_styles function from the 6.1 script loader seems to fix it.

Is it specific to the grid layout? As far as I can see it hasn't yet been shipped to core (at the time of writing). Added comment over here.

[tellthemachines]

Is it specific to the grid layout?

No, all the work from #47858 has regressed too.

Edit: we seem to have this problem every time we remove support for an older WP version; perhaps the code to run the Gutenberg versions of these classes when the plugin is enabled shouldn't live inside the compat/wordpress-x.x folders.

[Mamaduka]

Thank you, @tellthemachines.

we seem to have this problem every time we remove support for an older WP version; perhaps the code to run the Gutenberg versions of these classes when the plugin is enabled shouldn't live inside the compat/wordpress-x.x folders.

That is very true 😞 I will start looking into how we can fix this in a more future-proof way.

What would be the best way to test that the new method works correctly for layouts? Just make sure changes from #47858 are correctly applied.

Side note: It would be great to add regression tests for layout(s). I belive we briefly talked about this during WordCamp Asia.

[Mamaduka]

I started working on the fix in #50310. I would appreciate the testing instructions for the regression.

[tellthemachines]

The easiest way to test this is with the following markup:

<!-- wp:group {"layout":{"type":"constrained"}} -->
<div class="wp-block-group"><!-- wp:paragraph -->
<p>First child of group</p>
<!-- /wp:paragraph -->

<!-- wp:paragraph -->
<p>Second child of group</p>
<!-- /wp:paragraph --></div>
<!-- /wp:group -->

The first paragraph inside the group should have the following CSS rule:

.editor-styles-wrapper :where(body .is-layout-constrained) > :first-child:first-child {
    margin-block-start: 0;
}

And both paragraphs should have:

.editor-styles-wrapper :where(body .is-layout-constrained) > * {
    margin-block-start: 1.5rem;
    margin-block-end: 0;
}

Whereas in the current state of trunk, both paragraphs have:

.editor-styles-wrapper .is-layout-constrained > * {
    margin-block-start: 0;
    margin-block-end: 0;
}

And the second paragraph has:

.editor-styles-wrapper .is-layout-constrained > * + * {
    margin-block-start: 1.5rem;
    margin-block-end: 0;
}

[tellthemachines]

Side note: It would be great to add regression tests for layout(s). I belive we briefly talked about this during WordCamp Asia

Yes that is very true! We definitely need to add tests before stabilising the layout support. Which I hope will happen soon 😅

[talldan]

Just a note that this also seems to have caused an issue with the mobile navigation menu toggle - #50211. I did a bisect to check where it was introduced and it seems to be this PR.

#50310 doesn't seem to resolve the issue.

[Mamaduka]

Thanks for the note, @talldan.

I think the block view script handlers were not ported in WP 6.1, and the code was in the wrong compat layer.

@gziolo, @aristath, can you confirm which WP version includes viewScript handling so I can update the file in the correct compat directory?

[talldan]

It looks like there's also this code here related to view scripts:

gutenberg/lib/experimental/blocks.php

Lines 8 to 79 in e6450b2

	if ( ! function_exists( 'wp_enqueue_block_view_script' ) ) {
	/**
	* Enqueues a frontend script for a specific block.
	*
	* Scripts enqueued using this function will only get printed
	* when the block gets rendered on the frontend.
	*
	* @since 6.2.0
	*
	* @param string $block_name The block name, including namespace.
	* @param array $args An array of arguments [handle,src,deps,ver,media,textdomain].
	*
	* @return void
	*/
	function wp_enqueue_block_view_script( $block_name, $args ) {
	$args = wp_parse_args(
	$args,
	array(
	'handle' => '',
	'src' => '',
	'deps' => array(),
	'ver' => false,
	'in_footer' => false,
	// Additional args to allow translations for the script's textdomain.
	'textdomain' => '',
	)
	);
	/**
	* Callback function to register and enqueue scripts.
	*
	* @param string $content When the callback is used for the render_block filter,
	* the content needs to be returned so the function parameter
	* is to ensure the content exists.
	* @return string Block content.
	*/
	$callback = static function( $content, $block ) use ( $args, $block_name ) {
	// Sanity check.
	if ( empty( $block['blockName'] ) || $block_name !== $block['blockName'] ) {
	return $content;
	}
	// Register the stylesheet.
	if ( ! empty( $args['src'] ) ) {
	wp_register_script( $args['handle'], $args['src'], $args['deps'], $args['ver'], $args['in_footer'] );
	}
	// Enqueue the stylesheet.
	wp_enqueue_script( $args['handle'] );
	// If a textdomain is defined, use it to set the script translations.
	if ( ! empty( $args['textdomain'] ) && in_array( 'wp-i18n', $args['deps'], true ) ) {
	wp_set_script_translations( $args['handle'], $args['textdomain'], $args['domainpath'] );
	}
	return $content;
	};
	/*
	* The filter's callback here is an anonymous function because
	* using a named function in this case is not possible.
	*
	* The function cannot be unhooked, however, users are still able
	* to dequeue the script registered/enqueued by the callback
	* which is why in this case, using an anonymous function
	* was deemed acceptable.
	*/
	add_filter( 'render_block', $callback, 10, 2 );
	}
	}

If I delete that it works again. 🤷

[gziolo]

can you confirm which WP version includes viewScript handling so I can update the file in the correct compat directory?

viewScript and the ability to pass an array of scripts were added to WordPress core in 6.1.

It looks like there's also this code here related to view scripts:
If I delete that it works again. 🤷

That would be very surprising that it impacts the Navigation block. I'll investigate today.

[Mamaduka]

@talldan, if I add both these filters, then the viewScript works again. Adding just one of them causes a fatal error.

[gziolo]

@talldan, if I add both these filters, then the viewScript works again. Adding just one of them causes a fatal error.

We probably need to deregister scripts registered in WP core, similar to this line:

gutenberg/lib/compat/wordpress-6.1/blocks.php

Line 86 in e6450b2

wp_deregister_script( $view_script_handle );

We have a similar logic for individual block styles in:

gutenberg/lib/blocks.php

Line 188 in d54dc62

function gutenberg_register_core_block_assets( $block_name ) {

[talldan]

Out of interest, what's the issue with removing the code in the experimental/blocks.php file? What does it do that's different to core?

[gziolo]

Out of interest, what's the issue with removing the code in the experimental/blocks.php file? What does it do that's different to core?

See #50364. It's all about preventing registering a script using the same handle twice. When it happens, _doing_it_wrong gets called, and that apparently breaks something.

[aaronrobertshaw]

I found this PR via a git bisect while investigating #50416. That issue appears to be due to the same problem @tellthemachines flagged.

A quick test of #50310 shows it fixes the issue in #50416 as well.

[fullofcaffeine]

@Mamaduka Sorry for missing this one! :/ -- next time if I don't reply in a timely manner, feel free to ping me via Slack in the WP core channel (my handle is the same there).