WordPress.org

Make WordPress Core

Opened 11 months ago

Closed 4 days ago

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

Download all attachments as: .zip

Change History (70)

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

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

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

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


10 months ago

@afragen
10 months ago

Update notice to use 'newer' not 'higher'

@afragen
10 months ago

Adds jQuery removal of update class so bottom row border displays

@afragen
10 months ago

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

@afragen
10 months ago

Latest screenshot

@afragen
10 months ago

Latest screenshot

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


10 months ago

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

Oops, attached to wrong trac ticket.

@afragen
10 months ago

Adds required PHP version info to nag on plugins.php

@afragen
10 months ago

Shows nag with required PHP version

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

changed function name as suggested ;)

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


10 months ago

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


10 months ago

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


10 months ago

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

@afragen
10 months ago

hard-coded version, more in line with WP core

@afragen
10 months ago

View from plugins.php

@afragen
10 months ago

View from update-core.php page.

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

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


10 months ago

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

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

@afragen
9 months ago

feedback applied

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

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


9 months ago

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


9 months ago

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

change More Details button to 'Cannot Update'

@afragen
9 months ago

Cannot Update button

@afragen
9 months ago

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

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


9 months ago

@afragen
9 months ago

added some escaping where needed

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


8 months ago

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


7 months ago

#27 @afragen
6 months ago

@schlessera @flixos90 should this be milestone 4.9.9?

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

#28 @afragen
6 months ago

Probably need to milestone this for 5.1

#29 @flixos90
6 months ago

  • Milestone changed from 5.0 to 5.1

@afragen
3 months ago

Update patch for update-php link

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


3 months ago

@afragen
3 months ago

Removes checkbox from plugins.php page if incompatible PHP version

@afragen
3 months ago

screenshot showing checkbox gone

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


3 months ago

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


2 months ago

#34 @afragen
2 months ago

We probably need to change milestone to 5.2

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

#35 @flixos90
2 months ago

  • Milestone changed from 5.1 to 5.2

@afragen
2 months ago

updated patch

@afragen
2 months ago

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

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

  • Version set to trunk

@afragen
4 days ago

@desrosj
4 days ago

#38 @desrosj
4 days 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
4 days 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
40 hours 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.

Note: See TracTickets for help on using tickets.