-
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
Plugin: Add requirement for minimum and maximum WordPress versions #35194
Open
azaozz
wants to merge
17
commits into
trunk
Choose a base branch
from
fix/maximum-supported-wp-version
base: trunk
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
+246
−20
Open
Changes from all commits
Commits
Show all changes
17 commits
Select commit
Hold shift + click to select a range
6222b71
Add min and max WP version constants
azaozz c5205ae
Fix docblocks for filter callbacks.
azaozz a2c4cf0
Fix docs string order.
azaozz 4697e9e
Update gutenberg.php
draganescu 0f824b7
Update gutenberg.php
draganescu c976fb6
Update gutenberg.php
draganescu fcc78ae
Update to current versions
azaozz 2748c42
More cleanup and updates
azaozz ef09cbc
Fix typo
azaozz b475a7d
Only show the warnings on the Dashboard and the Plugins screen.
azaozz 1927d21
Disable Gutenberg during the beta period as well
youknowriad 09519e2
Add/fix the explanations on how to set GUTENBERG_MAX_WP_VERSION.
azaozz ae895f6
Add disabled action links notice,
azaozz ddc4ce3
Move `(disabled)` before `Deactivate`.
azaozz 773ba28
Update the `since` for 17.2.0, add some more inline comments.
azaozz 61c973e
Update: do not disable the plugin in the next development version of WP.
azaozz 187366a
Merge branch 'trunk' into fix/maximum-supported-wp-version
azaozz File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
Is the min version always known for each Gutenberg release?
What if the plan changes and thus that version might be different (maybe older such as a previous minor or later)? Later isn't necessarily problematic as the remedy is to upgrade. Older is problematic in that a fatal error might happen.
Wondering if instead, this minimum version should be set by Core and consumed in the plugin. For example, Core could provide a global function such as
_get_plugin_wp_min_compatible_version()
where for-core plugins like Gutenberg could invoke. Let Core determine which version is the min compatible.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.
Uh, sorry but I think I'm missing something? Does that mean we're getting rid of the "Requires at least" plugin header?
That means a plugin will not "know" what is the minimum WP version it supports at release, and want to change/fix it later? This hasn't been a problem... forever, not sure it is a problem now?
Not sure how core would "know" if a plugin is fully compatible or not. Emphasis on "fully compatible" here as some incompatibilities are not obvious or easy to detect.
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.
Whoops, this isn't correct. Sorry. It's a minimum version in Core, but a max version in the plugin.
Historically within Core itself, it views the minimum compatible version of the GB plugin to be the first version that causes a fatal error. That's very different from defining "fully compatible". It's focused on preventing fatal errors for users.
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.
Typically the versions that are compatible with the WordPress version in development aren't known until close to WP Beta 1.
Just before Beta 1 or during beta is when the harded code GB version is updated Core (currently within
_upgrade_core_deactivate_incompatible_plugins()
).What's my point?
The plugin's actual maximum WordPress version might not be known at the plugin release time. It might change as the WordPress dev cycle advances into beta.
For example, a fatal error happened recently which then caused an update in Core to set the 17.6 as the minimum compat version for WP 6.5. I'm wondering if 17.5.x or older would have know it's max WP version is WP 6.4, and not 6.5?
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.
How can released GB plugin versions know if Core itself will deactivate it due to be incompatible?
That's where the plugin could use the proposed Core function
_get_plugin_wp_min_compatible_version()
.Using the previous example, that Core function would return
17.6
. So then released plugin versions could invoke the Core function and take action itself. Then in time once all released versions of the plugin have this new code, Core would no longer need to deactivate the plugin, i.e. because the plugin handles it itself.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.
Ahh I see. I knew I'm missing something :)
The same way it "knows" it is not going to be installed on a server with a PHP version lower than the minimum required, and in a "too old" WP? I.e. the plugin sets its own requirements, and WP makes sure these requirements are met. Same as PHP and WP versions, and now plugin dependencies.
Similar logic has existed in core since 2007 (WP 2.0) I think: plugins can specify minimal WP version. This is opt-in and enforced by the plugins repo API and by the core plugins API.
Adding another optional requirement for a maximum supported WP version would be best to follow the same logic/design imho, and should be available for all plugins. I know of 2-3 other plugins that can use this right now, for example the Test jQuery Updates plugin that will probably be used again for jQuery 4.0.
Hmm, don't think WP (core) would be able to "know better" which plugin is compatible with which version. This info should be in the plugin, and is set to a constant in this PR. So not sure why a plugin will have to use a WP function to get the info it sets itself? Think it is the opposite: WP should "read" what the plugin requirements are and check if they are satisfied. If not satisfied WP should not load the plugin and should warn the users/site admins.
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.
Right. For that reason the "maximum supported" WP version can only be a major (two digits) version and should (generally) match the "tested up to" plugin header.
Minor version of Gutenberg will still support the same "max WP" version. In addition the "max WP" version will include support for the next "WP Trunk", (alpha, beta, RC). This is needed in order to be able to use the current Gutenberg releases in a WP Trunk installs, like on wp.org. Please see the discussion above.