WordPress.org

Make WordPress Core

Opened 11 months ago

Closed 2 months ago

Last modified 2 months ago

#43986 closed task (blessed) (fixed)

Disable "Install Plugin" button for PHP required version mismatch

Reported by: schlessera Owned by: afragen
Milestone: 5.1 Priority: normal
Severity: major Version:
Component: Plugins 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 11 months 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 11 months 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 11 months 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 11 months 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 10 months ago.
screenshot_01.png (62.3 KB) - added by afragen 10 months ago.
This is what patch will display.
43986-1.diff (1.8 KB) - added by afragen 10 months ago.
This should cleanly apply.
43986-2.diff (1.7 KB) - added by afragen 10 months ago.
Updated patch to account for results of add plugin search
43986-3.diff (1.7 KB) - added by afragen 10 months ago.
Just a fix for proper spacing. No other differences from 43986-2.diff
screenshot_01.2.png (64.9 KB) - added by afragen 10 months ago.
Current PHP version information added
screenshot_02.png (65.8 KB) - added by afragen 10 months ago.
More information here
screenshot_01.3.png (66.2 KB) - added by afragen 10 months 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 10 months ago.
This patch removes the extra stuff from the plugin action links and adds it to the bottom of the plugin card via a new action hook.
screenshot_01.4.png (45.4 KB) - added by johnalarcon 10 months ago.
screenshot_02.2.png (62.6 KB) - added by afragen 10 months ago.
43986v2-2.diff (5.5 KB) - added by afragen 10 months ago.
Simplifies message and adds color, but CSS needs to be built.
screenshot_03.png (61.5 KB) - added by afragen 10 months ago.
minimal words
43986v2-3.diff (5.4 KB) - added by afragen 10 months ago.
This patch has fewest words.
43986v2-4.diff (5.5 KB) - added by afragen 10 months 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 10 months ago.
43986.2.more-details.PNG (67.4 KB) - added by SergeyBiryukov 10 months ago.
43986.2.diff (7.8 KB) - added by SergeyBiryukov 10 months ago.
43986.3.diff (6.8 KB) - added by SergeyBiryukov 10 months ago.
43986.3.plugin-list.PNG (70.9 KB) - added by SergeyBiryukov 10 months ago.
43986.3.more-details.PNG (67.0 KB) - added by SergeyBiryukov 10 months ago.
screenshot_02.3.png (414.3 KB) - added by afragen 10 months ago.
more details of 43986v2-5.diff
43986v2-5.diff (9.5 KB) - added by afragen 10 months ago.
add aria-labels everywhere, fixes the 'more details' iframe
43986v2-6.diff (9.5 KB) - added by afragen 10 months ago.
fixed aria-label text for WordPress compatibility to make more sense
43986v2-7.diff (9.5 KB) - added by afragen 10 months ago.
improve wording of aria-labels
43986v2-8.diff (10.4 KB) - added by afragen 10 months ago.
added is_php_compatible() function and use it along with is_wordpress_compatible()
43986v3-1.diff (7.2 KB) - added by afragen 10 months 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 10 months ago.
2 lines on plugin card
screenshot_03.2.png (173.0 KB) - added by afragen 10 months ago.
Example WordPress incompat
screenshot_04.png (396.2 KB) - added by afragen 10 months ago.
WP good, PHP bad
43986v3-2.diff (6.9 KB) - added by afragen 10 months ago.
No more untested PHP notices.
43986v3-3.diff (7.8 KB) - added by afragen 10 months 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 10 months 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 10 months 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 10 months ago.
plugin card in truck
screenshot_08.png (110.7 KB) - added by afragen 10 months ago.
More Details in trunk
plugin-install-error.jpg (78.5 KB) - added by boemedia 10 months ago.
43986v4.1.diff (9.6 KB) - added by afragen 10 months ago.
Design feedback with card bottom replaced.
screenshot_11.png (117.3 KB) - added by afragen 10 months ago.
plugin card with design feedback re: bottom info replacement
screenshot_12.png (400.2 KB) - added by afragen 10 months ago.
More Details window. No real changes from design.
43986v4.2.diff (9.6 KB) - added by afragen 10 months 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 10 months ago.
An alternate idea where the bottom information isn't obscured.
43986v5.1.diff (9.7 KB) - added by afragen 10 months ago.
Design style #2, displays plugin info, 2 lines
screenshot_14.png (136.3 KB) - added by afragen 10 months ago.
Design style #2
43986v4.3.diff (9.6 KB) - added by afragen 10 months ago.
updated aria-label
43986v5.2.diff (9.7 KB) - added by afragen 10 months ago.
updated aria-label
43986v4.4.diff (9.6 KB) - added by afragen 10 months ago.
updated patch based upon #core-php meeting 4 June 2018
screenshot_01.5.png (117.4 KB) - added by afragen 10 months ago.
plugin card with $wp_version set to 3.7
screenshot_02.5.png (427.2 KB) - added by afragen 10 months ago.
More Details window with $wp_version set to 3.7
screenshot_03.3.png (116.3 KB) - added by afragen 10 months ago.
latest patch running trunk
43986-final.diff (10.1 KB) - added by afragen 9 months ago.
This patch based upon #core-php meeting of 11 June 2018
screenshot_02.6.png (188.2 KB) - added by afragen 9 months ago.
Plugin card view - 11 Jun 2018 meeting
screenshot_05.2.png (151.6 KB) - added by afragen 9 months ago.
More Details view - 11 June 2018
43986-final.2.diff (9.8 KB) - added by afragen 9 months ago.
feedback applied
screenshot_01.6.png (266.8 KB) - added by afragen 9 months ago.
plugin card with feedback applied
screenshot_02.7.png (170.2 KB) - added by afragen 9 months ago.
More Details window with feedback applied
43986-final.3.diff (9.8 KB) - added by afragen 9 months ago.
added check for $statusurl? back to plugin-install.php
43986-final.4.diff (10.0 KB) - added by afragen 9 months ago.
indenting fixed
43986-final.5.diff (10.0 KB) - added by afragen 9 months ago.
changed messaging text from 'upgrading' to 'updating'
43986-link-update.diff (2.2 KB) - added by afragen 3 months ago.
Fix links from upgrade-php to update-php

