WordPress.org

Make WordPress Core

Opened 6 weeks ago

Last modified 3 days ago

#40934 assigned task (blessed)

Allow PHP version requirements for plugins & themes

Reported by: joostdevalk Owned by: joostdevalk
Milestone: 4.9 Priority: normal
Severity: normal Version:
Component: Plugins Keywords: dev-feedback
Focuses: ui, administration Cc:

Description

Not all plugins can work on PHP 5.2, like WordPress core currently does. Not all plugin developers want to support PHP 5.2, like core does. As a project, WordPress would like to move forward and have people on more recent PHP versions. One of the ways to reach that goal would be to show them that they cannot install a certain plugin or theme because their install does not meet the required criteria.

As such, I'm proposing to allow plugins and themes to have a minimum PHP version requirement. Not a maximum, just a minimum. This minimum version requirement should not mean that plugins should not be shown in the new plugins screen, for instance, instead, they should be shown but "disabled", with links to Wordpress.org pages explaining why, and how to upgrade their PHP.

To do this, the following work would have to be done:

Core

  • Plugin header parser changes for minimum PHP version requirement.
  • Disallow activating incompatible plugins from plugins list. Mockups required.
  • Add new plugins screen changes for plugins whose criteria do not match. Mockup attached.
  • Check plugin header on manual plugins installation to prevent fatal errors. Mockup required for error.

Meta

Plugin directory

WordPress dot org / Codex

  • Create pages on how to upgrade PHP, preferably with links to specific instructions for specific hosts

If this gets "blessed" I'll proceed to make individual smaller tickets for the individual changes.

Attachments (9)

cannot-install-plugin.jpg (174.4 KB) - added by joostdevalk 6 weeks ago.
Mockup for "cannot install plugin" on add new plugins screen
WHIP core - plugins page.png (232.4 KB) - added by hedgefield 6 weeks ago.
Incompatible plugins cannot be installed and show up red in the overview. Used the WP colors #FBEAEA for the background and #DC3232 for the button.
WHIP core - add plugin page.png (268.1 KB) - added by hedgefield 6 weeks ago.
Incompatible plugins cannot be installed and show up red in the overview. Used the WP colors #FBEAEA for the background and #DC3232 for the button.
WHIP core - plugin directory.jpg (171.0 KB) - added by hedgefield 6 weeks ago.
The statistics in the plugin directory show the required PHP version
WHIP core - plugin detail backend.png (383.6 KB) - added by hedgefield 6 weeks ago.
The plugin directory page in the backend can show a warning if the detected PHP version is too low, and the install button is red here too. I didn't edit the statistics in this one because it's still using the old plugin directory theme (see #40971)
WHIP core - PHP stats.png (243.6 KB) - added by hedgefield 6 weeks ago.
The plugin directory stats page with a table that shows PHP usage per user. I made up the numbers at random before I saw @pento's comment, so ignore those, they're for illustrative purposes ;)
WHIP core - updates page.png (129.8 KB) - added by hedgefield 5 weeks ago.
Rather than not showing the incompatible plugins in the Updates page at all or splitting it out somehow (you wouldn't be able to use the selection box because you wouldn't be allowed to update it), I put a message above the list to indicate there are plugins that cannot be updated.
WHIP core - plugin detail backend2.png (430.1 KB) - added by hedgefield 5 weeks ago.
I updated the More Details modal with the new plugin directory theme, made the PHP warning more fierce (because it's not a warning) and added more messaging next to the button, which I changed into a label, because it shouldn't be clickable.
WHIP core - add plugin page2.png (260.7 KB) - added by hedgefield 5 weeks ago.
And an alternative take on the Add Plugins page without the red tint and the button turned into a label. I used the compatibility check in the card's footer to put the PHP warning, since it doesn't matter if the plugin is compatible with Wordpress if it's not compatible with your PHP.

Change History (57)

@joostdevalk
6 weeks ago

Mockup for "cannot install plugin" on add new plugins screen

This ticket was mentioned in Slack in #core by joostdevalk. View the logs.


6 weeks ago

This ticket was mentioned in Slack in #meta by joostdevalk. View the logs.


6 weeks ago

#3 @swissspidy
6 weeks ago

Sounds like a duplicate of #23880.

Related: #33381, #12260, #24271.

#4 in reply to: ↑ description ; follow-ups: @johnbillion
6 weeks ago

If the WordPress project is to allow plugins or themes to specify a minimum PHP version, and indeed if core itself is to consider increasing its own minimum PHP version, the only way this will happen is if supporting documentation comes first. Everything else comes down to relatively trivial technical implementation.

Replying to joostdevalk:

To do this, the following work would have to be done:

  • Create pages on how to upgrade PHP, preferably with links to specific instructions for specific hosts

Communicating clearly to end users what PHP is, what a web server is, and what a web host is, is not easy. Indeed, many users aren't even aware of what WordPress is. Let's start with the documentation and work backwards.

#5 @johnbillion
6 weeks ago

Also this really is a duplicate of #23880. Opening new tickets just for visibility is not desirable.

#6 in reply to: ↑ 4 @joostdevalk
6 weeks ago

Communicating clearly to end users what PHP is, what a web server is, and what a web host is, is not easy. Indeed, many users aren't even aware of what WordPress is. Let's start with the documentation and work backwards.

We haven't done the first bit of that but would be happy to.

We do already have some examples at Yoast of documentation on how to update PHP, with links to a good amount of hosts:

https://kb.yoast.com/kb/how-to-update-your-php-version/

#7 follow-up: @jdgrimes
6 weeks ago

Another thing not mentioned: updates should be disabled when a plugin's minimum PHP version is increased, if the server is running to low of a version. Ideally the update would still be shown to the user, but they would be shown an error message and wouldn't be able to install the update. I implemented something similar to this in a plugin in anticipation of upping the required version: https://github.com/WordPoints/wordpoints/issues/623

#8 in reply to: ↑ 7 @joostdevalk
6 weeks ago

Replying to jdgrimes:

Another thing not mentioned: updates should be disabled when a plugin's minimum PHP version is increased, if the server is running to low of a version. Ideally the update would still be shown to the user, but they would be shown an error message and wouldn't be able to install the update. I implemented something similar to this in a plugin in anticipation of upping the required version: https://github.com/WordPoints/wordpoints/issues/623

good addition, thanks!

#9 in reply to: ↑ 4 ; follow-up: @blobfolio
6 weeks ago

First of all, YES!

But...

Replying to johnbillion:

the only way this will happen is if supporting documentation comes first. Everything else comes down to relatively trivial technical implementation.

I wouldn't underestimate the size of this task. Even if we ignore plugin author and user awareness (and documentation), we'd still be looking at patches to at least three different areas: the WP.org API, plugins frontend, and the Core itself. The API and Core work would both be "delicate" in that any failure or oversight could result in sites blowing up. Plugin and environment parsing would need to be robust enough to survive the odd typo or obscure version string. :)

@joostdevalk Beyond a main PHP version, I think it would also be necessary to support extension requirements. Compatibility issues faced by my plugins are as often to be found there as the main version. Naming could get a bit tricky, so maybe it would be best to adopt the same approach Composer uses https://getcomposer.org/doc/01-basic-usage.md#platform-packages; people should be pretty familiar with that.

I would also suggest that any approach needs to take care of upgrades. Attempting to install an incompatible plugin isn't the end of the world, and in that narrow case plugin authors can basically compensate for WP's lack of innate handling. But upgrades, man, those are killer. There's currently no mechanism to revert to a known-working version, etc.

#10 in reply to: ↑ 9 ; follow-up: @joostdevalk
6 weeks ago

Replying to blobfolio:

@joostdevalk Beyond a main PHP version, I think it would also be necessary to support extension requirements. Compatibility issues faced by my plugins are as often to be found there as the main version. Naming could get a bit tricky, so maybe it would be best to adopt the same approach Composer uses https://getcomposer.org/doc/01-basic-usage.md#platform-packages; people should be pretty familiar with that.

Because I wanted to keep this thread readable, I've kept that bit out. I had thought about that, but am not sure if we want to go there immediately as it considerably grows the task at hand. At the same time, I can see why a plugin would require a specific minimum MySQL version for instance, so we should at least build this with future extensibility in mind.

#11 in reply to: ↑ 4 ; follow-up: @pbiron
6 weeks ago

Replying to johnbillion:

If the WordPress project is to allow plugins or themes to specify a minimum PHP version, and indeed if core itself is to consider increasing its own minimum PHP version, the only way this will happen is if supporting documentation comes first. Everything else comes down to relatively trivial technical implementation.

I'm agnostic as to whether the documentation must come first.

But part of that documentation should be directed at plugin/theme authors in an attempt to educate them how to determine what the "minimum PHP version" for their plugin/theme is.

I say this because I honestly couldn't tell you what the "minimum PHP version" are for any of the plugins/themes I've written. All I know is that I've tested them with a particular version of PHP.

This should include pointers to the various "Migrating from PHP X to PHP Y" appendices in the PHP Manual (e.g., Migrating from PHP 5.4.x to 5.5.x). In fact, I didn't even realize those appendices existed until I saw this ticket and asked myself how I would I know what the "minimum PHP version" for plugin X is.

#12 in reply to: ↑ 10 @blobfolio
6 weeks ago

Replying to joostdevalk:

Because I wanted to keep this thread readable, I've kept that bit out. I had thought about that, but am not sure if we want to go there immediately as it considerably grows the task at hand. At the same time, I can see why a plugin would require a specific minimum MySQL version for instance, so we should at least build this with future extensibility in mind.

Haha, yeah, I didn't mention MySQL or OS or Server (e.g. Nginx, Apache, etc.) for that same reason. :) Those three things start getting difficult to test for and probably wouldn't be worth it at the outset.

PHP extensions, at least, work the same as PHP itself... good ol' phpversion($extension).

Replying to @jdgrimes

Another thing not mentioned: updates should be disabled when a plugin's minimum PHP version is increased, if the server is running to low of a version.

Agreed, that is the path of least terrible. But dropping support could potentially leave users vulnerable to security issues indefinitely, so there would also need to be a prominent admin notice, probably also an email notification, informing the site owners of the change. Users don't ever pay attention to updates, let alone the accompanying upgrade notice text, so it needs to be BIG and ANNOYING. Haha.

#13 in reply to: ↑ 11 @blobfolio
6 weeks ago

Replying to pbiron:

how I would I know what the "minimum PHP version" for plugin X is.

http://php5.laurent-laville.org/compatinfo/ is a good start. :)

#14 follow-ups: @johnbillion
6 weeks ago

I'd like to see a bit of a stronger argument put forward for a PHP version constraint. Not because I am against it (I'm not), but because it's important that we qualify time and effort spent on it and fully consider the impact on end users.

WordPress traditionally avoids (to a significant degree in some cases) exposing the end user to concerns regarding things such as PHP version, PHP extensions, server requirements, etc. It takes this to the extreme in some cases, providing shims when certain extensions aren't available (the mb_*() functions), and running with very low requirements (PHP 5.2).

Maybe this needs to change, or maybe this is foundational to WordPress and the reason for its success. Maybe it's less relevant or less important now than it has been over the last 14 years. Maybe not, maybe partly. This commitment to minimal requirements and backwards compatibility needs to be considered.

If we are going to consider exposing the user to a PHP version constraint, it's important to qualify it with the benefits that it provides. In a world of microservices, packages, and dependency management, this is routine stuff, but WordPress doesn't operate in this world. I'd like to see a document put together which answers:

  • What are the real benefits to plugin and theme authors of a PHP version constraint mechanism?
  • What problems are caused by lack thereof?
  • What are the benefits, if any, to end users?
  • What are the benefits, if any, to WordPress core or the wider WordPress ecosystem?

The answers will all be subjective of course, but they'll help guide us with regard to prioritisation and implementation. This may seem like overthinking things, but supporting a PHP version constraint for plugins and themes introduces a fundamental change to the way WordPress is used.

This ticket was mentioned in Slack in #core by johnbillion. View the logs.


6 weeks ago

#16 in reply to: ↑ 14 @jdgrimes
6 weeks ago

Replying to johnbillion:

If we are going to consider exposing the user to a PHP version constraint, it's important to qualify it with the benefits that it provides. In a world of microservices, packages, and dependency management, this is routine stuff, but WordPress doesn't operate in this world. I'd like to see a document put together which answers:

  • What are the real benefits to plugin and theme authors of a PHP version constraint mechanism?
  • What problems are caused by lack thereof?
  • What are the benefits, if any, to end users?
  • What are the benefits, if any, to WordPress core or the wider WordPress ecosystem?

The answers will all be subjective of course, but they'll help guide us with regard to prioritisation and implementation. This may seem like overthinking things, but supporting a PHP version constraint for plugins and themes introduces a fundamental change to the way WordPress is used.

I agree.

Here is an answer to the first two questions from my perspective as a plugin developer.

I know that usually when it comes to talk of PHP versions, the first thing that will be said is that "we can really do everything that we need to in PHP 5.2." There's truth in this, and as such in real life I find that the features offered by newer versions aren't what has pushed me to decide to drop support. It is really a question of maintenance burden. In other words, the features of new versions aren't very important (to me, at least), it is the bugs and other issues that arise from old ones.

And really, it has little to do with the quirks of any particular version. It isn't so much about PHP 5.2 (or 5.3, or any other version) as it is about the burden of supporting 7+ different versions of PHP, each of which has quirks. Ensuring compatibility of a plugin with each supported WordPress version and each supported PHP version adds up.

And it becomes frustrating that more and more time is spent supporting a legacy version of PHP that increasingly few users are actually using. It is time that could be put to the benefit of all users by building new features, instead of going down the drain just for 3%.

This is what has compelled me to consider requiring a different minimum version than WordPress, something that I would really like to avoid. It is just in the best interest of users and developers alike.

