Opened 4 years ago
Last modified 12 months ago
#51139 new enhancement
Allow "tested up to" PHP version statement for plugins & themes
Reported by: | aaroncampbell | Owned by: | |
---|---|---|---|
Milestone: | Awaiting Review | Priority: | normal |
Severity: | normal | Version: | |
Component: | General | Keywords: | |
Focuses: | Cc: |
Description
Minimum PHP Version support for plugins and themes was added in #40934 (see also #meta2952 and #meta3718 for support added to the plugin and theme directories). At that time a "tested up to" PHP version was talked about but seemed like it needed it's own ticket. This is that ticket :)
I'm proposing to allow plugins and themes to have a "tested up to" PHP version statement (Not a maximum). This version statement should not mean that plugins should not be shown in the new plugins screen, etc, but can be used for warnings for users like we do with "tested up to" WordPress versions.
Considering the new PHP version support proposal, this will help to better equip both users and hosts to make intelligent, informed decisions around upgrading PHP. Host would be able to scan sites and proactively update PHP without relying on slow linting tools.
One of the biggest hurdles will be the time it takes to get enough plugin developers using this header for the data to be useful. The biggest, most popular plugins will adopt it quickly which will help immediately. Also, for those plugins hosted on the .org directory, we could use a threshold to fill in the data for plugins that haven't yet specified it. If some number of sites, say 100 for this example, with somePlugin version X.Y.Z say they're on PHP A.B.C when checking to see if there are updates available, we could reasonably say that X.Y.Z is compatible up to PHP A.B.C. We could only do this for plugins with enough installs to meet that threshold, but it would certainly make the information immediately useful for anything needing to automate PHP version support checks.
To do this, the following work would have to be done:
Core
- Plugin header parser changes for "tested up to" PHP version statement.
- Warnings added that use this header (mockups needed)
Meta
- Plugin readme parser changes for "tested up to" PHP version statement. Source location: https://meta.trac.wordpress.org/browser/sites/trunk/wordpress.org/public_html/wp-content/plugins/plugin-directory/readme
- Plugins API changes. Source location: https://meta.trac.wordpress.org/browser/sites/trunk/wordpress.org/public_html/wp-content/plugins/plugin-directory/standalone
- Logic added to track "tested up to PHP" for plugins/themes not specifying it
Plugin directory
- Show tested up to PHP version on plugins page. Source location: https://meta.trac.wordpress.org/browser/sites/trunk/wordpress.org/public_html/wp-content/themes/pub/wporg-plugins/template-parts/plugin.php (Simple mockup attached)
Attachments (1)
Change History (22)
#2
@
4 years ago
Just linking to some previous discussions and comments on the Tested PHP
header:
- https://meta.trac.wordpress.org/ticket/2952#comment:5
- comment:17:ticket:40934
- comment:29:ticket:40934
- comment:58:ticket:40934
Some thoughts on the naming:
Requires at least
is actually an alias forRequires
.Tested up to
is also an alias forTested
.
Since the Requires PHP
header is based on the shorter name (and not Requires at least PHP
), it seems that Tested PHP
would be more consistent with the existing naming (as opposed to Tested up to PHP
, for example).
The Plugin Directory UI can of course display that as "Tested up to PHP" for clarity, like on the screenshot above.
#3
@
4 years ago
Thanks for the added links @SergeyBiryukov, and I agree that Tested PHP
is probably better in order to be consistent with the newer naming preferences. Displaying "Tested up to PHP" as the user facing message is probably preferred but if someone has a better suggestion I'm fine with anything we think users can reasonably understand.
This ticket was mentioned in Slack in #hosting-community by mike. View the logs.
4 years ago
This ticket was mentioned in Slack in #core by mike. View the logs.
4 years ago
#6
follow-up:
↓ 14
@
4 years ago
I especially like the idea of automatically populating PHP compatibility information based on what WP.org knows about active plugins, their versions, and sites that are using them successfully.
That stands to be a pretty good measurement of what users consider to be "working" properly.
This ticket was mentioned in Slack in #core-site-health by sergey. View the logs.
4 years ago
This ticket was mentioned in Slack in #hosting-community by mike. View the logs.
4 years ago
This ticket was mentioned in Slack in #core by timothybjacobs. View the logs.
4 years ago
This ticket was mentioned in Slack in #hosting-community by javier. View the logs.
3 years ago
#11
@
18 months ago
This would be a particularly useful enhancement in light of the proposal to [formalize criteria for dropping the 'beta' label from the PHP compatibility table](https://make.wordpress.org/core/2023/06/20/proposal-criteria-for-removing-beta-support-from-each-php-8-version/#comment-44986).
The 'beta' label - intentionally or not - signals to the user that they should be on the lookout for compatibility issues. Hinting this on plugins/themes would provide the same indication, and lessen the pressure on community devs as they work to update their codebases.
This ticket was mentioned in Slack in #core by swissspidy. View the logs.
17 months ago
#13
follow-up:
↓ 17
@
17 months ago
I notice the proposed meta changes don't include changes to themes, just plugins. Was this an oversight?
#14
in reply to:
↑ 6
@
17 months ago
Replying to mikeschroder:
I especially like the idea of automatically populating PHP compatibility information based on what WP.org knows about active plugins, their versions, and sites that are using them successfully.
That stands to be a pretty good measurement of what users consider to be "working" properly.
I'm a big fan of automated testing for minimum/maximum. IMO this could be a field in addition to the author fields.
You could have Author supports min/max. Then "validated to work on min/max". This could even lead to notifying authors when something breaks inside of the bounds of what they claim to support.
This ticket was mentioned in Slack in #meta by toddrin. View the logs.
17 months ago
This ticket was mentioned in Slack in #core-php by toddrin. View the logs.
17 months ago
#17
in reply to:
↑ 13
@
17 months ago
Replying to toddrin:
I notice the proposed meta changes don't include changes to themes, just plugins. Was this an oversight?
Not an oversight, right now Themes doesn't have a hard-set for PHP version. The requirements/ headers for themes and plugins are different.
#18
@
15 months ago
PHP development is moving rapidly, and the new stringent take the PHP Group has on deprecation (albeit good) and shorter EOL spans are causing code to become incompatible fast. I welcome this addition sooner than later — not only for WordPress users but also to encourage developers to test the latest versions.
I recommend doing something like "Supports PHP 5.6 ~ 7.4" to declutter the sidebars.
The same can be done for WordPress: "Supports WordPress 5.5 ~ 6.3.1".
Plugin directory plugin sidebar with "Tested up to PHP" added