-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update WP compatibility check in gutenberg_pre_init()
#29938
Update WP compatibility check in gutenberg_pre_init()
#29938
Conversation
The plugin relies on `WP_Block_Supports`, which was added in 5.6 and `register_block_format()`, which was added in 5.5.
When `return` is used here, Gutenberg is not loaded and the other hooks added in this file use functions that are only loaded with Gutenberg.
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. |
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. Activating-Gutenberg-10-2-1-on-older-site.mp4 |
I see another line where Line 172 in b8bb4fb
We should probably move the version to the constant to make it easier to upgrade in the future. |
Previously reported in #27998 |
I'll update the PR to add the
gutenberg/bin/generate-gutenberg-php.php Line 19 in da8555d
Does it complicate things too much to add this to
I completely missed this! 🤦🏻 |
I landed #30230 to unblock this PR.
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be good to go now with the changes I applied.
It works great now in my testing when using the latest |
Minimum required WP version is 5.6 (WordPress#29701 and WordPress#29938). `wp_filter_content_tags` was added in 5.5 so these checks is no longer needed.
Description
This updates the
version_compare()
check ingutenberg_pre_init()
in a few ways:WP_Block_Supports
, which was added in WP 5.6, andregister_block_format()
, which was added in WP 5.5.5.7
rather than5.7.0
.version_compare( '5.7', '5.7.0', '<' )
evaluates astrue
, 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.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 thereturn
, 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: