Block plugin updates if required PHP version is not supported - Plugins screen

[schlessera]

Note: This ticket is a subtask for the overarching #40934 ticket.

When a plugin states it requires a specific minimum PHP version through its "Requires PHP" header information and the server does not support this PHP version, WordPress should block any possibility to update the plugin. This way, plugins will stay at the latest release that still supports the server's PHP version.

Some initial observations:

• The plugin infrastructure might need to be changed to allow querying for "the latest release that still supports a given PHP version".
• Plugin authors should have a way to push security updates for older releases prior to a PHP version bump, to not leave sites behind on vulnerable plugin versions.

This ticket's goal is to prevent plugin updates from the "Plugins" admin screen. With that, it complements #44350, which deals with preventing plugins from the general "Updates" admin screen.

[schlessera]

Mockup by @hedgefield: 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.

[afragen]

A new filter would be required to display the notice in that particular location, otherwise it displays at the top as an admin notice.

[afragen]

The above patch is an initial pass.

It also address the plugins.php page by hiding the plugin row update message and adding a link element with an indication of an update.

It could be improved by having the ability to remove the update class from the parent row. This would show the bottom border.

[afragen]

Update notice to use 'newer' not 'higher'

[afragen]

Adds jQuery removal of update class so bottom row border displays

[afragen]

Use jQuery to remove update row instead of using CSS and display:none to hide

[afragen]

Latest screenshot

[afragen]

Latest screenshot

[afragen]

This patch removes the extra stuff from the plugin action links and adds it to the bottom of the plugin card via a new action hook.

[afragen]

Oops, attached to wrong trac ticket.

[afragen]

Adds required PHP version info to nag on plugins.php

[afragen]

Shows nag with required PHP version

[schlessera]

@afragen I think some of the naming is awkward, as you refer to the name of the plugin meta key 'requires php'.

As an example, the method load_requires_php() is grammatically weird, as it reads differently than it is intended: "something we want to load does require PHP" or something...

I suggest adapting the naming to make the purpose clear, regardless of what the index key is called, like enforce_php_requirement() or similar.

[afragen]

@schlessera thanks for the feedback!

I can certainly rename the function as suggested. I’m also hoping for some guidance regarding the phrase we should be using in the notice.

[SergeyBiryukov]

I think this should be handled on the API level, like the WordPress version check.

The API currently checks the requires header and only serves updates to WordPress versions that support them. If the author bumps the header, older WP versions won't get the update. It should do the same for requires_php header, which would need a Meta Trac ticket.

This would not prevent plugin authors from being able to release security updates, which was an initial concern here.

If plugin versions 1.x and 2.x have different PHP or WordPress requirements, the author can release both 1.x.y and 2.x.z, and the API would serve them appropriately to the sites meeting the requirements.

If the goal is not just to block updates to incompatible versions, but also to give users an incentive to upgrade PHP, then some UI changes in core might be needed. The patches seem like a good start, would need design feedback though. Perhaps we'd want to handle WordPress version checks in a similar way, for consistent experience and as an incentive to update WordPress to the latest version?

Apparently the updates endpoint, unlike query_plugins, does not currently return the requires_php header. That should be added first to avoid introducing multiple external requests.

[afragen]

changed function name as suggested ;)

[schlessera]

Added Meta trac ticket for adding "Requires PHP" information to Update API endpint: ​https://meta.trac.wordpress.org/ticket/3642

[joyously]

It is my hope that decisions on the user interface keep in mind what the user is doing when this Install plugin button is disabled. This really only affects those sites with a lower version of PHP than the plugin has. But there could be plugins that are on the bleeding edge oh PHP that the user is not interested in.

The first step in upgrading PHP (beyond understanding the concepts) is to determine if the plugins and theme will work on the new version. For this, the user needs to see the numbers because he's looking before the upgrade. The user has to choose plugins that will work with a different version than his current version. Then he has to upgrade, and then he has to switch to those plugins he found. (Or install the plugins, but not activate yet.)

Perhaps instead of disabling the install button, we should be disabling activation only.

Ooops, I think I put this on the wrong ticket, but it sort of applies to this one also. The user could have installed a plugin in preparation for a PHP upgrade, and wants the latest version, but the plugin might not be activated yet.

[afragen]

hard-coded version, more in line with WP core

[afragen]

View from plugins.php

[afragen]

View from update-core.php page.

[afragen]

Given the feedback on the patch for #43986, I've revised this patch to be more hard coded.

Here's the patch 43987v2.diff​

The above image shows the plugins.php page. In this view the Caldera Forms plugin has an update available. I used some standard information and link to the ServeHappy page.

The above image shows the update-core.php page. The changes show the plugin but the checkbox has been removed preventing the ability to update the plugin and a message has been placed in the compatibility section. Again the link points to the ServeHappy page.

[afragen]

feedback applied

[afragen]

43987v3.2.diff​ with latest feedback incorporated.

Given discussion on Slack, ​https://wordpress.slack.com/archives/C60K3MP2Q/p1528738663000512
there is no checking for WP version as the API takes care of that already.

The following is a view of the plugins.php page.

The patch creates the Cannot Update button in the View version %s details, but does not add the notice as this is added by #43986

