WordPress.org

Make WordPress Core

Opened 14 months ago

Closed 6 weeks ago

Last modified 4 weeks ago

#43987 closed task (blessed) (fixed)

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

Reported by: schlessera Owned by: afragen
Milestone: 5.2 Priority: normal
Severity: normal Version: 5.1
Component: Plugins 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 14 months 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 13 months ago.
screenshot_02.png (64.7 KB) - added by afragen 13 months ago.
screenshot_03.png (107.0 KB) - added by afragen 13 months ago.
43987-1.diff (4.6 KB) - added by afragen 13 months ago.
Update notice to use 'newer' not 'higher'
43987-2.diff (4.6 KB) - added by afragen 13 months ago.
Adds jQuery removal of update class so bottom row border displays
43987-3.diff (4.6 KB) - added by afragen 13 months 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 13 months ago.
Latest screenshot
screenshot_02.2.png (97.2 KB) - added by afragen 13 months ago.
Latest screenshot
43986v2-1.diff (2.8 KB) - added by afragen 13 months 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 13 months ago.
Adds required PHP version info to nag on plugins.php
screenshot_02.3.png (61.3 KB) - added by afragen 13 months ago.
Shows nag with required PHP version
43987-5.diff (4.8 KB) - added by afragen 13 months ago.
changed function name as suggested ;)
43987v2.diff (3.8 KB) - added by afragen 13 months ago.
hard-coded version, more in line with WP core
screenshot_02.4.png (79.3 KB) - added by afragen 13 months ago.
View from plugins.php
screenshot_01.2.png (69.0 KB) - added by afragen 13 months ago.
View from update-core.php page.
43987v3.diff (5.4 KB) - added by afragen 12 months ago.
feedback applied
screenshot_03.2.png (76.5 KB) - added by afragen 12 months ago.
43987v3.2.diff (5.4 KB) - added by afragen 12 months ago.
change More Details button to 'Cannot Update'
screenshot_03.3.png (190.8 KB) - added by afragen 12 months ago.
Cannot Update button
43987v3.3.diff (5.4 KB) - added by afragen 12 months ago.
changed all messaging text from 'upgrading' to 'updating'
43987v3.4.diff (6.6 KB) - added by afragen 11 months ago.
added some escaping where needed
43987v3.5.diff (6.6 KB) - added by afragen 5 months ago.
Update patch for update-php link
43987v4.1.diff (7.6 KB) - added by afragen 5 months 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 5 months ago.
screenshot showing checkbox gone
43987v4.2.diff (9.7 KB) - added by afragen 5 months ago.
fixed version_compare so 5.1.10 is greater than 5.1.2
43987.14.diff (7.5 KB) - added by afragen 5 months ago.
updated patch
screenshot_43987.14.png (83.7 KB) - added by afragen 5 months ago.
updated screenshot for 43987.14.diff with web host update PHP link added
43987.15.diff (7.6 KB) - added by afragen 3 months ago.
43987.2.diff (7.2 KB) - added by desrosj 3 months ago.

Download all attachments as: .zip

Change History (78)

@schlessera
14 months 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
14 months ago

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

#2 @afragen
13 months 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
13 months ago

#3 @afragen
13 months 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.

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


13 months ago

@afragen
13 months ago

Update notice to use 'newer' not 'higher'

@afragen
13 months ago

Adds jQuery removal of update class so bottom row border displays

@afragen
13 months ago

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

@afragen
13 months ago

Latest screenshot

@afragen
13 months ago

Latest screenshot

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


13 months ago

@afragen
13 months 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
13 months ago

Oops, attached to wrong trac ticket.

@afragen
13 months ago

Adds required PHP version info to nag on plugins.php

@afragen
13 months ago

Shows nag with required PHP version

#7 @schlessera
13 months 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
13 months 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
13 months 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
13 months ago

changed function name as suggested ;)

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


13 months ago

#11 @schlessera
13 months 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.


13 months ago

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


13 months ago

#14 @joyously
13 months 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 13 months ago by joyously (previous) (diff)

@afragen
13 months ago

hard-coded version, more in line with WP core

@afragen
13 months ago

View from plugins.php

@afragen
13 months ago

View from update-core.php page.

#15 @afragen
13 months 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 13 months ago by afragen (previous) (diff)

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


12 months ago

#17 @flixos90
12 months 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
12 months ago

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

@afragen
12 months ago

feedback applied

#19 @afragen
12 months 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 12 months ago by afragen (previous) (diff)

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


12 months ago

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


12 months ago

#22 @earnjam
12 months 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
12 months 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
12 months ago

change More Details button to 'Cannot Update'

@afragen
12 months ago

Cannot Update button

@afragen
12 months ago

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

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


11 months ago

@afragen
11 months ago

added some escaping where needed

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


11 months ago

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


10 months ago

#27 @afragen
9 months ago

@schlessera @flixos90 should this be milestone 4.9.9?

Last edited 9 months ago by afragen (previous) (diff)

#28 @afragen
8 months ago

Probably need to milestone this for 5.1

#29 @flixos90
8 months ago

  • Milestone changed from 5.0 to 5.1

@afragen
5 months ago

Update patch for update-php link

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


5 months ago

@afragen
5 months ago

Removes checkbox from plugins.php page if incompatible PHP version

@afragen
5 months ago

screenshot showing checkbox gone

#31 @afragen
5 months 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.


5 months ago

@afragen
5 months 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.


5 months ago

#34 @afragen
5 months ago

We probably need to change milestone to 5.2

Last edited 5 months ago by afragen (previous) (diff)

#35 @flixos90
5 months ago

  • Milestone changed from 5.1 to 5.2

@afragen
5 months ago

updated patch

@afragen
5 months ago

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

#36 @afragen
5 months 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
5 months ago

  • Version set to trunk

@afragen
3 months ago

@desrosj
3 months ago

#38 @desrosj
3 months 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
3 months 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
3 months 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
2 months 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.


2 months ago

#43 @nerrad
2 months 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
8 weeks 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.


7 weeks ago

#46 in reply to: ↑ 41 @azaozz
6 weeks 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 weeks ago by azaozz (previous) (diff)

#47 @azaozz
6 weeks ago

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

#48 @afragen
4 weeks ago

Last edited 4 weeks ago by afragen (previous) (diff)
Note: See TracTickets for help on using tickets.