(I'm certainly not alone in this, many other plugin developers, especially those who take testing compatibility seriously are feeling much the same way.)

Of course, I am welcome to do this without any action on core's part though. So what are the problems that handling this in core would solve?

First, from the user perspective, it would give the user a much more consistent experience. More and more plugins are going to begin doing this, and not all of them are going to put the same amount of effort into making it a positive (if possible) experience for users. This effort will also be duplicative, wasting yet more time that could be put to much better use. So for the optimal user experience, the community coming together around this issue as a whole is best.

From a developer side of that, the problems that are caused by a lack of core support for this is that it is more difficult for a developer to communicate this constraint to the user effectively. It is also means more work to prevent them from installing the plugin when it won't work, and especially to prevent them from updating to the version that is dropping support for their version of PHP (which if they did, it would mean the plugin would suddenly cease to function; not a good UX).

And does this have benefits for the wider WordPress ecosystem as a whole? I think it does. Most of us have probably spent time (you and I in the last week, I think) struggling with issues tied to various PHP versions, particularly 5.2. The more versions we support, the more time is spent on this. It is significant enough that as a community we are able to do less actually useful stuff because of it. We are continually putting more time into this, with less and less return (as it is benefiting fewer and fewer users). At some point, we all agree that it is no longer worth it. That time may come at a different pace for different plugins, and at a different pace for many plugins than for core. It depends on how many people are on a team, and how many users on certain PHP versions there are. It is a decision that people are already making. Plugin devs are already confronting users with this, like it or not, and there is nothing that we can do about it (unless we make that against the plugin directory guidelines). In my opinion, the best UX is going to result from core support. Perhaps we're not quite to the place where the benefits outweigh the costs, but it is clear that many plugin devs believe, that for them at least, we are already far past.

#17 in reply to: ↑ 14 @jb510
6 weeks ago

I think it's a forgone conclusion this should have happened long ago... but I agree it needs to be as user-friendly as possible. People running WordPress necessarily have a web host or enough technical skill to set one up on their own. They are not without resources to help them upgrade PHP versions.

Replying to johnbillion:

  • What are the real benefits to plugin and theme authors of a PHP version constraint mechanism?
  • What problems are caused by lack thereof?
  • What are the benefits, if any, to end users?
  • What are the benefits, if any, to WordPress core or the wider WordPress ecosystem?

I agree these answer can definitely help inform implementation.

I think the benefits to plugin and theme authors is pretty minimal actually. Sure it'd make development easier not having to think about multi-version support, but we can pretty easily put a version check in at activation and updates.

I think the "real" benefits are to users:
a) Users will be less likely to white screen their sites when installing/activating P/Ts
b) Users will become familiar with a standardized experience of dealing with this issue that has good standardized support documentation (as opposed to now seeing upgrade notices phrased 3 different ways by 3 different plugins with inconsistent documentation and support across them).

I will say that I do think there should be a "tested up to" flag to bring things in line with the reporting on core version. ie. min version PHP 5.6 tested up to 7.0.

It is useful for site owner to know the plugins they have installed have already been tested up to 7. There are still a lot of old plugins do break on 7 and while WP Engine's Compat testing is good, I think asking users to use that plugin is asking too much, it'd be better experience for them if they could just read a line of text that says "tested up to 7.0". (Obviously, the top end wouldn't be a hard fail the way the bottom end would be)

#18 @pento
6 weeks ago

#23880 was marked as a duplicate.

#19 follow-up: @pento
6 weeks ago

  • Component changed from Administration to Plugins
  • Focuses ui administration added
  • Owner set to joostdevalk
  • Status changed from new to assigned
  • Type changed from enhancement to task (blessed)

Several years ago, I was strongly against this kind of change, but I've more recently been convinced of its merits.

As far as the technical aspects go, I don't think there's much disagreement - it's relatively simple to implement (4.9 should be an easy target).

The far harder problems here, as @johnbillion mentioned, are the people problems. How do we explain to site owners what's going on, and what they need to do to fix it? Historically, we've written these problems off as being too hard - we didn't have the resources to document how to fix it, and previous attempts (see: the abysmal failure of GoPHP5's effort to make a dent in PHP4 usage) were unsuccessful.

Over the past several years, there have three changes in the WordPress world that changed my mind on this.

  • Reframing the discussion. This has always been discussed as "how to get Core using a newer PHP", plugins have always taken a back seat. Focussing on plugins allows us to think of it as less of a "breaking back compat" issue, and more of a "graceful degradation" issue - if a feature (in this case, a plugin) doesn't work in your version of PHP, you simply don't get to use it, though your site will happily continue running if you choose to do nothing.
  • The hosting community. The relatively newly formed hosting community gives us a much stronger link to interested hosts than we've previously had. Historically, host discussions have happened through ad-hoc pinging of contacts, which is wildly unreliable. With hosting input on this, it should be much easier to hook into host-specific upgrade information. If we can detect the host (or the host automatically installs a plugin to alter the appropriate filters), then we can link directly to host documentation, giving the user the most accurate information for their scenario. Indeed, it would potentially be possible to perform the upgrade from within wp-admin, if the host provided the necessary command to run.
  • The documentation and translation community. Where we don't have host-specific information, we will need documentation for everyone else. Historically, both the documentation and translation teams have been overworked and understaffed, but they've been making great strides over the last couple of years. Co-ordinating this kind of documentation effort is well within our capabilities at this point.

