Make WordPress Core

Opened 7 years ago

Closed 6 years ago

Last modified 6 years ago

#43987 closed task (blessed) (fixed)

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

Reported by: schlessera's profile schlessera Owned by: afragen's profile afragen
Milestone: 5.2 Priority: normal
Severity: normal Version: 5.1
Component: Site Health Keywords: servehappy fixed-major
Focuses: Cc:

Description (last modified by flixos90)

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.

Attachments (30)

WHIP core - updates page.png (129.8 KB) - added by schlessera 7 years ago.
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.
43987.diff (4.6 KB) - added by afragen 7 years ago.
screenshot_02.png (64.7 KB) - added by afragen 7 years ago.
screenshot_03.png (107.0 KB) - added by afragen 7 years ago.
43987-1.diff (4.6 KB) - added by afragen 7 years ago.
Update notice to use 'newer' not 'higher'
43987-2.diff (4.6 KB) - added by afragen 7 years ago.
Adds jQuery removal of update class so bottom row border displays
43987-3.diff (4.6 KB) - added by afragen 7 years ago.
Use jQuery to remove update row instead of using CSS and display:none to hide
screenshot_01.png (63.7 KB) - added by afragen 7 years ago.
Latest screenshot
screenshot_02.2.png (97.2 KB) - added by afragen 7 years ago.
Latest screenshot
43986v2-1.diff (2.8 KB) - added by afragen 7 years ago.
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.
43987-4.diff (4.7 KB) - added by afragen 7 years ago.
Adds required PHP version info to nag on plugins.php
screenshot_02.3.png (61.3 KB) - added by afragen 7 years ago.
Shows nag with required PHP version
43987-5.diff (4.8 KB) - added by afragen 7 years ago.
changed function name as suggested ;)
43987v2.diff (3.8 KB) - added by afragen 7 years ago.
hard-coded version, more in line with WP core
screenshot_02.4.png (79.3 KB) - added by afragen 7 years ago.
View from plugins.php
screenshot_01.2.png (69.0 KB) - added by afragen 7 years ago.
View from update-core.php page.
43987v3.diff (5.4 KB) - added by afragen 7 years ago.
feedback applied
screenshot_03.2.png (76.5 KB) - added by afragen 7 years ago.
43987v3.2.diff (5.4 KB) - added by afragen 7 years ago.
change More Details button to 'Cannot Update'
screenshot_03.3.png (190.8 KB) - added by afragen 7 years ago.
Cannot Update button
43987v3.3.diff (5.4 KB) - added by afragen 7 years ago.
changed all messaging text from 'upgrading' to 'updating'
43987v3.4.diff (6.6 KB) - added by afragen 7 years ago.
added some escaping where needed
43987v3.5.diff (6.6 KB) - added by afragen 6 years ago.
Update patch for update-php link
43987v4.1.diff (7.6 KB) - added by afragen 6 years ago.
Removes checkbox from plugins.php page if incompatible PHP version
Screen Shot 2019-01-03 at 7.14.35 PM.png (78.9 KB) - added by afragen 6 years ago.
screenshot showing checkbox gone
43987v4.2.diff (9.7 KB) - added by afragen 6 years ago.
fixed version_compare so 5.1.10 is greater than 5.1.2
43987.14.diff (7.5 KB) - added by afragen 6 years ago.
updated patch
screenshot_43987.14.png (83.7 KB) - added by afragen 6 years ago.
updated screenshot for 43987.14.diff with web host update PHP link added
43987.15.diff (7.6 KB) - added by afragen 6 years ago.
43987.2.diff (7.2 KB) - added by desrosj 6 years ago.

Download all attachments as: .zip

Change History (79)

@schlessera
7 years ago

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.

#1 @flixos90
7 years ago

  • Keywords needs-patch needs-unit-tests servehappy added
  • Milestone changed from Awaiting Review to 5.0

#2 @afragen
7 years ago

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
7 years ago

#3 @afragen
7 years ago

  • Keywords has-patch added; needs-patch removed

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
7 years ago

@afragen
7 years ago

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


7 years ago

@afragen
7 years ago

Update notice to use 'newer' not 'higher'

@afragen
7 years ago

Adds jQuery removal of update class so bottom row border displays

@afragen
7 years ago

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

@afragen
7 years ago

Latest screenshot

@afragen
7 years ago

Latest screenshot

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


7 years ago