Change History (165)

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

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

#3 @afragen
11 months ago

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

#4 @Luciano Croce
10 months ago

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

@afragen
10 months ago

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


10 months ago

@afragen
10 months ago

This is what patch will display.

@afragen
10 months ago

This should cleanly apply.

#7 @afragen
10 months ago

Somehow need to hook into AJAX search results.

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

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

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


10 months ago

@afragen
10 months ago

Updated patch to account for results of add plugin search

@afragen
10 months ago

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

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

Current PHP version information added

#11 @afragen
10 months ago

@joyously we could do something like the above.

@afragen
10 months ago

More information here

#12 @afragen
10 months ago

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

#13 @afragen
10 months ago

Perhaps only displaying the required PHP version would be simplest.

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

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

#16 @afragen
10 months ago

@joyously how about this one 👆

@afragen
10 months ago

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

#17 @Luciano Croce
10 months ago

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

#18 follow-up: @afragen
10 months ago

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

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

#19 in reply to: ↑ 18 @Luciano Croce
10 months 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 10 months ago by Luciano Croce (previous) (diff)

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

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

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

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

I’ll adjust the patch accordingly.

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

@afragen
10 months ago

minimal words

@afragen
10 months ago

This patch has fewest words.

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

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

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

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

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

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!

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

@afragen
10 months ago

more details of 43986v2-5.diff

@afragen
10 months ago

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

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

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

@afragen
10 months ago

improve wording of aria-labels

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


10 months ago

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


10 months ago

@afragen
10 months ago

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

@afragen
10 months ago

2 lines on plugin card

@afragen
10 months ago

Example WordPress incompat

@afragen
10 months ago

WP good, PHP bad

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

No more untested PHP notices.

@afragen
10 months ago

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

@afragen
10 months ago

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

@afragen
10 months ago

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

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

@afragen
10 months ago

plugin card in truck

@afragen
10 months ago

More Details in trunk

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


10 months ago

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


10 months ago

#41 @boemedia
10 months 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.


10 months ago

@afragen
10 months ago

Design feedback with card bottom replaced.

@afragen
10 months ago

plugin card with design feedback re: bottom info replacement

@afragen
10 months ago

More Details window. No real changes from design.

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

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


10 months ago

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


10 months ago

#46 follow-up: @lakenh
10 months 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
10 months 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.


10 months ago

@melchoyce
10 months ago

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

@afragen
10 months ago

Design style #2, displays plugin info, 2 lines

@afragen
10 months ago

Design style #2

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

@afragen
10 months ago

updated aria-label

@afragen
10 months ago

updated aria-label

#49 in reply to: ↑ 46 @afragen
10 months 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
10 months ago

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

#51 @afercia
10 months 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.


10 months ago

#53 follow-up: @acirujano
10 months 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
10 months 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.


10 months ago

#56 follow-ups: @joyously
10 months ago

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

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

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

@afragen
10 months ago

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

@afragen
10 months ago

plugin card with $wp_version set to 3.7

@afragen
10 months ago

More Details window with $wp_version set to 3.7

@afragen
10 months ago

latest patch running trunk

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


10 months ago

#59 in reply to: ↑ 56 ; follow-up: @joyously
10 months 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
10 months 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 10 months ago by afragen (previous) (diff)

#61 @joyously
10 months 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
10 months 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
10 months 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
10 months 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
10 months 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
10 months 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.


10 months ago

#68 @melchoyce
10 months 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.


10 months ago

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


10 months ago

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


9 months ago

#73 @flixos90
9 months ago

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

@afragen
9 months ago

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

@afragen
9 months ago

Plugin card view - 11 Jun 2018 meeting

@afragen
9 months ago

More Details view - 11 June 2018

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

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


9 months ago

#76 @flixos90
9 months 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
9 months 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 9 months ago by SergeyBiryukov (previous) (diff)

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

feedback applied

@afragen
9 months ago

plugin card with feedback applied

@afragen
9 months ago

More Details window with feedback applied

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

@afragen
9 months ago

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

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


9 months ago

@afragen
9 months ago

indenting fixed

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


9 months ago

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


9 months ago

#83 @boemedia
9 months ago

  • Keywords ux-feedback added

@afragen
9 months ago

changed messaging text from 'upgrading' to 'updating'

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


9 months ago

#85 in reply to: ↑ 56 ; follow-up: @SergeyBiryukov
9 months 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
9 months 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
9 months 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
9 months 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
9 months 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
9 months 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.


9 months ago

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


8 months ago

#93 @SergeyBiryukov
8 months 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 8 months ago by SergeyBiryukov (previous) (diff)

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


7 months ago

#95 @pento
5 months ago

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

@afragen
3 months ago

Fix links from upgrade-php to update-php

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


3 months ago

#97 @SergeyBiryukov
2 months 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.


2 months ago

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

In 44656:

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

Props afragen.
Fixes #46024. See #43986.

Note: See TracTickets for help on using tickets.