Make WordPress Core

Opened 6 years ago

Closed 6 years ago

Last modified 5 years ago

#43986 closed task (blessed) (fixed)

Disable "Install Plugin" button for PHP required version mismatch

Reported by: schlessera's profile schlessera Owned by: afragen's profile afragen
Milestone: 5.1 Priority: normal
Severity: major Version:
Component: Site Health Keywords: needs-unit-tests servehappy has-patch ux-feedback has-dev-note
Focuses: Cc:

Description

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.

Attachments (64)

WHIP core - add plugin page.png (268.1 KB) - added by schlessera 6 years ago.
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.
WHIP core - plugin detail backend.png (383.6 KB) - added by schlessera 6 years ago.
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)
WHIP core - plugin detail backend2 (1).png (430.1 KB) - added by schlessera 6 years ago.
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.
WHIP core - add plugin page2.png (260.7 KB) - added by schlessera 6 years ago.
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.
43986.diff (1.8 KB) - added by afragen 6 years ago.
screenshot_01.png (62.3 KB) - added by afragen 6 years ago.
This is what patch will display.
43986-1.diff (1.8 KB) - added by afragen 6 years ago.
This should cleanly apply.
43986-2.diff (1.7 KB) - added by afragen 6 years ago.
Updated patch to account for results of add plugin search
43986-3.diff (1.7 KB) - added by afragen 6 years ago.
Just a fix for proper spacing. No other differences from 43986-2.diff
screenshot_01.2.png (64.9 KB) - added by afragen 6 years ago.
Current PHP version information added
screenshot_02.png (65.8 KB) - added by afragen 6 years ago.
More information here
screenshot_01.3.png (66.2 KB) - added by afragen 6 years ago.
This uses a new action hook to add text to the plugin card bottom. Also removes info below disabled install link.
43986v2-1.diff (2.8 KB) - added by afragen 6 years ago.
This patch removes the extra stuff from the plugin action links and adds it to the bottom of the plugin card via a new action hook.
screenshot_01.4.png (45.4 KB) - added by johnalarcon 6 years ago.
screenshot_02.2.png (62.6 KB) - added by afragen 6 years ago.
43986v2-2.diff (5.5 KB) - added by afragen 6 years ago.
Simplifies message and adds color, but CSS needs to be built.
screenshot_03.png (61.5 KB) - added by afragen 6 years ago.
minimal words
43986v2-3.diff (5.4 KB) - added by afragen 6 years ago.
This patch has fewest words.
43986v2-4.diff (5.5 KB) - added by afragen 6 years ago.
Oops, now includes something if PHP is compatible. PHP shown as compatible if no requirement listed.
43986.2.plugin-list.PNG (72.6 KB) - added by SergeyBiryukov 6 years ago.
43986.2.more-details.PNG (67.4 KB) - added by SergeyBiryukov 6 years ago.
43986.2.diff (7.8 KB) - added by SergeyBiryukov 6 years ago.
43986.3.diff (6.8 KB) - added by SergeyBiryukov 6 years ago.
43986.3.plugin-list.PNG (70.9 KB) - added by SergeyBiryukov 6 years ago.
43986.3.more-details.PNG (67.0 KB) - added by SergeyBiryukov 6 years ago.
screenshot_02.3.png (414.3 KB) - added by afragen 6 years ago.
more details of 43986v2-5.diff
43986v2-5.diff (9.5 KB) - added by afragen 6 years ago.
add aria-labels everywhere, fixes the 'more details' iframe
43986v2-6.diff (9.5 KB) - added by afragen 6 years ago.
fixed aria-label text for WordPress compatibility to make more sense
43986v2-7.diff (9.5 KB) - added by afragen 6 years ago.
improve wording of aria-labels
43986v2-8.diff (10.4 KB) - added by afragen 6 years ago.
added is_php_compatible() function and use it along with is_wordpress_compatible()
43986v3-1.diff (7.2 KB) - added by afragen 6 years ago.
Hard-coded, but with individual notices ( WordPress and PHP) for both plugin card and More Details iframe.
screenshot_02.4.png (214.3 KB) - added by afragen 6 years ago.
2 lines on plugin card
screenshot_03.2.png (173.0 KB) - added by afragen 6 years ago.
Example WordPress incompat
screenshot_04.png (396.2 KB) - added by afragen 6 years ago.
WP good, PHP bad
43986v3-2.diff (6.9 KB) - added by afragen 6 years ago.
No more untested PHP notices.
43986v3-3.diff (7.8 KB) - added by afragen 6 years ago.
Added color to icons (since they're present), reverse order of precedence for PHP then WordPress notices
screenshot_05.png (178.8 KB) - added by afragen 6 years ago.
set $wp_version = '3.7' to see this. Used to show all most variability, only WP untested not shown.
screenshot_06.png (116.0 KB) - added by afragen 6 years ago.
More Details page with 2 messages. Again set $wp_version = '3.7' to see this.
screenshot_07.png (173.7 KB) - added by afragen 6 years ago.
plugin card in truck
screenshot_08.png (110.7 KB) - added by afragen 6 years ago.
More Details in trunk
plugin-install-error.jpg (78.5 KB) - added by boemedia 6 years ago.
43986v4.1.diff (9.6 KB) - added by afragen 6 years ago.
Design feedback with card bottom replaced.
screenshot_11.png (117.3 KB) - added by afragen 6 years ago.
plugin card with design feedback re: bottom info replacement
screenshot_12.png (400.2 KB) - added by afragen 6 years ago.
More Details window. No real changes from design.
43986v4.2.diff (9.6 KB) - added by afragen 6 years ago.
oops forgot a commit in the last patch. Shouldn't be functionally different but one less conditional.
image (1).png (450.6 KB) - added by melchoyce 6 years ago.
An alternate idea where the bottom information isn't obscured.
43986v5.1.diff (9.7 KB) - added by afragen 6 years ago.
Design style #2, displays plugin info, 2 lines
screenshot_14.png (136.3 KB) - added by afragen 6 years ago.
Design style #2
43986v4.3.diff (9.6 KB) - added by afragen 6 years ago.
updated aria-label
43986v5.2.diff (9.7 KB) - added by afragen 6 years ago.
updated aria-label
43986v4.4.diff (9.6 KB) - added by afragen 6 years ago.
updated patch based upon #core-php meeting 4 June 2018
screenshot_01.5.png (117.4 KB) - added by afragen 6 years ago.
plugin card with $wp_version set to 3.7
screenshot_02.5.png (427.2 KB) - added by afragen 6 years ago.
More Details window with $wp_version set to 3.7
screenshot_03.3.png (116.3 KB) - added by afragen 6 years ago.
latest patch running trunk
43986-final.diff (10.1 KB) - added by afragen 6 years ago.
This patch based upon #core-php meeting of 11 June 2018
screenshot_02.6.png (188.2 KB) - added by afragen 6 years ago.
Plugin card view - 11 Jun 2018 meeting
screenshot_05.2.png (151.6 KB) - added by afragen 6 years ago.
More Details view - 11 June 2018
43986-final.2.diff (9.8 KB) - added by afragen 6 years ago.
feedback applied
screenshot_01.6.png (266.8 KB) - added by afragen 6 years ago.
plugin card with feedback applied
screenshot_02.7.png (170.2 KB) - added by afragen 6 years ago.
More Details window with feedback applied
43986-final.3.diff (9.8 KB) - added by afragen 6 years ago.
added check for $statusurl? back to plugin-install.php
43986-final.4.diff (10.0 KB) - added by afragen 6 years ago.
indenting fixed
43986-final.5.diff (10.0 KB) - added by afragen 6 years ago.
changed messaging text from 'upgrading' to 'updating'
43986-link-update.diff (2.2 KB) - added by afragen 6 years ago.
Fix links from upgrade-php to update-php

Change History (168)

@schlessera
6 years ago

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

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

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

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.

#1 @afragen
6 years ago

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?

#2 @flixos90
6 years ago

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

#3 @afragen
6 years ago

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

#4 @Luciano Croce
6 years ago

  • Keywords dev-feedback added
  • Severity changed from normal to major

@afragen
6 years ago

#5 @afragen
6 years ago

  • Keywords has-patch added; needs-patch removed

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

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


6 years ago

@afragen
6 years ago

This is what patch will display.

@afragen
6 years ago

This should cleanly apply.

#7 @afragen
6 years ago

Somehow need to hook into AJAX search results.

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

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

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


6 years ago

@afragen
6 years ago

Updated patch to account for results of add plugin search

@afragen
6 years ago

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

#9 @joyously
6 years ago

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?

#10 @afragen
6 years ago

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

Current PHP version information added

#11 @afragen
6 years ago

@joyously we could do something like the above.

@afragen
6 years ago

More information here

#12 @afragen
6 years ago

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

#13 @afragen
6 years ago

Perhaps only displaying the required PHP version would be simplest.

#14 @joyously
6 years ago

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

#15 @afragen
6 years ago

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

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

#16 @afragen
6 years ago

@joyously how about this one 👆

@afragen
6 years ago

This patch removes the extra stuff from the plugin action links and adds it to the bottom of the plugin card via a new action hook.

#17 @Luciano Croce
6 years ago

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

#18 follow-up: @afragen
6 years ago

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

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

#19 in reply to: ↑ 18 @Luciano Croce
6 years ago

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.

Last edited 6 years ago by Luciano Croce (previous) (diff)

#20 @johnalarcon
6 years ago

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.

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

#21 @afragen
6 years ago

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

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

#22 @johnalarcon
6 years ago

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.

#23 @afragen
6 years ago

I’ll adjust the patch accordingly.

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

@afragen
6 years ago

minimal words

@afragen
6 years ago

This patch has fewest words.

#24 @afragen
6 years ago

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

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

#25 @afragen
6 years ago

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.

#26 @johnalarcon
6 years ago

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

#27 @SergeyBiryukov
6 years ago

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

#28 @johnalarcon
6 years ago

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

#29 @schlessera
6 years ago

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

#30 @SergeyBiryukov
6 years ago

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.

#31 @afragen
6 years ago

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

@schlessera If we prevent users from not being able to install plugins that don’t contain, or don’t correctly contain, specific values we can have many plugins that will no longer update or install.

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

Thanks for the great feedback!

Version 0, edited 6 years ago by afragen (next)

@afragen
6 years ago

more details of 43986v2-5.diff

@afragen
6 years ago

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

#32 @afragen
6 years ago

@schlessera

minimal words

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

more details of 43986v2-5.diff

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

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

@afragen
6 years ago

improve wording of aria-labels

@afragen
6 years ago

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

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


6 years ago

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


6 years ago

@afragen
6 years ago

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

@afragen
6 years ago

2 lines on plugin card

@afragen
6 years ago

Example WordPress incompat

@afragen
6 years ago

WP good, PHP bad

#35 @afragen
6 years ago

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

2 lines on plugin card

Shows two line in the plugin card.

Example WordPress incompat

Shows separate notices in the 'More Details' iframe.

WP good, PHP bad

Shows when compatibility exists, no notice is displayed.

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

#36 @flixos90
6 years ago

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.

#37 @nerrad
6 years ago

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

No more untested PHP notices.

@afragen
6 years ago

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

@afragen
6 years ago

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

@afragen
6 years ago

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

#38 @afragen
6 years ago

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.

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

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

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

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

plugin card in truck

Plugin card in trunk

More Details in trunk

More Details page in trunk

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

@afragen
6 years ago

plugin card in truck

@afragen
6 years ago

More Details in trunk

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


6 years ago

This ticket was mentioned in Slack in #design by michelemiz. View the logs.


6 years ago

#41 @boemedia
6 years ago

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.


This ticket was mentioned in Slack in #design by afragen. View the logs.


6 years ago

@afragen
6 years ago

Design feedback with card bottom replaced.

@afragen
6 years ago

plugin card with design feedback re: bottom info replacement

@afragen
6 years ago

More Details window. No real changes from design.

#43 @afragen
6 years ago

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.
plugin card with design feedback re: bottom info replacement

Below is how the More Details window looks.
More Details window. No real changes from design.

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

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


6 years ago

This ticket was mentioned in Slack in #design by afragen. View the logs.


6 years ago

#46 follow-up: @lakenh
6 years ago

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

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

This ticket was mentioned in Slack in #accessibility by lakenh. View the logs.


6 years ago

@melchoyce
6 years ago

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

@afragen
6 years ago

Design style #2, displays plugin info, 2 lines

@afragen
6 years ago

Design style #2

#48 @afragen
6 years ago

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

Design style #2

More Details window hasn't changed.

@melchoyce here's the second version.

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

@afragen
6 years ago

updated aria-label

@afragen
6 years ago

updated aria-label

#49 in reply to: ↑ 46 @afragen
6 years ago

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.

#50 @afercia
6 years ago

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

#51 @afercia
6 years ago

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.

This ticket was mentioned in Slack in #design by acirujano. View the logs.


6 years ago

#53 follow-up: @acirujano
6 years ago

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!

#54 in reply to: ↑ 53 @ibantxillo
6 years ago

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!

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


6 years ago

#56 follow-ups: @joyously
6 years ago

It is my hope that decisions on the user interface keep in mind what the user is doing when this Install plugin button is disabled. This really only affects those sites with a lower version of PHP than the plugin has. But there could be plugins that are on the bleeding edge oh PHP that the user is not interested in.

The first step in upgrading PHP (beyond understanding the concepts) is to determine if the plugins and theme will work on the new version. For this, the user needs to see the numbers because he's looking before the upgrade. The user has to choose plugins that will work with a different version than his current version. Then he has to upgrade, and then he has to switch to those plugins he found. (Or install the plugins, but not activate yet.)

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

@afragen
6 years ago

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

@afragen
6 years ago

plugin card with $wp_version set to 3.7

@afragen
6 years ago

More Details window with $wp_version set to 3.7

@afragen
6 years ago

latest patch running trunk

#57 @afragen
6 years ago

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.

plugin card with $wp_version set to 3.7

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

More Details window with $wp_version set to 3.7

This how the plugin card looks when running trunk.

latest patch running trunk

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

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


6 years ago

#59 in reply to: ↑ 56 ; follow-up: @joyously
6 years ago

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.

#60 in reply to: ↑ 59 @afragen
6 years ago

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.

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

#61 @joyously
6 years ago

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

#62 @nerrad
6 years ago

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.

#63 @joyously
6 years ago

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

#64 @flixos90
6 years ago

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

#65 @flixos90
6 years ago

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

#66 @joyously
6 years ago

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.

This ticket was mentioned in Slack in #design by melchoyce. View the logs.


6 years ago

#68 @melchoyce
6 years ago

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

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


6 years ago

This ticket was mentioned in Slack in #design by joshuawold. View the logs.


6 years ago

#71 @afragen
6 years ago

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

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

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


6 years ago

#73 @flixos90
6 years ago

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

@afragen
6 years ago

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

@afragen
6 years ago

Plugin card view - 11 Jun 2018 meeting

@afragen
6 years ago

More Details view - 11 June 2018

#74 @afragen
6 years ago

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.

Plugin card view - 11 Jun 2018 meeting

The following shows the More Details window.

More Details view - 11 June 2018

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

Please review and comment.

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

This ticket was mentioned in Slack in #design by afragen. View the logs.


6 years ago

#76 @flixos90
6 years ago

  • Keywords dev-feedback removed

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 &nbsp;.
  • 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.

#77 @SergeyBiryukov
6 years ago

  • 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.
Last edited 6 years ago by SergeyBiryukov (previous) (diff)

#78 @afragen
6 years ago

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

feedback applied

@afragen
6 years ago

plugin card with feedback applied

@afragen
6 years ago

More Details window with feedback applied

#79 @afragen
6 years ago

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

plugin card with feedback applied

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

More Details window with feedback applied

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

@afragen
6 years ago

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

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


6 years ago

@afragen
6 years ago

indenting fixed

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


6 years ago

This ticket was mentioned in Slack in #design by joyously. View the logs.


6 years ago

#83 @boemedia
6 years ago

  • Keywords ux-feedback added

@afragen
6 years ago

changed messaging text from 'upgrading' to 'updating'

This ticket was mentioned in Slack in #design by boemedia. View the logs.


6 years ago

#85 in reply to: ↑ 56 ; follow-up: @SergeyBiryukov
6 years ago

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.

#86 in reply to: ↑ 85 ; follow-up: @joyously
6 years ago

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.

#87 in reply to: ↑ 86 ; follow-up: @SergeyBiryukov
6 years ago

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.

#88 in reply to: ↑ 87 @joyously
6 years ago

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.

#89 @SergeyBiryukov
6 years ago

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

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.

#90 @SergeyBiryukov
6 years ago

  • Keywords fixed-major added
  • Milestone changed from 5.0 to 4.9.8
  • Resolution fixed deleted
  • Status changed from closed to reopened

Moving for 4.9.8 consideration.

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


6 years ago

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


6 years ago

#93 @SergeyBiryukov
6 years ago

  • Milestone changed from 4.9.8 to 4.9.9

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/

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

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


6 years ago

#95 @pento
6 years ago

  • Keywords fixed-major removed
  • Milestone changed from 4.9.9 to 5.1

@afragen
6 years ago

Fix links from upgrade-php to update-php

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


6 years ago

#97 @SergeyBiryukov
6 years ago

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

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.

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


6 years ago

#99 @flixos90
6 years ago

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.

#101 @flixos90
6 years ago

In 44656:

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

Props afragen.
Fixes #46024. See #43986.

#102 @SergeyBiryukov
6 years ago

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.

#103 @apedog
6 years ago

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.

#104 @spacedmonkey
5 years ago

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