@afragen
7 years ago

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.

#6 @afragen
7 years ago

Oops, attached to wrong trac ticket.

@afragen
7 years ago

Adds required PHP version info to nag on plugins.php

@afragen
7 years ago

Shows nag with required PHP version

#7 @schlessera
7 years ago

@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.

#8 @afragen
7 years ago

@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.

#9 @SergeyBiryukov
7 years ago

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
7 years ago

changed function name as suggested ;)

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


7 years ago

#11 @schlessera
7 years ago

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

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


7 years ago

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


7 years ago

#14 @joyously
7 years ago

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.

Last edited 7 years ago by joyously (previous) (diff)

@afragen
7 years ago

hard-coded version, more in line with WP core

@afragen
7 years ago

View from plugins.php

@afragen
7 years ago

View from update-core.php page.

#15 @afragen
7 years ago

  • Keywords dev-feedback added

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

Here's the patch 43987v2.diff

View from plugins.php

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.

View from update-core.php 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.

Last edited 7 years ago by afragen (previous) (diff)

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


7 years ago

#17 @flixos90
7 years ago

  • Description modified (diff)
  • Keywords dev-feedback removed
  • Summary changed from Block plugins from updating if required PHP version is not supported to Block plugin updates if required PHP version is not supported - Plugins screen

#18 @flixos90
7 years ago

  • Owner set to afragen
  • Status changed from new to assigned

@afragen
7 years ago

feedback applied

#19 @afragen
7 years ago

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

Cannot Update button

Last edited 7 years ago by afragen (previous) (diff)

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


7 years ago

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


7 years ago

#22 @earnjam
7 years ago

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?

#23 @afragen
7 years ago

@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
7 years ago

change More Details button to 'Cannot Update'

@afragen
7 years ago

Cannot Update button

@afragen
7 years ago

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

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


7 years ago

@afragen
7 years ago

added some escaping where needed

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


7 years ago

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


6 years ago

#27 @afragen
6 years ago

@schlessera @flixos90 should this be milestone 4.9.9?

Last edited 6 years ago by afragen (previous) (diff)

#28 @afragen
6 years ago

Probably need to milestone this for 5.1

#29 @flixos90
6 years ago

  • Milestone changed from 5.0 to 5.1

@afragen
6 years ago

Update patch for update-php link

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


6 years ago

@afragen
6 years ago

Removes checkbox from plugins.php page if incompatible PHP version

@afragen
6 years ago

screenshot showing checkbox gone

#31 @afragen
6 years ago

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

screenshot showing checkbox gone

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


6 years ago

@afragen
6 years ago

fixed version_compare so 5.1.10 is greater than 5.1.2

This ticket was mentioned in Slack in #themereview by greenshady. View the logs.


6 years ago

#34 @afragen
6 years ago

We probably need to change milestone to 5.2

Last edited 6 years ago by afragen (previous) (diff)

#35 @flixos90
6 years ago

  • Milestone changed from 5.1 to 5.2

@afragen
6 years ago

updated patch

@afragen
6 years ago

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

#36 @afragen
6 years ago

  • Keywords dev-feedback added

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.

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

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

#37 @afragen
6 years ago

  • Version set to trunk

@afragen
6 years ago

@desrosj
6 years ago

#38 @desrosj
6 years ago

  • Keywords commit added

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.

#39 @desrosj
6 years ago

  • Resolution set to fixed
  • Status changed from assigned to closed

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.

#40 @SergeyBiryukov
6 years ago

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.

#41 follow-up: @johnbillion
6 years ago

  • Keywords fixed-major added; needs-unit-tests has-patch dev-feedback commit removed
  • Resolution fixed deleted
  • Status changed from closed to reopened

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:

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


6 years ago

#43 @nerrad
6 years ago

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.

#44 @afragen
6 years ago

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.

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


6 years ago

#46 in reply to: ↑ 41 @azaozz
6 years ago

  • Milestone changed from 5.2 to 5.2.1

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.

Last edited 6 years ago by azaozz (previous) (diff)

#47 @azaozz
6 years ago

  • Milestone changed from 5.2.1 to 5.2
  • Resolution set to fixed
  • Status changed from reopened to closed

#48 @afragen
6 years ago

Last edited 6 years ago by afragen (previous) (diff)

#49 @spacedmonkey
6 years ago

  • Component changed from Plugins to Site Health
Note: See TracTickets for help on using tickets.