Update WP compatibility check in gutenberg_pre_init()

[jeremyfelt]

Description

This updates the version_compare() check in gutenberg_pre_init() in a few ways:

1. Move from requiring 5.3 to 5.6. The plugin relies on WP_Block_Supports, which was added in WP 5.6, and register_block_format(), which was added in WP 5.5.
2. Fix the version comparison. WordPress reports its version as 5.7 rather than 5.7.0. version_compare( '5.7', '5.7.0', '<' ) evaluates as true, which puts 5.7.1 as the actual minimum version. When compatibility is checked against a major WP release, the X.Y version number should be used. See previously, Gutenberg is not compatible with WordPress 5.0 #15565.
3. After adding an admin notice, the plugin bails with return; and Gutenberg libraries are not loaded. Other hooks are added by the plugin that require those libraries, and a fatal error occurs rather than a compatibility notice. This removes the return, which helps to eliminate immediate fatal errors and allows the notice to be shown.

A (likely preferable) alternative to item 3 would be to remove all other functionality from the main plugin file so that it too is only loaded when gutenberg_pre_init() fires successfully.

Current culprits appear to be:

• modify_welcome_panel()
• modify_admin_bar()
• gutenberg_site_editor_menu()
• gutenberg_menu()

How has this been tested?

I've tested by updating core back and forth between WP 5.3, 5.5, 5.6, and 5.7 while the plugin is in an active an inactive state.

Types of changes

Bug fix

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• [NA] My code follows the accessibility standards.
• [NA] I've tested my changes with keyboard and screen readers.
• My code has proper inline documentation.
• I've included developer documentation if appropriate.
• [NA] I've updated all React Native files affected by any refactorings/renamings in this PR.

[jeremyfelt]

I don't see how the end-to-end test failure is related to this change and I don't have the capability to restart the job to see if it's just a one-off issue. Happy to fix anything if needed! :)

[gziolo]

I don't see how the end-to-end test failure is related to this change and I don't have the capability to restart the job to see if it's just a one-off issue. Happy to fix anything if needed! :)

Yes, it looks unrelated. E2E tests don't run with the older versions of WordPress. I re-triggered those tests.

[paaljoachim]

Hey

I just want to say that I tried activating the Gutenberg plugin 10.2.1 on an older WP site that is running 5.3.6.
It would not activate and gave the message that the plugin could not be activated as a fatal error was detected (loosely translated from Norwegian).
It would be helpful if it also mentioned update to the newest version of WordPress to be able to use a new version of Gutenberg.

Activating-Gutenberg-10-2-1-on-older-site.mp4

[gziolo]

I see another line where 5.3 is hardcoded:

gutenberg/gutenberg.php

Line 172 in b8bb4fb

printf( __( 'Gutenberg requires WordPress %s or later to function properly. Please upgrade WordPress before activating Gutenberg.', 'gutenberg' ), '5.3.0' );

We should probably move the version to the constant to make it easier to upgrade in the future.

[swissspidy]

Previously reported in #27998

[jeremyfelt]

I'll update the PR to add the return statement back in. #30230 is excellent. 👍🏻

We should probably move the version to the constant to make it easier to upgrade in the future.

gutenberg/bin/generate-gutenberg-php.php

Line 19 in da8555d

function print_production_defines() {

Does it complicate things too much to add this to print_production_defines()? If I understand how that file is used, it could then be automatically generated based on the plugin header's required version.

Previously reported in #27998

I completely missed this! 🤦🏻

[gziolo]

I landed #30230 to unblock this PR.

Does it complicate things too much to add this to print_production_defines()? If I understand how that file is used, it could then be automatically generated based on the plugin header's required version.

I thought about a simpler approach where we define the constant in the file, but given that we need it only on production, we can take a more complex path 😄 I leave it up to you to decide. The solution you mentioned has the benefit of updating only the minimum version in the plugin's metadata moving forward. The downside is that we would not have access to this constant in development mode, so we would have to account for that somehow.

[gziolo]

This should be good to go now with the changes I applied.

[gziolo]

It works great now in my testing when using the latest trunk.