As a bonus, we also have a bunch of prior learning that the Yoast team can provide, through their experiments with encouraging upgrades.

As far as benefits go, I don't think anything has changed from earlier discussions, but I'll list them as I see them.

  • Performance. No-one argues that newer PHP versions are much faster, particularly from 7.0 onwards. Upgrading PHP gives us a faster internet, and a better experience for everyone.
  • Security. While many hosts backport security fixes to their internally maintained PHP versions, there are plenty that don't. A more secure web is always a benefit.
  • Improved WordPress Developer Experience. Getting started with developing for WordPress is easy, in part because we really only use coding practices from 10 or more years ago. This has been both a strength and a weakness for WordPress - it's easy to get started, but it's hard (it could even be interpreted as officially discouraged) to advance to modern practices, which risks alienating a new generation of developers with no interest in maintaining 14+ year old code. This is a balance, but it feels like the balance has tipped too far in the wrong direction.
  • Setting a direction for Core. The things we learn from allowing plugins to set a minimum PHP version will inevitably influence how we choose to bump Core's minimum PHP version. Bumping Core's PHP version is a much bigger problem, but taking this first step will help us get there.

Ultimately, the current strategy of "wait for PHP usage to naturally evolve" is working, albeit very slowly. If this doesn't work, we can fall back on how it was before. But, done correctly, I don't believe this project can harm WordPress, so the worst case is "nothing changes", and we can go back to the drawing board. The best case is that we get a good bump in PHP usage, and a way forward for Core's PHP version, too.

@joostdevalk: I assume you're interested in leading this effort? If that's the case, consider it "blessed". :-)

Also, do you have any data on the effectiveness of the Yoast campaign? That would be interesting to see.

#20 @blobfolio
6 weeks ago

  • Component changed from Plugins to Administration
  • Focuses ui administration removed
  • Type changed from task (blessed) to enhancement

I, for one, am not comfortable supporting versions of PHP that have reached End of Life. If software dependencies aren't receiving security patches, the software running on top of it isn't safe either. I do it, but only because WordPress provides no safe mechanism for allowing its hosted plugins to advance (in the way that virtually all other software is able to).

In a word, "security". PHP 5.2 was released more than 10 years ago. In tech years, that's older than most religions. The security problems technologies released a decade ago were built to defend against are laughable today. WordPress still supports single MD5 password hashes. Haha.

And I get that there's an opposing philosophy, "Technology should be available to as many people as possible." That isn't wrong, but as a plugin author, that is something I like to help augment. "The base technology works for everyone, but if you can swing it, this will keep you safer."

As-is, the WordPress plugin ecosystem is dangerous. WordPress has no ability to resolve conflicts prior to executing the full install/upgrade routines, takes no pre/post snapshots, maintains no history, gives users no innate ability to manage version control. Each update is a game of Russian Roulette, particularly for casual blog authors who aren't familiar with the underlying tech and don't realize that their servers are at best inadequate.

"Why?"

I recently came to a difficult decision for one of my plugins upon discovering certain innate security limitations in the minimum requirements I had set forth years earlier (long since resolved by subsequent PHP releases). My choice was to either progressively address the issue, leaving a subset of users vulnerable, or bump the requirement, alienating that same subset of users. I wasn't willing to risk exploding their sites, and since WordPress provided no framework (not even a proper upgrade hook), here is what I had to do:

  1. Push and tag an intermediate release that A) presents an admin notice warning users if their system won't support future releases (and, btw, it is not safe to keep using this... update or find an alternative) and B) suppresses update notifications in such cases. I released this before work began on the rewrite, a good month ahead of time, but couldn't rely on users actually installing it (very few people apply regular updates), so...
  1. Release a new version that includes a red pill/blue pill index file, either loading the real plugin code a fallback. The fallback version produces a notice and either A) deactivates the plugin (if a new install) or B) hijacks the upgrade feature to turn it into a downgrade feature (using an artificially inflated version number and a link to the tagged legacy release). The fallback also has to supply semi-functional userspace functions so that themes referencing them wouldn't explode, but since the relevant codebase isn't loaded, these instead submit notices via email to the site administrator alerting them to the problem, just in case they didn't see the wp-admin notices.

It ended up being an insane hoop, and very difficult to adequately test. At the time I thought, "Boy, wouldn't it be swell if WP had basic PHP/extension requirements baked into the API?" Haha.

#21 @pento
6 weeks ago

  • Component changed from Administration to Plugins
  • Focuses ui administration added
  • Type changed from enhancement to task (blessed)