[earnjam]

There is one thing ​I brought up in Slack, but wanted to post either here or on #44350. If this solution is implemented, we'll have an inconsistency between how we handle blocking updates for plugins when their PHP version is incompatible vs when their WordPress version is incompatible.

If the WP version is too low, we just don't show that there is an update to the plugin available at all.

According to these mock-ups, if the PHP version is too low, we'll let users know there is an update, but prevent it from happening and display an error message explaining why.

Should we be bringing those two things in line with each other? If the reason for showing the error message for the PHP version incompatibility is to encourage users to update, wouldn't showing the error for a WordPress version incompatibility do the same?

[afragen]

@earnjam my guess is that this inconsistency happens because .org prevents the updates from showing. You might try a trac ticket on meta to see if there is need/desire to change this behavior.

If the behavior from .org changes it would be relatively simple to adjust core in a similar manner to #43968, #43987, and #44350.

Also, I'm not so certain as to the inconsistency. It's simple enough at that point for the user to update WP. Not so simple to update PHP, and they might need help. The notice that there's an update available, hopefully, encourages them to upgrade PHP.

[afragen]

change More Details button to 'Cannot Update'

[afragen]

Cannot Update button

[afragen]

changed all messaging text from 'upgrading' to 'updating'

[afragen]

added some escaping where needed

[afragen]

@schlessera @flixos90 should this be milestone 4.9.9?

[afragen]

Probably need to milestone this for 5.1

[afragen]

Update patch for update-php link

[afragen]

Removes checkbox from plugins.php page if incompatible PHP version

[afragen]

screenshot showing checkbox gone

[afragen]

43987v4.1.diff​ updated for post WP5.0 merge into trunk and update-php link. Also added the removal of the checkbox from the plugin list on the plugins.php so it matches update-core.php from #44350

[afragen]

fixed version_compare so 5.1.10 is greater than 5.1.2

[afragen]

We probably need to change milestone to 5.2

[afragen]

updated patch

[afragen]

updated screenshot for 43987.14.diff with web host update PHP link added

[afragen]

I've updated the patch 43987.14.diff​.

The screenshot is what happens when the web host provides it's own link to Update PHP.

I don't know why there's an extra empty paragraph tag. It's not added in the patch.

[desrosj]

43987.2.diff​ removes the esc_attr() wrappers for $plugin_name that were added. $plugin_name is passed through wp_kses() further up to strip out harmful markup, and the parts of the string being output in attributes are already escaping. Passing $response->new_version through esc_attr() seems ok, though.

I think we can improve how the annotation is displayed a bit, but this looks good for beta.

[desrosj]

In 44937:

Plugins: Block plugin updates if required PHP version is not supported.

When a plugin states it requires a specific minimum PHP version (as defined in the requires_php field included in the plugin update API response), a user should not be allowed to update that plugin when the server does not satisfy the minimum PHP version.

When this scenario is encountered, the update buttons and links are disabled and links to educational resources about PHP are displayed to the user with a notice.

Props afragen, schlessera, desrosj.
Fixes #43987.

[SergeyBiryukov]

In 44980:

Plugins: Use <em> instead of <span> for PHP annotation in wp_plugin_update_row(), for consistency with other instances.

Props afragen.
Fixes #46598. See #43987.

[johnbillion]

I think this needs to be backported to the older branches in one form or another.

With WordPress 5.2 requiring at least PHP 5.6, many plugin authors will start updating their plugins to also require PHP 5.6. This is fine for users running WordPress 5.2, but for users on older versions of WordPress they'll start receiving update notifications for plugins that they may no longer be able to run if they're using a version of PHP older than 5.6. If the user updates such a the plugin then they'll likely start seeing fatal errors.

Backporting the changes that prevent updates from being served to sites that don't meet the plugin's minimum PHP version will help avoid users on older branches finding themselves updating a plugin to a version that no longer works.

Two other possible contenders for backporting:

• #43992
• #43986

[nerrad]

I agree with @johnbillion that it'd be good to backport some of this work. Unfortunately, backporting will still only be useful for sites that actually update to that minor version.

I wonder if there's something that could also be done on the wp.org side where a plugin download is not served if the server requesting the download reports a php version that the plugin doesn't support? I realize that will cause an error with the download for WP versions that don't handle that but it would be a non-breaking error (right?) which would be better than a fatal.

[afragen]

I think our efforts are better spent encouraging those users to update to the current version of WordPress. Otherwise we will end up wanting to backport most of Servehappy.

[azaozz]

Replying to johnbillion:

I think this needs to be backported to the older branches in one form or another.

Should (could?) this be handled on the updates API side? Seems a better idea than trying to backport it. Then all sites running older versions of WP will be covered, instantly.

For now it seems setting the Requires at least: 5.2 header in the plugin's readme.txt is sufficient for preventing update notifications. Of course, ideally plugin authors should be able to require newer PHP versions and still support older WP versions, but I don't see this as a blocker for 5.2.

In any case, even if there's no other way except to backport this to older versions, the backporting should happen in a minor release so it can be pushed in an auto-update. Moving this for further consideration to the next minor.

Edit: actually backporting deserves its own ticket :) Opened #47160 for it.