Gutenberg 14.8.0+ compat issue with WordPress < 6.1

[Otto42]

Gutenberg 14.8.0+ compat issue with WordPress < 6.1

14.8.0 introduced the use of has_same_registered_blocks function call:
https://plugins.trac.wordpress.org/changeset/2837553/gutenberg/trunk/lib/experimental/class-wp-theme-json-resolver-gutenberg.php

This function was only added to WordPress in 6.1.:
https://core.trac.wordpress.org/changeset/54493

However, Gutenberg itself was marked as compatible with 6.0:
https://plugins.trac.wordpress.org/changeset/2837553/gutenberg/trunk/gutenberg.php

Result attempting to install Gutenberg 14.8.0 and up with WordPress 6.0 will cause a fatal error. Example:
https://wordpress.org/support/topic/call-to-undefined-method-wp_theme_json_resolver_gutenberghas_same_registered_b/

Thus, the compatibility needs to be marked at 6.1 in the plugin headers, which will prevent older installs from accidentally breaking the site.

[kathrynwp]

@spacedmonkey @oandregal @felixarntz – hey there, just a ping to see if any of you might be able to have a look at this. Thanks!

[noahtallen]

I'll take a look and try to get a fix into a patch release.

[noahtallen]

Thus, the compatibility needs to be marked at 6.1 in the plugin headers, which will prevent older installs from accidentally breaking the site.

We do need to add back compatibility in Gutenberg for this feature -- Gutenberg does need to be compatible with 6.0, since its goal is to support the last two major WordPress releases (which would be 6.1 and 6.0 currently). At least, that's what I've heard from others in the project!

[noahtallen]

possibly fixed by #46806, will test

[noahtallen]

Ok, so I've confirmed that the trunk branch is compatible with WordPress 6.0. This means that everything has been fixed! The challenge is getting those fixes into the 14.8.x release. Most of the fixes include changes targeted for the next Gutenberg release, so I need to make sure I'm not introducing new issues when porting over just the fixes.

The good news is that 14.9 will be compatible with 6.0, assuming nothing else breaks in the next week!

[noahtallen]

I can fix compatibility in 14.8 by cherry-picking the following PRs into the release branch:

• Try: bundle WP_Theme_JSON class instead of inheriting per WordPress version #46579
• Try: bundle the WP_Theme_JSON_Resolver class instead of inheriting per WordPress version #46750
• Fix compatibility with WP 6.0.x #46806
• [Mobile] - Block Editor Settings Endpoint - Use wp_get_global_styles instead of gutenberg_get_global_styles #46809

Explanations:

• "fix compat with 6.0.x" relies on the bundling of the WP_Theme_JSON class. so we need both of those.
• [Mobile] - Block Editor Settings Endpoint - Use wp_get_global_styles instead of gutenberg_get_global_styles #46809 is standalone compatibility fix
• however those two aren't enough; we also need Try: bundle the WP_Theme_JSON_Resolver class instead of inheriting per WordPress version #46750 to fix the has_same_registered_blocks issue

So... the problem is now that #46579 and #46750 are really big PRs. By cherry-picking just them, we potentially introduce new features or unfixed bugs that are intended for 14.9.... So I'm not entirely sure what to do. I'll reach out for some feedback

[noahtallen]

I've mostly verified that those PRs don't introduce new changes (and are just refactors of code that already exists in 14.8), I think we can put them in a patch release. I'll definitely be testing them thoroughly before pushing anything.

[Otto42]

Fair enough on adding 6.0 support back, but for the existing tags that are not compatible, somebody needs to retroactively edit them to have the compatibility tag correct. Just for sanity. And safety. We use that to prevent breaking sites, and right now, sites are being broken.

If you need any help with this email me.

[noahtallen]

14.8.3 has been released, which should be compatible with WP 6.0. I unfortunately don't know how to retroactively change those headers for 14.8.0, 14.8.1, and 14.8.2. I doubt I even have direct access to the plugin repo to do so -- I'm only using the existing point release processes which goes through GitHub Actions.

You could also technically say that 14.8.0 wasn't compatible with any WordPress version, due to a severe issue with publishing posts that was fixed in 14.8.1

[oandregal]

So... the problem is now that #46579 and #46750 are really big PRs. By cherry-picking just them, we potentially introduce new features or unfixed bugs that are intended for 14.9.... So I'm not entirely sure what to do. I'll reach out for some feedback

I can confirm these are refactors: they bundle the code in a single class when it was before in multiple folders and classes inheriting from each other. If anything, it fixes bugs like the one raised here.

It seems the issue was introduced at #46250 Apparently, it was reported and a fix prepared, though the fix missed the 14.8 window. To catch these things earlier, Gutenberg would benefit from running the CI tests in all the WordPress versions it supports. I presume most people test the PRs with only one WordPress runtime. cc @hellofromtonya @anton-vlasenko in case this is something in your radar.

I've tested that 14.8.2 breaks and 14.8.3 works fine again. Thanks for taking care of preparing the patch release, Noah!

[noahtallen]

Very happy to hear! I'll close this issue now. But I definitely agree we need to test compatibility before publishing the plugin. There was a fatal error in the original 14.x releases as well, which only happened with WP 6.0 and PHP 8. So this is two releases in a row that haven't been compatible with WP 6 at first!

[ockham]

But I definitely agree we need to test compatibility before publishing the plugin.

I wonder if we should run our existing test suite against currentWordPress - 1 in CI 🤔 I guess that should cover a lot of these errors? Probably too much stuff to run on every single PR, but it might make sense to do upon release. Not quite sure how to best flag errors in such a scenario; we could drop them into the release draft maybe?

Or maybe we should run those tests upon merge to trunk? This would give some ongoing visibility via ❌ marks next to those commits...

[noahtallen]

Yes definitely. I think at the very least, the phpunit suite would have caught all of these issues. My impression is that the vast majority of issues are related to PHP compatibility, rather than client-side code. That kinda makes sense, since Gutenberg is mostly self-contained on the client-side. It bundles almost everything it needs itself. Whereas in PHP, it relies on both PHP working as expected and WordPress working as expected.

So I think PHPunit with currentWordPress - 1 along with PHP 8 would do a pretty good job as a baseline. (PHP 8 seems to be stricter about types than PHP 7, meaning more fatals can happen)

[ockham]

FWIW, PHP 8 coverage is also one of the goals of @hellofromtonya's #43333. I think that @anton-vlasenko actually has a PR to implement that ready for review: #46510.

Edit: Since that PR also moves PHP unit tests from unit-tests.yml (which they share with JS unit tests) into their own workflow file, let's wait for it to land so that we can then consider adding currentWordPress - 1 to the PHP unit test matrix.

[ockham]

I've filed #46979 to keep track of this.