#22 in reply to: ↑ 19 @joostdevalk
6 weeks ago

@joostdevalk: I assume you're interested in leading this effort? If that's the case, consider it "blessed". :-)

Yes! Thank you. I'll get started.

Also, do you have any data on the effectiveness of the Yoast campaign? That would be interesting to see.

I have some data, to be found here:

https://docs.google.com/spreadsheets/d/176WrzJ_66tL7aFRfJHnqdmgxfD7B8N2CwE2K0DvNmOg/edit?usp=sharing

I've asked @dd32 to run the numbers again, but haven't had a response to that request yet. Maybe someone else with .org access can run those?

This ticket was mentioned in Slack in #meta by joostdevalk. View the logs.


6 weeks ago

This ticket was mentioned in Slack in #hosting-community by pento. View the logs.


6 weeks ago

#25 follow-up: @pento
6 weeks ago

Here are the current numbers, limited to Yoast SEO versions 4.5-4.9:

PHP Version Percent of Yoast SEO installs
5.2 1.1%
5.3 6.2%
5.4 16.1%
5.5 10.7%
5.6 46.7%
7.0 16.8%
7.1 2.3%

Fun side note: there's exactly 1 site using a recent Yoast SEO version on PHP 4.3. :-)

#26 @Ipstenu
6 weeks ago

RE Pento's comment on an 'upgrade now!' button...

Given that every single host is going to have a different process for updating, I would think a standard URL like rednightmaremomma.com/wordpress-upgrade-php that everyone can use and redirect as needed may be the best choice in the long run. That would allow the hosts who aren't really actively involved to jump on board and redirect people based on the URL they came from, if they're logged in to cpanel/whatever already, and so on. Even if it just redirects them to a static page that says "To upgrade PHP, please open a ticket..." it means we don't have to update CORE to add in new hosts.

#27 @hedgefield
6 weeks ago

Hey all, I've worked on some mockups for the changes @joostdevalk proposed. I've almost exclusively used existing UI elements to append certain areas in the backend and plugin directory with the info/warnings about compatible PHP versions. Images below:

@hedgefield
6 weeks ago

Incompatible plugins cannot be installed and show up red in the overview. Used the WP colors #FBEAEA for the background and #DC3232 for the button.

@hedgefield
6 weeks ago

Incompatible plugins cannot be installed and show up red in the overview. Used the WP colors #FBEAEA for the background and #DC3232 for the button.

@hedgefield
6 weeks ago

The statistics in the plugin directory show the required PHP version

@hedgefield
6 weeks ago

The plugin directory page in the backend can show a warning if the detected PHP version is too low, and the install button is red here too. I didn't edit the statistics in this one because it's still using the old plugin directory theme (see #40971)

@hedgefield
6 weeks ago

The plugin directory stats page with a table that shows PHP usage per user. I made up the numbers at random before I saw @pento's comment, so ignore those, they're for illustrative purposes ;)

#28 in reply to: ↑ 25 @joostdevalk
6 weeks ago

Replying to pento:

Here are the current numbers, limited to Yoast SEO versions 4.5-4.9:

PHP Version Percent of Yoast SEO installs
5.2 1.1%
5.3 6.2%
5.4 16.1%
5.5 10.7%
5.6 46.7%
7.0 16.8%
7.1 2.3%

Fun side note: there's exactly 1 site using a recent Yoast SEO version on PHP 4.3. :-)

Thanks for those numbers @pento! I've updated the spreadsheet:

https://docs.google.com/spreadsheets/d/176WrzJ_66tL7aFRfJHnqdmgxfD7B8N2CwE2K0DvNmOg/edit?usp=sharing

As you can see, it works.

#29 @joyously
6 weeks ago

I'm proposing to allow plugins and themes to have a minimum PHP version requirement. Not a maximum, just a minimum.

Looking at this from a user perspective, I need a Tested Up To version number more than a minimum. I'm actually looking at upgrading several client sites, but I have no idea if those sites will still work if I jump to PHP 7 or if I need to choose PHP 5.6. I spent a lot of yesterday reading the PHP release notes to see the actual differences, and there are quite a few. Each of my client sites has a different set of plugins. Without the Tested value, I would end up being a plugin tester. And how can I do a thorough job of that? And I am not the typical user, who would not know any of this. A typical user would trust the WordPress message to upgrade PHP, and have a site that no longer works, with no good way to determine why.

#30 @joyously
6 weeks ago

For the mockup of the "disabled" plugin, I don't think it should be red. I think it should be more like other things that are "disabled", which is gray or reduced opacity, instead of drawing attention to something you can't use.

And I think the messaging would be a little different for plugins that are not tested up the version that is on the site, but it should also look "disabled".

@hedgefield
5 weeks ago

