Disable "Install Plugin" button for PHP required version mismatch

[schlessera]

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

As a first step in enforcing the "Requires PHP" plugin header information, we should disable the "Install" (plugin) button while displaying a notice with the reason why.

In contrast to blocking updates (which has infrastructure & security" implications), disabling the "Install" button is relatively easy to do, provides most of the benefit of the "Requires PHP" header from all new and future installs, and most of all, provides a very real and convincing incentive for actually working on upgrading their servers.

While any installation path should be properly blocked based on this header, just disabling the "Install" button already makes sure we stop creating more problematic installations sites in the future.

[schlessera]

Mockup by @hedgefiled: Incompatible plugins cannot be installed and show up red in the overview. Used the WP colors #FBEAEA for the background and #DC3232 for the button.

[schlessera]

Mockup by @hedgefiled: The plugin directory page in the backend can show a warning if the detected PHP version is too low, and the install button is red here too. I didn't edit the statistics in this one because it's still using the old plugin directory theme (see #40971)

[schlessera]

Mockup by @hedgefiled: I updated the More Details modal with the new plugin directory theme, made the PHP warning more fierce (because it's not a warning) and added more messaging next to the button, which I changed into a label, because it shouldn't be clickable.

[schlessera]

Mockup by @hedgefield: And an alternative take on the Add Plugins page without the red tint and the button turned into a label. I used the compatibility check in the card's footer to put the PHP warning, since it doesn't matter if the plugin is compatible with Wordpress if it's not compatible with your PHP.

[afragen]

Am I understanding the flow correctly?

The user’s Install page would need to survey every plugin listed on the page and query the API to get the requires data from readme.txt. Then it would have to check the user’s PHP version, and add the custom labels, buttons, etc.

Wouldn’t some sort of data return from the API that builds the page be needed?

[afragen]

Nevermind, I found the 'plugin_install_action_links' in the plugin card.

[afragen]

Here's an initial pass at displaying an inactive button and message when the PHP requirement is not met. It needs styling.

https://core.trac.wordpress.org/attachment/ticket/43986/43986.diff

[afragen]

This is what patch will display.

[afragen]

This should cleanly apply.

[afragen]

Somehow need to hook into AJAX search results.

OK, I've gotten this solved. New patch coming.

[afragen]

Updated patch to account for results of add plugin search

[afragen]

Just a fix for proper spacing. No other differences from 43986-2.diff

[joyously]

I think it's a shame that the version number needed is known, but not shown to the user. Wouldn't it be better to tell them which version they need to upgrade to in order to use that plugin?

[afragen]

Where would you like to see the current PHP version number?

All the messages are very much open for discussion. I simply put in something similar to the proposed design.

[afragen]

Current PHP version information added

[afragen]

@joyously we could do something like the above.

[afragen]

More information here

[afragen]

Sorry @joyously I misread your comment. See the last screenshot as an example.

[afragen]

Perhaps only displaying the required PHP version would be simplest.

[joyously]

@afragen I think that is too much to put below the button. Can you put it where the WP compatibility line is instead, like in the screenshot schlessera showed?

[afragen]

I don’t think there’s no current hook in that location, but I’ll look into adding one if it doesn’t exist.

[afragen]

This uses a new action hook to add text to the plugin card bottom. Also removes info below disabled install link.

[afragen]

@joyously how about this one 👆

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

[Luciano Croce]

@afargen Please: consider to add the number of Downloads. Thx!

[afragen]

@Luciano-Croce I’m pretty sure that’s not in scope of this ticket.

[Luciano Croce]

Replying to afragen:

@Luciano-Croce I’m pretty sure that’s not in scope of this ticket.

Yes, of course, but I’m pretty sure that’s since this modification is open, it could be added without having to open another ticket, something more to keep in mind in this "refactoring".

Have a nice day.

Thanks.

[johnalarcon]

If there's too much text, it won't get read. Or, if it seems jammed together, the aesthetic suffers (and it also probably wouldn't get read). It also doesn't seem necessary to tell users what version of PHP or WordPress they're running - if they don't meet the requirement, they don't meet them. I think stating the requirements and using checks-n-exes would be a cleaner approach. See ss above. That little block of requirements could be moved around wherever, and still probably fit nicely.

[afragen]

@johnalarcon I can do something pretty close to that if that's the consensus.

I think we need a lot more input before a final decision.

@joyously what do you think?

[afragen]

Simplifies message and adds color, but CSS needs to be built.

[johnalarcon]

The word "required" for PHP version is redundant under a "Requirements" header. Also, WordPress version doesn't have a "v", but PHP version does...I'd nix it for both - people know what these numbers are. I think it looks quite nice and (the reqs info) could even fit in nicely under the More Details link, which would bring the footer back to a reasonable size.

[afragen]

I’ll adjust the patch accordingly.

I actually like the placement and it’s technically the “compatibility” section of the card.

[afragen]

minimal words

[afragen]

This patch has fewest words.

[afragen]

Now if you're running trunk, you still get the standard Untested message.

Yes, the CSS still needs to be built.

I'm really liking this version.

[afragen]

Oops, now includes something if PHP is compatible. PHP shown as compatible if no requirement listed.

[afragen]

Might consider using a question mark for untested so it would look like ? WordPress. Some other character might be more appropriate but I'm not sure how to figure out the best one.

[johnalarcon]

That looks really nice! Yeah, re: untested... I'd lean toward a question mark, as well.

[SergeyBiryukov]

43986.2.diff​ is my take on the patch, mostly following @hedgefield's mockups.

Screenshots: 43986.2.plugin-list.PNG​, 43986.2.more-details.PNG​.

I don't think we should change the UI too much. "Incompatible with your version of PHP. ​Learn more" seems enough for our purposes, and we can explain the details in "More Details" modal.

I didn't implement red buttons (went with regular disabled buttons instead), as we don't have them anywhere else in core, and I'd like to avoid introducing new design conventions here. Maybe even the pink background on plugin cards is too much? I'm open to suggestions though if someone has strong feelings either way :)

[johnalarcon]

@SergeyBiryukov

Re: SS 43986.2-plugin-list.PNG, I agree about the pink background; it's a bit much.

Re: SS 43986.2-more-details.PNG, a couple of things.

The SS depicts a warning. Giving them a "notice" seems more appropriate. I feel that a warning would only be warranted if the installation was actually allowed to proceed - ie, there was some sort of risk or danger.

The text is a bit verbose. Does it need to say here that the plugin can't be installed? My feeling is the big disabled button communicates that chunk of the sentence in a place where users will more easily find it. That said, I couldn't pare the text down by much, but here's my thought:

Notice: This plugin requires PHP X.x or later. Please contact your web host or site admin for assistance in upgrading.

[schlessera]

Some notes regarding the above patches (should apply equally to @afragen's & @SergeyBiryukov's patches):

• You should account for the possibility of $plugins not containing the 'requires_php' index, to make the code more robust. If that index is not included, just assume it is compatible.
• Information should not be coded in color or symbols only, because of a11y reasons. This applies to things like a pink background just as well as the colored symbols. As an example, the color-coded ✔️and ❌should contain invisible screen-reader-text so that screen readers can read out loud what is happening.

@SergeyBiryukov I think your logic is off. If the plugin does not contain the required headers, the code will default to blocking installations.

In terms of code, I think we have two different approaches here: action-based vs hard-coded. One is more flexible and looks cleaner, the other is a better enforcement. I'm not yet sure on which method I'd prefer...

[SergeyBiryukov]

Thanks for the feeback! In 43986.3.diff​:

• Correct the logic to account for requires_php header not being present.
• Change Warning label in More Details to Error, since that's what the message is.
• Remove pink background from plugin cards.

[afragen]

Currently, if requires_php is not present the value is present and defaults to false.

Do we want to display any information regarding WordPress compatibility? Currently the only notice is untested.

Thanks for the great feedback!

[afragen]

more details of 43986v2-5.diff

[afragen]

add aria-labels everywhere, fixes the 'more details' iframe

[afragen]

@schlessera

Now has aria-labels over the requirements text and other option is simply WordPress untested, also with aria-label.

Also has aria-labels.

I added a test for isset( $plugin['requires_php']) in the relevant functions for completeness.

I also added an additional filter hook to be able to replace the 'More Details' button.

As @SergeyBiryukov and I are going at this from 2 slightly different methods, perhaps we can discuss it more at the #core-php meeting?

The minimalist plugin card is growing on me. Especially since more verbiage is present in the More Details iframe.

[afragen]

fixed aria-label text for WordPress compatibility to make more sense

[afragen]

improve wording of aria-labels

[afragen]

added is_php_compatible() function and use it along with is_wordpress_compatible()

[afragen]

Hard-coded, but with individual notices ( WordPress and PHP) for both plugin card and More Details iframe.

[afragen]

2 lines on plugin card

[afragen]

Example WordPress incompat

[afragen]

WP good, PHP bad

[afragen]

So @SergeyBiryukov and I decided to create 2 patches, one with a single line message and one with a two line message. The two line message treats WordPress compatibility and PHP compatibility as separate concerns.

Both patches should be functionally equivalent.

These examples are obviously from the two line variant. 43986v3-1.diff

Shows two line in the plugin card.

Shows separate notices in the 'More Details' iframe.

Shows when compatibility exists, no notice is displayed.

For the purposes of these examples I set the $wp_version = '4.7.0';

[flixos90]

Thanks for the latest patch 43986v3-1.diff​ @afragen, it's really useful to have this and the accompanying screenshots available.

One comment: Can you please remove the “tested PHP” part? There is no plugin header for a maximum tested PHP version, and that decision was made for a reason. Let’s not assume anything there, as a message like “This plugin has not been tested with your current version of PHP.” raises concerns that are unnecessary in the vast majority of cases. Let’s keep the PHP checks to the minimum required version.

[nerrad]

I like the direction things are going however I really think the message given in the card should directly relate to the state of the install button.

• if users are able to install, then there's no need for any message because they are able to install it.
• if users are not able to install/update, then the message should answer the question "Why can't I install this?"

[afragen]

No more untested PHP notices.

[afragen]

Added color to icons (since they're present), reverse order of precedence for PHP then WordPress notices

[afragen]

set $wp_version = '3.7' to see this. Used to show all most variability, only WP untested not shown.

[afragen]

More Details page with 2 messages. Again set $wp_version = '3.7' to see this.

[afragen]

OK latest 43986v3-3.diff​ showing no notice except for PHP incompatibility and all current WP notices. Order of notices is PHP then WP. Also icons are now colored after CSS compiled.

Shows most combinations of plugin card notices. Again $wp_version = '3.7' to show these.

Shows More Details page with both notices. Again $wp_version = '3.7' to show these.

Plugin card in trunk

More Details page in trunk

[afragen]

plugin card in truck

[afragen]

More Details in trunk

[boemedia]

We discussed this ticket in yesterday's design team meeting. We agree this would be a good way of preventing installation of plugins that don't work with older php-versions. However, we find the information on the plugin cards kind of overwhelming and the icons not very visible.

Here's a few suggestions we have:

• reduce text
• don't show notification when the plugin is compatible. It should be compatible by default.
• place notification instead of 'rating' and 'last updated', to make it more prominent.

Please find attached the original card design for making the error message more visual.

If there are any questions about this feedback, please feel free and jump by in the Design Slack Channel: ​https://wordpress.slack.com/messages/C02S78ZAL.

[afragen]

Design feedback with card bottom replaced.

[afragen]

plugin card with design feedback re: bottom info replacement

[afragen]

More Details window. No real changes from design.

[afragen]

Thanks for the design feedback and thanks to @melchoyce for continuing the discussion and refining stuff.

43986v4.3.diff​ is the new patch with the design feedback regarding replacement of the info panel with an incompatibility notice and updated aria-label.

Below is how the plugin card looks.

Below is how the More Details window looks.

[lakenh]

Just a few little accessibility nitpicks with the most recent patch :)

As discussed a bit in Slack, the "Why?" link isn't very descriptive on its own. There was an aria-label that's also on the "More Details" link added, however, that causes a bit of an accessibility problem on its own. The link text is now redundant, and that aria-label doesn't describe the error, nor tell a screen-reader user that clicking on that will help them fix the problem.

I still think that the link text should be changed to something that tells the entire function of the page it's linking.

Alternatively, the WordPress admin has a screen-reader text class, and so we could also have the link text be something like Why <span class="screen-reader-text">is there an installation incompatibility</span>?.

If the aria-label though is the way we're doing it, I'd recommend changing it to something like "View plugin installation incompatibility."

[afragen]

oops forgot a commit in the last patch. Shouldn't be functionally different but one less conditional.

[melchoyce]

An alternate idea where the bottom information isn't obscured.

[afragen]

Design style #2, displays plugin info, 2 lines

[afragen]

Design style #2

[afragen]

43986v5.2.diff​ is patch for inline notice that still shows plugin card information, including compatibility info and updated aria-label.

More Details window hasn't changed.

@melchoyce here's the second version.

[afragen]

updated aria-label

[afragen]

updated aria-label

[afragen]

Replying to lakenh:

Just a few little accessibility nitpicks with the most recent patch :)

As discussed a bit in Slack, the "Why?" link isn't very descriptive on its own. There was an aria-label that's also on the "More Details" link added, however, that causes a bit of an accessibility problem on its own. The link text is now redundant, and that aria-label doesn't describe the error, nor tell a screen-reader user that clicking on that will help them fix the problem.

I still think that the link text should be changed to something that tells the entire function of the page it's linking.

Alternatively, the WordPress admin has a screen-reader text class, and so we could also have the link text be something like Why <span class="screen-reader-text">is there an installation incompatibility</span>?.

If the aria-label though is the way we're doing it, I'd recommend changing it to something like "View plugin installation incompatibility."

I’ve updated the aria-label in both of the latest patches based upon design input.

[afercia]

The patch shouldn't patch .rtl files (see list-tables-rtl.css), they're generated during the build process.

[afercia]

The proposed usage of the aria-label doesn't meet what the WCAG recommend in these cases:

• Why?
• View plugin installation incompatibility with %s

Ideally, the aria-label text should start with the same text used for the visible link text. There are good reasons for this, for more details see the links below. Instead, the aria-label used here is completely different form the visible text. Regardless, I'd recommend to keep things simple and not use an aria-label in the first place. A better, visible, link text instead of Why? would be certainly a better option.

​https://www.w3.org/TR/WCAG21/#label-in-name
Success Criterion 2.5.3 Label in Name§

For user interface components with labels that include text or images of text, the name (they mean the accessible name, i.e. the aria-label) contains the text that is presented visually.

​https://www.w3.org/WAI/WCAG21/Understanding/label-in-name.html

A best practice is to have the text of the label at the start of the name.

​https://www.w3.org/TR/WCAG20-TECHS/ARIA8.html

the aria-label text will override the text supplied within the link. As such the text supplied will be used instead of the link text by AT. Due to this it is recommended to start the text used in aria-label with the text used within the link. This will allow consistent communication between users.

​https://www.w3.org/TR/WCAG20-TECHS/ARIA8.html#ARIA8-ex1

The words 'read more' are repeated in the aria-label (which replaces the original anchor text of "[Read more...]") to allow consistent communication between users.

[acirujano]

Hi from the Contributor Day at WordCamp Irun!

We'e been working on this ticket and after discussing it with the team, we agreed that the screenshot_05.png on ticket #37 could be the best solution.

Cheers!

[ibantxillo]

I´m agree, that solution is the best solution.

the button appears disabled, the information of the cause of the disablement, and from the link of more details you can go the tab and see in more detail that you need to be able to install this plugin. And all have the WordPress design style.

Cheers!

Replying to acirujano:

Hi from the Contributor Day at WordCamp Irun!

We'e been working on this ticket and after discussing it with the team, we agreed that the screenshot_05.png on ticket #37 could be the best solution.

Cheers!

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

[afragen]

updated patch based upon #core-php meeting 4 June 2018

[afragen]

plugin card with $wp_version set to 3.7

[afragen]

More Details window with $wp_version set to 3.7

[afragen]

latest patch running trunk

[afragen]

Based upon today's #core-php meeting I have updated the patch 43986v4.4.diff​.

The plugin card displays as follows. I set $wp_version = '3.7'; so that the message for an incompatible version of WordPress would display. There is not untested message in the plugin card. There is still the untested notice in the More Details window.

This is the More Detail window using the constraints as above.

This how the plugin card looks when running trunk.

This is the start of discussion that this patch was based upon, ​https://wordpress.slack.com/archives/C60K3MP2Q/p1528124435000346

[joyously]

Your constant patches make it difficult to see the discussion. My comment got lost in the flurry, but I think it deserves an answer.

Why are we disabling the Install button at all? Why are we not focusing on activation?

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.

[afragen]

Replying to joyously:

Your constant patches make it difficult to see the discussion. My comment got lost in the flurry, but I think it deserves an answer.

Why are we disabling the Install button at all? Why are we not focusing on activation?

We disable the Install button because we want the user to understand that they cannot install the plugin. It would be a poor user experience to think they can install a plugin and instead get an error of the installation process. I wrote a POC plugin that did it this way. It looks awful. Ultimately it was the consensus opinion of #core-php and the primary scope of the trac ticket to disable the install button.

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

There are infinite combinations of plugins and it is the responsibility of the site owner, or the person responsible for site maintenance, to ensure that the site doesn’t whitescreen because of some poorly coded plugin or an update. All that we can do is try to protect the user as much as we can. There is currently no method to determine if a plugin is compatible with a higher version of PHP. It’s up to the plugin developer to maintain their code, or you can fork it, fix it, and submit a PR; and it’s our responsibility to test our sites.

It is highly unlikely that a WordPress update will cause an issue with a plugin. We all know that WordPress seeks backwards compatibility, sometimes to the detriment of more advanced coding practices.

More information regarding a plugin’s requirements is still, and always has been, in the “More Details” window.

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

This was addressed above.

Others may have different explanations. I could be wrong. I am not the authority nor do I claim to be. I do hope some of my explanation makes sense and I hope even more that it is accurate. I’m trying.

[joyously]

I think you missed my point.

In order to keep a site working through an upgrade, the user will need to identify plugins to use with the new PHP version, and install them ahead of the upgrade so that they can be activated quickly after the upgrade. The goal would be to minimize the down time and effort involved in finding replacements. If the user has to wait until after the upgrade to install the replacements, there is potentially much more time that the site is not working.

Additionally, there is a subtle problem with showing a warning for Required PHP version because it is a minimum version. The user will only see the warnings when his PHP version is low. So if he does the upgrade first, and then searches for plugin replacements, there will be no warnings on plugins that are written for a lower PHP version and could cause errors on the upgraded version, such as the ones needing replacement. Having the warning work in only one direction dictates that it is better to install the replacements before the upgrade, but this ticket is about making that impossible. And after the upgrade, any attempts to find plugins would always have some element of doubt about whether there is a PHP conflict (since it won't be flagged).

[nerrad]

Thanks for leaving your feedback here Joy. I think there may be some misunderstanding behind the purpose of this ticket so I'll attempt to clarify.

The purpose of this ticket involves using the existing information available in the api response from WordPress.org to determine whether the server meets the minimum requirements of PHP for a plugin to be installed and block installation if that is not possible and guide the user in how to rectify that if their server doesn't meet the minimum requirements and they still want to install (and thus use) the plugin. There was an addition to that in the course of doing this ticket which involved also blocking install if the plugin did not meet the WordPress requirements. Since your feedback is focusing on the PHP requirements I'll focus on that in my answer.

In order to keep a site working through an upgrade, the user will need to identify plugins to use with the new PHP version, and install them ahead of the upgrade so that they can be activated quickly after the upgrade.

I'm still not sure I understand this correctly but it sounds like your concern is about plugins the site owner may already have installed that might not work with the upgraded php version and you want a way for site owners to identify those so they can either install replacements or upgrade the plugins if an update is available. Is that correct? If so, this ticket won't resolve that issue and quite frankly it can't. There is currently no way for any WordPress install to "know" whether any uninstalled plugin will work with a given installed php version (outside of what the plugin author provides via the required PHP version meta). There was some discussion a while back about introducing a "Works up to" value for PHP in the plugin details on WordPress.org but the consensus is that was a bad idea for a number of reasons that I don't think is worthwhile to go into here.

One of the reasons users are directed to the ServeHappy page about upgrading php via a link with the warning introduced here is because it includes information informing people about the risks involved with an upgrade including the possibility of current plugins active on their site not working with the new version of PHP.

It's important to keep in mind that the scope of this ticket is intentionally narrow.

Having the warning work in only one direction dictates that it is better to install the replacements before the upgrade, but this ticket is about making that impossible. And after the upgrade, any attempts to find plugins would always have some element of doubt about whether there is a PHP conflict (since it won't be flagged).

I'm not sure how this ticket is "about making that impossible". What you are suggesting is impossible now. This ticket is about surfacing information that is available in WordPress.org for plugins that have chosen to use the new Requires PHP version: meta data to make it clear what version of PHP their plugin requires. The work in this ticket surfaces that information in a way that makes it immediately apparent to site owner's what plugins definitely won't work on their site in its current state. This ticket does not have the scope of covering all the other issues you raised. You may want to create a separate trac ticket and articulate those things in them for consideration. However, be aware there'd be a number of other components that would need ironed out before some of what you suggested could be implemented because there's currently no data available that helps with that (maybe when the tide project is implemented that would help with that).

With all that said, I'm also trying to understand the purpose behind your feedback and the goal you are shooting for? Can you elaborate on that? For example, are you suggesting that because this ticket doesn't address the issues you are raising that its current form will cause more problems for users than it solves so you think it should be blocked from release until those issues are also solved?

Finally, I realize you also asked if it'd be better to prevent activation rather than installation. Again this ticket is specifically dealing with installation and I think it's worthwhile preventing people from installing plugins where version incompatibilities are definitely known. I also think its worthwhile blocking activation in the case of plugins that are uploaded via ftp and that is being handled in #43992. Also just in case you aren't aware there's also a separate ticket that is dealing with plugin upgrades #43987.

[joyously]

Again, you have missed my point.

This ticket has a narrow scope because it is written with the "solution" as the title. That is not the preferred method of writing tickets. It should describe the problem, and then the solution is discussed and implemented. The problem this ticket is addressing is preventing PHP errors from occurring with mismatched PHP versions by using the Requires PHP header if it exists in the plugin. But we have not discussed the best way to accomplish that. What has been left out of this discussion is the actual steps the user must go through in order to upgrade PHP.

With the implementation of the last patch, the user is not helped; he is just hindered. What would help is to allow the installation of plugins regardless of PHP version, and disallow their activation if there is a PHP mismatch. Think about the user trying to upgrade. He has to find some plugin replacements and install them before the upgrade so that the site is not down long. The plugins being replaced would need to be deactivated before the upgrade so the site doesn't crash on upgrade.

All I'm asking for is the user experience to be given more thought. The current solution is not helpful at all. The "disabling" should be the activation, not the installation or the plugin update. Given one choke point, it's easier to implement and more useful to the user, especially since the WP admin is not the only way to get a plugin installed. WP doesn't care if the user has old plugins that don't run with the current WP version. They don't matter until they are activated, right? So what is the problem with installing plugins with higher PHP requirements? They aren't a problem until activated. Let the user install what he wants/needs, and show him enough info to help him manage them as he does his PHP upgrade (or all the time).

[flixos90]

@joyously

The "disabling" should be the activation, not the installation or the plugin update. Given one choke point, it's easier to implement and more useful to the user, especially since the WP admin is not the only way to get a plugin installed.

I agree that activation is actually the critical part with this. However, there is hardly a benefit of allowing the user to install an incompatible plugin, only to see one step later that it does not work. The current approach aims at highlighting that immediately, so that the user isn't required to perform unnecessary steps before getting to that conclusion.

Preventing installation is also in line with preventing upgrades, which we will implement as well. When a plugin has an update which has changed its requirements, causing the plugin to no longer be compatible, we will prevent the update. The plugin may already be active, so our logic wouldn't fire if it was only on activation, and it wouldn't be helpful to update to that version either.

We will also implement what you are getting at, preventing activation of an incompatible plugin that has been installed in another way. This ticket here was simply taken at first, the rest will be iterations on the higher goal.

[flixos90]

I'd also like to highlight that we should re-evaluate our discussion result regarding the positioning of the notice next week: Some concerns had already been expressed about hiding the stats from the plugin card, a follow-up discussion on yesterday's meeting had some more thoughts (see ​https://wordpress.slack.com/archives/C60K3MP2Q/p1528132740000072).

The general approach for the copy of the plugin card notices still stands, we only need to determine the final wording (about which the above discussion is also worth reading).

[joyously]

I agree that activation is actually the critical part with this. However, there is hardly a benefit of allowing the user to install an incompatible plugin, only to see one step later that it does not work.

But there is a benefit: the user can prepare for the upgrade by installing what he needs first, then upgrading PHP, then activating the new plugins. Because after the upgrade, the warnings won't show him the plugins needed so easily. (Everything will look compatible, even the ones that he used to have which are not compatible.)

The current approach aims at highlighting that immediately, so that the user isn't required to perform unnecessary steps before getting to that conclusion.

Don't you see that the user needs to install before the upgrade? WP doesn't know when that will be. I'm not suggesting that the user is not warned of the incompatibility. I'm suggesting that the user should be able to install, but not allowed to activate.

Preventing installation is also in line with preventing upgrades, which we will implement as well.

I have the same concern there. The user should be able to update a plugin (seeing appropriate warnings), but not allowed to activate a mismatch. The logic for allowing should still be on activation, but different warnings would be shown for active or non-active plugins. I know this is on a different ticket, but I think it should all be handled in one place - activation.

[melchoyce]

Recommending some alternate copy (talked about it in Slack):

You can’t install this plugin because it doesn’t work with your version of WordPress. [Please update WordPress].

You can’t install this plugin because it doesn’t work with your version of PHP. [Learn more about updating PHP].

You can’t install this plugin because it doesn’t work with both your version of WordPress, and your version of PHP. [Please update WordPress], and then [Learn more about updating PHP].

[afragen]

Here's a link to a mockup of @melchoyce's text suggestions above.

​https://wordpress.slack.com/files/U02RQU03T/FB381GTA5/screenshot_01.png

[afragen]

This patch based upon #core-php meeting of 11 June 2018

[afragen]

Plugin card view - 11 Jun 2018 meeting

[afragen]

More Details view - 11 June 2018

[afragen]

Based upon feedback from today's meeting ​https://wordpress.slack.com/archives/C60K3MP2Q/p1528729248000798 the following patch is submitted 43986-final.diff​ .

It is based upon @melchoyce's final mockup. ​https://wordpress.slack.com/files/U02QJMG7R/FB48T5W7M/image.png

The following shows the plugin card with each type of message.

The following shows the More Details window.

Message precedence is for the WordPress message over the PHP message.

Please review and comment.

[flixos90]

Thanks for the updated patch @afragen!

A first round of code review:

• In the More Details view, when the required WordPress version is not met, please use the text as we discussed. In your current patch it still uses the less precise and less obvious text that is used in trunk at the moment ("This plugin has <strong>not been marked as compatible</strong> with your version of WordPress.", this can also be seen in your second screenshot).
• Try to simplify the checks that lead to $compatible_php a bit. The extra $tested_php variable is not necessary and makes the code hard to read. This applies to both class-wp-plugin-install-list-table.php and plugin-install.php. It could simply become: $compatible_php = empty( $api->requires_php ) || version_compare( substr( PHP_VERSION, 0, strlen( $api->requires_php ) ), $api->requires_php, '>=' ); In other words, when the no required PHP version is given, it should be considered compatible by definition.
• The checks for $can_install can then simply become $compatible_php && $compatible_wp.
• The checks for whether to show a notice about insufficient PHP version can simply become ! $compatible_php.
• Please use echo instead of print.
• Please use regular spacing instead of  .
• The localized strings with links are hard to read. In such cases where links are part of regular sentences, please include the anchor elements in the translatable string, and use placeholders for the URLs only. In the current patch, it is correct in plugin-install.php, but not in class-wp-plugin-install-list-table.php.
• Please pay particular attention to translator comments. They should have the form /* translators: %s: description */ when a single %s placeholder is present, or /* translators: 1: first description, 2: second description */ in case of multiple numbered placeholders.

[SergeyBiryukov]

• In the More Details view, maybe skip "Click here" and replace "upgrading" with "updating", for consistency with the language in the plugin card? "Learn more about updating PHP" should be enough.
• The third notice on screenshot_02.6.png​ looks a bit off, it wraps to a second line earlier than it has to. Looks like there's some extra padding on the right.
• The https://wordpress.org/support/upgrade-php URL needs to be translatable.

[afragen]

Working on the patch now.

@flixos90 thanks for the feedback.

@SergeyBiryukov the ServeHappy URL is has upgrade-php, shouldn't we use upgrade and not update?

Also, there is no extra padding, that's the result of small screen.

[afragen]

feedback applied

[afragen]

plugin card with feedback applied

[afragen]

More Details window with feedback applied

[afragen]

@flixos90 @SergeyBiryukov this patch 43986-final.4.diff​ should reflect the above feedback. It was much appreciated.

The following shows the plugin card with the patch applied and $wp_version = '4.0';.

The following shows the More Details window with the patch applied and $wp_version = '4.0';.

[afragen]

added check for $statusurl? back to plugin-install.php

[afragen]

indenting fixed

[afragen]

changed messaging text from 'upgrading' to 'updating'

[SergeyBiryukov]

Replying to joyously:

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.

It looks like your point is about finding a replacement for plugins that may not be compatible with a newer PHP version.

I understand the use case, however there's currently no guaranteed way of knowing whether a plugin is compatible with a newer PHP version. Per previous dicussions, the Requires PHP header only denotes the minimum required version, not the maximum supported version.

IIRC, the points that contributed to the decision were:

• While some outdated plugins can break on newer PHP versions, breakage after installing a newer plugin in an older environment is more common. Plugin authors should be able to use modern PHP without breaking sites.
• If we did have a field for the maximum supported version, it could quickly become outdated, and there would be no way of knowing if that's intentional, or the developer simply forgot to update it. We wouldn't want to give the user inaccurate information, and asking every plugin developer to follow PHP release history and update their plugins accordingly might be a bit too much.

This ticket is focused on another use case instead: searching for plugins compatible with the current PHP version, while giving an incentive to eventually update PHP.

As for older plugins that may not be compatible with a newer PHP version, the "safe mode" approach suggested in #44458 should help with identifying them and finding a replacement.

[joyously]

Replying to SergeyBiryukov:

It looks like your point is about finding a replacement for plugins that may not be compatible with a newer PHP version.

Thanks for trying to understand, but no, that's not quite it. My point is about finding replacement plugins, but it is the messaging and the timing that keeps getting lost. The current patch will show the PHP 5.3 user the plugins for PHP 7 as disabled, and he will have to write them down or something to find them again after his PHP upgrade. Before his upgrade, he will have to deactivate the ones that aren't compatible. Then after his upgrade, he will have to search again for those names he wrote down, and most plugins, even the ones he just deactivated, will not have any indication that there is a compatibility problem. Therefore, the disabling of the button will only make it more difficult for the user. It doesn't help at all.

This ticket is focused on another use case instead: searching for plugins compatible with the current PHP version, while giving an incentive to eventually update PHP.

The way it is now is a disincentive to update PHP. Since we only have the PHP minimum, we can only benefit the user on the lower version. That is precisely the one that needs to install plugins that need a higher version so that the upgrade goes smoothly.

As for older plugins that may not be compatible with a newer PHP version, the "safe mode" approach suggested in #44458 should help with identifying them and finding a replacement.

I am still hoping that Tide can help by providing a range of versions.

[SergeyBiryukov]

Replying to joyously:

The current patch will show the PHP 5.3 user the plugins for PHP 7 as disabled, and he will have to write them down or something to find them again after his PHP upgrade. Before his upgrade, he will have to deactivate the ones that aren't compatible.

How would they know which plugins aren't compatible with PHP 7 before actually trying to upgrade? What if there's no need to deactivate anything? If and when Tide provides this information, then we can reconsider the UX. For now, I'd suggest going with the current patch to get more feedback.

[joyously]

Replying to SergeyBiryukov:

How would they know which plugins aren't compatible with PHP 7 before actually trying to upgrade? What if there's no need to deactivate anything? If and when Tide provides this information, then we can reconsider the UX.

They won't know, but some of the plugins will be marked with a warning and a disabled install button (but only before the upgrade). They will have to run some version of Tide or the PHP Compatibility plugin to find out what is needed before they upgrade. All I'm saying is that they should not be blocked from installing (especially if there is a warning messge). It is the activation that is important.

[SergeyBiryukov]

In 43436:

Plugins: Disable "Install Now" button for plugins that require a higher version of PHP or WordPress.

Display a notice with an explanation and the steps required to resolve the issue.

Props afragen, schlessera, flixos90, nerrad, melchoyce, boemedia, hedgefield, joyously, johnalarcon, lakenh, afercia, acirujano, ibantxillo, SergeyBiryukov.
Fixes #43986.

[SergeyBiryukov]

Moving for 4.9.8 consideration.

[SergeyBiryukov]

Per yesterday's #core-php chat, before backporting this and other related tickets (#43987, #44350) the "Upgrading PHP" support page needs some more work so that it's not just a long wall of text.

P.S. ​https://make.wordpress.org/core/2018/07/17/servehappy-roadmap-update-and-priorities/

[afragen]

Fix links from upgrade-php to update-php

[SergeyBiryukov]

In 44420:

Plugins: Use newer "Updating PHP" page URL in the notice displayed when a plugin requires a higher PHP version.

Props afragen.
Fixes #43986. See #45686.

[flixos90]

In 44627:

Plugins: Use centralized API to display information about updating PHP when a plugin requires a higher version.

This changeset uses the API functions introduced in [44476] to link to the resource about updating PHP when highlighting a plugin's required PHP version is not met. It furthermore expands them, introducing a new wp_update_php_annotation() function that prints the markup to indicate that the default URL has been altered by the web host, allowing it to be reused universally.

Furthermore, this changeset adds missing update_php capability checks before displaying the information about updating PHP.

Props afragen.
Fixes #45986. See #43986, #45686.

[desrosj]

Dev note has been published: ​https://make.wordpress.org/core/2019/01/14/php-site-health-mechanisms-in-5-1/.

[flixos90]

In 44656:

Upgrade/Install: Make version_compare() calls for plugin required version checks more robust.

Props afragen.
Fixes #46024. See #43986.

[SergeyBiryukov]

In 45043:

Plugins: Disable "Update Now" button for plugins that require a higher version of PHP or WordPress.

This complements disabling the "Install Now" button in [43436].

Props afragen.
Fixes #46677. See #43986.

[apedog]

A small "install anyway (I understand the risks/discouraged)" link under the disabled button could address @joyously's point of not narrowing the scope of users' actions.
A user might want to download the plugin, knowing full well that activation will be postponed until after PHP/WP upgrade. This seems like the perfect solution that is compatible with both philosophies - 1. The issue is with activation, not with downloading 2. Discourage installation as early as possible - don't kick the can to the activation phase.

This would mean changing the "Cannot Install" text (as obviously you CAN install, you just can't activate). And perhaps the link would be a button - but styled as a link (I'm not that well-versed in a11y requirements/practices). It should be minor/discouraged anyway.