WordPress.org

Make WordPress Core

Opened 3 months ago

Last modified 7 days ago

#43987 assigned task (blessed)

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

Reported by: schlessera Owned by: afragen
Milestone: 5.0 Priority: normal
Severity: normal Version:
Component: Plugins Keywords: needs-unit-tests servehappy has-patch
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 (22)

WHIP core - updates page.png (129.8 KB) - added by schlessera 3 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 2 months ago.
screenshot_02.png (64.7 KB) - added by afragen 2 months ago.
screenshot_03.png (107.0 KB) - added by afragen 2 months ago.
43987-1.diff (4.6 KB) - added by afragen 2 months ago.
Update notice to use 'newer' not 'higher'
43987-2.diff (4.6 KB) - added by afragen 2 months ago.
Adds jQuery removal of update class so bottom row border displays
43987-3.diff (4.6 KB) - added by afragen 2 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 2 months ago.
Latest screenshot
screenshot_02.2.png (97.2 KB) - added by afragen 2 months ago.
Latest screenshot
43986v2-1.diff (2.8 KB) - added by afragen 2 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 2 months ago.
Adds required PHP version info to nag on plugins.php
screenshot_02.3.png (61.3 KB) - added by afragen 2 months ago.
Shows nag with required PHP version
43987-5.diff (4.8 KB) - added by afragen 2 months ago.
changed function name as suggested ;)
43987v2.diff (3.8 KB) - added by afragen 7 weeks ago.
hard-coded version, more in line with WP core
screenshot_02.4.png (79.3 KB) - added by afragen 7 weeks ago.
View from plugins.php
screenshot_01.2.png (69.0 KB) - added by afragen 7 weeks ago.
View from update-core.php page.
43987v3.diff (5.4 KB) - added by afragen 6 weeks ago.
feedback applied
screenshot_03.2.png (76.5 KB) - added by afragen 6 weeks ago.
43987v3.2.diff (5.4 KB) - added by afragen 5 weeks ago.
change More Details button to 'Cannot Update'
screenshot_03.3.png (190.8 KB) - added by afragen 5 weeks ago.
Cannot Update button
43987v3.3.diff (5.4 KB) - added by afragen 4 weeks ago.
changed all messaging text from 'upgrading' to 'updating'
43987v3.4.diff (6.6 KB) - added by afragen 13 days ago.
added some escaping where needed

Download all attachments as: .zip

Change History (47)

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

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

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

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


2 months ago

@afragen
2 months ago

Update notice to use 'newer' not 'higher'

@afragen
2 months ago

Adds jQuery removal of update class so bottom row border displays

@afragen
2 months ago

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

@afragen
2 months ago

Latest screenshot

@afragen
2 months ago

Latest screenshot

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


2 months ago

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

Oops, attached to wrong trac ticket.

@afragen
2 months ago

Adds required PHP version info to nag on plugins.php

@afragen
2 months ago

Shows nag with required PHP version

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

changed function name as suggested ;)

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


8 weeks ago

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


8 weeks ago

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


7 weeks ago

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

@afragen
7 weeks ago

hard-coded version, more in line with WP core

@afragen
7 weeks ago

View from plugins.php

@afragen
7 weeks ago

View from update-core.php page.

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

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


6 weeks ago

#17 @flixos90
6 weeks 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
6 weeks ago

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

@afragen
6 weeks ago

feedback applied

#19 @afragen
6 weeks 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 5 weeks ago by afragen (previous) (diff)

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


6 weeks ago

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


6 weeks ago

#22 @earnjam
6 weeks 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
6 weeks 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
5 weeks ago

change More Details button to 'Cannot Update'

@afragen
5 weeks ago

Cannot Update button

@afragen
4 weeks ago

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

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


2 weeks ago

@afragen
13 days ago

added some escaping where needed

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


7 days ago

Note: See TracTickets for help on using tickets.