Rather than not showing the incompatible plugins in the Updates page at all or splitting it out somehow (you wouldn't be able to use the selection box because you wouldn't be allowed to update it), I put a message above the list to indicate there are plugins that cannot be updated.

@hedgefield
5 weeks ago

I updated the More Details modal with the new plugin directory theme, made the PHP warning more fierce (because it's not a warning) and added more messaging next to the button, which I changed into a label, because it shouldn't be clickable.

@hedgefield
5 weeks ago

And an alternative take on the Add Plugins page without the red tint and the button turned into a label. I used the compatibility check in the card's footer to put the PHP warning, since it doesn't matter if the plugin is compatible with Wordpress if it's not compatible with your PHP.

#31 @stevejburge
4 weeks ago

I'm not sure if this research has been done, but just in case ... other platforms are already doing this in core.

The next version of Drupal will likely ship with a message recommending you update to at least 5.6 https://www.drupal.org/node/2670966

Joomla has a core message recommending 7 https://image.ibb.co/gFa8MQ/wwww.png

#32 @joostdevalk
4 weeks ago

Thanks for letting us know @stevejburge! That certainly came up on the community summit too, we were looking at doing something similar.

This ticket was mentioned in Slack in #core-php by joostdevalk. View the logs.


3 weeks ago

#34 @joostdevalk
3 weeks ago

Related, for those interested: #41191

This ticket was mentioned in Slack in #core-php by desrosj. View the logs.


3 weeks ago

#36 follow-up: @jrf
2 weeks ago

Probably not a surprise to anyone who knows me, but I'm all for this!

It's also been discussed for the TGM Plugin Activation library as a potential addition for the 3.0 version, so getting this supported by core would be great!

I noticed the WP Engine PHP 7 Compatibility checker plugin has been mentioned already and while interesting, it is very much aimed at PHP 7+ and obviously not something for end-users who hardly know what PHP is.

What some people may not realize however, is that the plugin is but a thin shell around (an out of date version of) the PHPCompatibility sniff library for PHPCS which can test for compatibility with a range of PHP versions and contains checks for PHP cross-version compatibility for PHP 5.0 all the way up to PHP nightly.
It is actively being maintained (me being one of the maintainers) and contributions as well as bug reports or feature requests are very welcome.

It might be worth thinking about potentially creating an automated work-flow where commits to the plugin repository - or probably better: tagged releases at the moment of tagging - are checked for compatibility with minor PHP versions to determine what the minimum PHP version should be.

The tool will yield some false positives for code typically used to provide backward-compatibility for older PHP versions, but I imagine we can figure out a solution to that.

#37 @joyously
2 weeks ago

It might be worth thinking about potentially creating an automated work-flow where commits to the plugin repository - or probably better: tagged releases at the moment of tagging - are checked for compatibility with minor PHP versions to determine what the minimum PHP version should be.

That sounds awesome! It would be much better than an author-supplied number. But even if it was an offline tool that the plugin author could use to populate the field, it would be better than the author trying to figure it out.
And I would hope it would be a min and max.

#38 in reply to: ↑ 36 @netweb
2 weeks ago

Replying to jrf:

It might be worth thinking about potentially creating an automated work-flow where commits to the plugin repository - or probably better: tagged releases at the moment of tagging - are checked for compatibility with minor PHP versions to determine what the minimum PHP version should be.

There is already a SVN hook for plugins.svn.w.org that runs some basic PHP Lint checks, I believe one of those checks relates to PHP 7, @otto42, could you shed some more light on what is, or isn't checked by the SVN hook please?

#39 @Otto42
2 weeks ago

AFAIK,the pre-commit hook only runs the PHP 7 lint check right now. Nothing else.

This ticket was mentioned in Slack in #core-php by flixos90. View the logs.


10 days ago

#41 @joyously
9 days ago

I've been going through the motions of this manually, because I have several client sites that I need to move to a new host. So I ran the PHP Compatibility plugin targeting PHP 7 on each site, and they each have several plugins that have warnings for PHP 7 and some with errors for PHP 7. I think this will be a typical scenario, because plugins that are no longer supported or just haven't had updates show no indication of that in the plugin list. I was unable to get to some of the plugin's pages on wordpress.org because older plugins have a different URL (with /extend/ in it), and the plugin search will not show plugins older than 2 years. I think this is a bad user experience all around. All I wanted was to get to each plugin's support forum, but I had difficulty doing that with older plugins (which work fine, but haven't been updated -most don't need it). Just to note: I posted the results to about 25 plugin support forums yesterday (this is from 8 sites), and already received replies saying "that error is not a problem", "I'll fix it later", "thanks, but busy". Plugin authors will need incentive to do something...

Creating new fields in the readme for PHP version won't help with the older, unchanged plugins. Would there need to be something done for the ones that do not update to supply a value?

Anyway, if I had been a non-technical user and seen the WP message that I should update to PHP 7 and followed it blindly, I would have ended up with errors I wouldn't know how to fix, caused by plugins that I can't find the plugin pages for.
One of the plugins was interesting, because when I searched for it, it did not show, but a similar plugin did (mentioned the older plugin name). The author coded a nice transition from the old to the new (read the old one's settings and disabled that value in old plugin but old plugin was still active). I was able to switch to newer with no hassle at all.

I didn't see it on the attachments, but wouldn't it make sense to show the user the PHP version that the site is currently running, somewhere on the plugin page? I wouldn't want it to be hard to find, like the current WP version is.

#42 follow-up: @Ipstenu
9 days ago

I was unable to get to some of the plugin's pages on wordpress.org because older plugins have a different URL (with /extend/ in it), and the plugin search will not show plugins older than 2 years.

Those URLs should still redirect (https://wordpress.org/extend/plugins/akismet/ does at least)

That sounds like the compatibility plugin has a glitch.

Creating new fields in the readme for PHP version won't help with the older, unchanged plugins. Would there need to be something done for the ones that do not update to supply a value?

True, but that, like the 'tested up to' field, is a value used to determine a plugin's worth anyway. If a plugin doesn't have it, and hasn't been updated in 2+ years, use at your own risk.

but wouldn't it make sense to show the user the PHP version that the site is currently running, somewhere on the plugin page? I wouldn't want it to be hard to find, like the current WP version is.

That would be nice to have in the footer of WP?

WP 4.8 | PHP 7.1 | MySQL 5.6

#43 in reply to: ↑ 42 @pbiron
9 days ago

Replying to Ipstenu:

but wouldn't it make sense to show the user the PHP version that the site is currently running, somewhere on the plugin page? I wouldn't want it to be hard to find, like the current WP version is.

That would be nice to have in the footer of WP?

WP 4.8 | PHP 7.1 | MySQL 5.6

+1 to this!

#44 @blobfolio
9 days ago

I might be thinking about this the wrong way, but as I see it, the main benefit of allowing plugins to set their own minimum PHP requirements is just that: letting the plugins do it.

Code compatibility analyzers are useful and all, but the technology can't be run without human oversight. Ultimately, they're just looking at files in a bubble. The only way to know for sure is to view it in context by, e.g., running it.

The most common problem with code analyzers is that they'll end up returning inflated requirements because code flows aren't always apparent out of context. For example, the WordPress core will use hash_equals() when it can (a progressive security enhancement), but that function wasn't introduced until PHP5.6. In fact, running phpcompatinfo against the current WP trunk turns up 7.0.2 as the minimum version for me, which isn't quite right. Haha.

But wait, there's more! PHP releases don't just differ in terms of markup, functions, plugins, etc. They also differ in behavior. How can an unmonitored code analyzer guess at the author's intent?

For one, this means considering every system function that has had its behavior changed somewhere down the line (in a compatibility-breaking way, at least). As a plugin author, I might choose to require PHP5.3 because fnmatch() started having better Windows support at that time. That particular function exists as far back as PHP4, but for my hypothetical purposes, didn't do what I wanted until PHP5.3.

There are also fun issues like PHP7's ability to support scalar hinting in function declarations (e.g. function foo(string $bar){ ... }). When run on PHP7, the value passed as $bar will be cast as a string (or die trying). But when run on versions prior to PHP7, that same code will be expecting $bar to be an object belonging to the custom class \string.

Given all that, I would be hesitant to incorporate automated compatibility scanning at all, for any purpose, even as a fallback for plugins that don't assert their own details. All that accidental inflation would make the plugin repo a lonely place for granddaddy PHPs.

TL;DR
This is an excellent enhancement proposal, but one which I think only really applies to developers who are conscious about this sort of thing. Any attempt to get this executed without human participation is going to have consequences and possibly result in an overall worse UX for many site operators.

#45 in reply to: ↑ description @SergeyBiryukov
8 days ago

Replying to joostdevalk:

Meta

  • Plugin readme parser changes for minimum PHP version requirement.
  • Plugins API changes.

Plugin directory

  • Show minimum required PHP version on plugins page. Mockups required.
  • (Optional) Allow filtering plugin directory. Mockups required.
  • (Optional) Report PHP version usage per plugin’s users. Mockups required.

Created #meta2952 for the first three points.

This ticket was mentioned in Slack in #meta by sergey. View the logs.


8 days ago

#47 @Ipstenu
8 days ago

Related to #18821

1) The modal 'details' should list warnings for 'not supported/tested on your version of PHP'
2) We should consider alerts on the plugin listing for this (and for not tested on your version of WP, and for not updated)

Basically we should be alerting users as early and clearly as possible that there may be dragons.

This ticket was mentioned in Slack in #core-php by jdgrimes. View the logs.


3 days ago

Note: See TracTickets for help on using tickets.