WordPress.org

Make WordPress Core

Opened 8 months ago

Last modified 9 days ago

#41191 assigned enhancement

Create browse happy type notice for PHP versions

Reported by: joostdevalk Owned by: flixos90
Milestone: 5.0 Priority: normal
Severity: normal Version:
Component: General Keywords: has-patch has-unit-tests 2nd-opinion
Focuses: Cc:

Description (last modified by joostdevalk)

For tons of reasons we want people to upgrade their PHP versions, preferably to PHP7. While historically we've never bothered users with this, the Yoast WHIP project has proven that doing so can actually change the statistics in a meaningful way, both because users act and because hosts become more active when pushed harder.

There's prior art for notices about PHP, both in Joomla and Drupal:

https://www.drupal.org/node/2670966
https://image.ibb.co/gFa8MQ/wwww.png

I would argue we should take a more positive approach than they do and focus on the speed benefits of PHP7.

To do this, we would:

  1. Introduce notices that would tell people to upgrade their PHP.
  2. Link those to explanatory page that tell people what PHP is and why they should care.
  3. Link to pages that show them how to upgrade (preferably host specific if we can).
  4. Give them email examples of emails they can send their host if it didn't work out.
  5. Send them to the WordPress hosting page if all else fails.

Let's start by fleshing out # 1, I've already got my content team working on # 2 as well. @hedgefield already had some ideas, I'll ask him to add them here :)

Attachments (8)

WHIP core2.png (208.3 KB) - added by hedgefield 8 months ago.
Here's an idea for how we could present this notice. I've adapted the text from the Yoast WHIP notice for the Wordpress audience, and styled it like the Welcome widget on the WP dashboard. This could be the 'worst version' of the notice for people on 5.2, and it could get progressively more benign the closer to PHP7 someone is.
WHIP core3.png (177.3 KB) - added by hedgefield 8 months ago.
Here's another (smaller) take where most background information is deferred to the page with the instructions. We should also make a page that explains exactly what PHP is and why it is important, for people who have no idea what we mean. I added a link to that in the copy of this mockup too.
ServeHappy notice WP backend.png (105.3 KB) - added by hedgefield 6 weeks ago.
Backend notification
ServeHappy Page_Collapsed panels.png (461.8 KB) - added by hedgefield 6 weeks ago.
Quick mockup of a landing page with the explanation and instructions
ServeHappy Page_Expanded panels.png (1.7 MB) - added by hedgefield 6 weeks ago.
Mockup of the landing page with the sections expanded
41191.diff (10.3 KB) - added by flixos90 2 weeks ago.
41191.2.diff (10.3 KB) - added by flixos90 12 days ago.
41191.3.diff (5.3 KB) - added by flixos90 9 days ago.

Change History (46)

#1 @joostdevalk
8 months ago

  • Description modified (diff)

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


8 months ago

@hedgefield
8 months ago

Here's an idea for how we could present this notice. I've adapted the text from the Yoast WHIP notice for the Wordpress audience, and styled it like the Welcome widget on the WP dashboard. This could be the 'worst version' of the notice for people on 5.2, and it could get progressively more benign the closer to PHP7 someone is.

@hedgefield
8 months ago

Here's another (smaller) take where most background information is deferred to the page with the instructions. We should also make a page that explains exactly what PHP is and why it is important, for people who have no idea what we mean. I added a link to that in the copy of this mockup too.

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


8 months ago

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


8 months ago

#5 @psykro
8 months ago

I'm very keen on informing and pushing users to upgrade (or get their hosts to upgrade) their PHP versions. A few thoughts on this

  1. How would we go about creating host specific links. Are we able to determine what host a WordPress site is installed on?
  2. The notifications @hedgefield has posted look good, but I wonder if they will clutter up the admin notices, perhaps just the 'Your site could run faster' message with link that opens the content below it?

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


8 months ago

#7 @psykro
8 months ago

The following came out of the discussion of this ticket in the #core-php Slack channel

  • We'd like to show a notice to recommend jump to PHP >= 5.6 (even better >= 7.0).
  • We'd like to show that notice first for only 5.2 users, but then iterate over time to show it, up until we reach 5.5.
  • Once number of 5.2 users is low enough, we bump WP core's minimum requirement to 5.3. Then over time, we do that further until we reach 5.6.

#8 follow-up: @chesio
7 months ago

Once number of 5.2 users is low enough

I'm curious whether there's any actual number behind "low enough"... :)

#9 in reply to: ↑ 8 @jdgrimes
7 months ago

Replying to chesio:

Once number of 5.2 users is low enough

I'm curious whether there's any actual number behind "low enough"... :)

No. That will likely be discussed at a future meeting in the #core-php channel in Slack. (Meetings each Monday at 18:00 UTC.)

#10 @casiepa
7 months ago

It seems currently 4.6% of WP installs is still using 5.2, it would indeed be nice to set a target % when to tackle the higher version(s).
I must say to be very surprised that only 52.5% is on PHP 5.6 or higher. I would have expect that one to be much higher seeing the performance gains.

Following closely!

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


7 months ago

#12 @chesio
7 months ago

It seems currently 4.6% of WP installs is still using 5.2

Coincidentally, ~4.3% of WP installs run WordPress 3.6 or older (ie. 4+ years old and without automatic background updates option that has been introduced in 3.7 as far as I know).

The 4.6% is still too big number to ignore, but I think more reasonable way to make decisions based on these stats is to apply them only to WordPress installs that are "actively maintained". We can argue what "actively maintained" means, but I don't believe that someone suddenly decides to hit the "Update WordPress" button after not doing so in 4+ years...

#13 @flixos90
7 months ago

While I certainly like this idea, I think showing a very prominent notice to users should be the last step though on our way to making users upgrade their PHP version.

For example I consider #40934 more important as it is a more organic way to push users to a higher version. When they see a plugin won't work any longer, they know for fact they have a problem and are more likely to make efforts. Performance and security are both rather abstract arguments to users.

This notice considered here will likely make more people upgrade, but it will also be possibly annoying, not give a user a reason they can fully grasp. I think less aggressive solutions should be the first step.

#14 @rklrkl
7 months ago

I'll mention here that the Yoast notice about PHP being "out of date" was poorly done on several levels:

  • Far too large a notice (15 or so lines!) - should have been a 1 or 2 line banner with a link to read more about the issue.
  • It was undismissable, which was frankly appalling. If it must re-appear at some point, have it appear once a month or when the Yoast plugin is updated again.
  • The text made some highly dubious statements like "your version of PHP no longer receives security updates" (not true - CentOS backports security updates and that's what we are running) and "they [hosters] don't dare to do that [upgrade] because they're afraid they'll break your site" (we went through a PHP 5.3.3 -> 5.6.31 upgrade recently and it completely broke a site in such a manner we had to move that site back to an earlier PHP - it was literally unfixable with 5.6.31. So it's not being "afraid" that's the issue - we jumped right in there - it's the fact that sites *do* break on PHP upgrades).

I think my main concern here is that no-one's discussing LTS releases here like RHEL/CentOS that backport PHP fixes from later releases, but keep the base version the same. They'll get hit with messages telling them their 5.3.3 (RHEL/Centos 6) PHP is out of date when in fact it isn't. Yes, they can use the IUS repo (maybe WordPress should have docs on how to upgrade PHP on various platforms if they're going to push PHP upgrade notices? At least the notices can then link to the appropriate docs page for the platform), but the IUS repo is what broke one of our sites, so it's not a guarantee at all that things will work after an upgrade.

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


6 months ago

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


5 months ago

#17 @ottok
2 months ago

I think this is a great idea. I agree to most in #comment:14 regarding that we need to consider that on RedHat 6 the old PHP 5.3 version still does get security updates, and that the notification should be dismissable.

There has not been any activity on this for 4 months. Why hasn't the idea been blessed already? Is there a patch / git branch somewhere?

This is something we would like to contribute to, but the issue has no owner and no concrete channel where we could focus our energy to get progress. I hope some core devs could facilitate here a bit. Greetings from the WC Athens Contributor day.

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


2 months ago

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


2 months ago

#20 @schlessera
2 months ago

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

I take on ownership for this ticket, as I intend to push for making progress in the coming weeks.

#21 @schlessera
2 months ago

@ottok This is being discussed in the #core-php channel. We meet once per week to move the "servehappy" project forward, of which this is one part. You can find summaries of our meetings here: https://make.wordpress.org/core/tag/core-php/

#22 @ottok
2 months ago

@schlessera I attended the meeting on Dec 11th, but I don't have time to attend it weekly. Nice to see progress on this one!

@hedgefield
6 weeks ago

Backend notification

@hedgefield
6 weeks ago

Quick mockup of a landing page with the explanation and instructions

@hedgefield
6 weeks ago

Mockup of the landing page with the sections expanded

#23 @hedgefield
6 weeks ago

At the request of @schlessera I adjusted the backend notification mockup to have a single CTA that goes to a landing page somewhere in the wordpress ecosystem with the information and instructions (for which we also made a quick mockup). Since the draft of the copy for that page is quite long, we divided it up into expandable sections, kinda like the Gutenberg sidebar. But feel free to run with the layout of that page, this is just an idea. We made a few more sketches if needed.

Last edited 6 weeks ago by hedgefield (previous) (diff)

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


6 weeks ago

#25 @schlessera
5 weeks ago

Once we have a basic version of the admin notice working, we should discuss whether and how to backport it to earlier versions of WordPress and distribute through auto-updates. This way, we could reach a bigger audience.

#26 @dd32
5 weeks ago

distribute through auto-updates. This way, we could reach a bigger audience.

Doing it past the current-stable (4.9) wouldn't gain much audience - most older autoupdates rarely have administrators viewing dashboards IMHO (as evidenced by them ignoring the WordPress update banners)

#27 @flixos90
2 weeks ago

  • Milestone changed from Awaiting Review to Future Release

Per yesterday's PHP chat, the information page is gonna live at wordpress.org/support/upgrade-php/. See https://meta.trac.wordpress.org/ticket/2996 for more information.

I started work on the core notice in https://github.com/wp-core-php/wordpress-develop/pull/1. For the first iteration I wanted to stick with UI patterns that core already includes, so the notice looks minimally different from the mockups here (I based it on notice WP backend.png). But we can always consider changing that, as necessary.

Let's continue the discussion and work on the core notice on that pull request, before we get back to SVN and Trac for an eventual merge.

#28 follow-up: @schlessera
2 weeks ago

@dd32:

most older autoupdates rarely have administrators viewing dashboards IMHO (as evidenced by them ignoring the WordPress update banners)

What about those site owners that were burned by a major update once and have avoided them since? WordPress updates always contain lots of feature changes, and sites that were built in a fragile way are very easy to break on update.
Do we have any data available that helps us make an educated guess about how worthwhile this would be?

@flixos90:

Let's continue the discussion and work on the core notice on that pull request, before we get back to SVN and Trac for an eventual merge.

Sounds like a plan!

#29 in reply to: ↑ 28 @dd32
2 weeks ago

Replying to schlessera:

@dd32:

most older autoupdates rarely have administrators viewing dashboards IMHO (as evidenced by them ignoring the WordPress update banners)

What about those site owners that were burned by a major update once and have avoided them since? WordPress updates always contain lots of feature changes, and sites that were built in a fragile way are very easy to break on update.
Do we have any data available that helps us make an educated guess about how worthwhile this would be?

We don't really have any data that could be used to infer that someone is directly avoiding updating, however, I can say that 99.9% of sites which updated to 4.8.5 did so automatically, leaving 0.1% who updated by clicking the button. The number is so small that it's entirely possible it's an automated tools which show up as manual updates in our stats.
I don't think that number says that they're avoiding the major version update, but it could be.

#30 @schlessera
2 weeks ago

99.9% of sites which updated to 4.8.5 did so automatically, leaving 0.1% who updated by clicking the button

Oh, interesting data point (and interesting approach to finding an answer)!

I guess we could just deploy to what we think would make sense within reasonable effort, and then keep an eye on the PHP version x WordPress version statistics. This would tell us whether the portion with unsupported versions that we're not reaching is significant or not. If it isn't, we know we don't need to bother with the backporting. If it is, we can relaunch the backporting discussion.

@flixos90
2 weeks ago

#31 @flixos90
2 weeks ago

The Servehappy page draft is now available via public preview at https://wordpress.org/support/?page_id=9948338&preview=1&_ppp=6866f27cbf. Please do another review of the content so that we can publish it.

On the core end of things, 41191.diff implements the admin notice in core which links to the above support page. The patch was created from [this pull request on GitHub](https://github.com/wp-core-php/wordpress-develop/pull/1), please have a look for further information and reasoning on the patch.

#32 @flixos90
13 days ago

  • Milestone changed from Future Release to 4.9.5

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


13 days ago

#34 @nerrad
13 days ago

Just making note of some of the feedback made in slack when this was announced there. Click through the link to read.

Whatever final implementation we land with, discoverability is a key need here to support the goals of this initiative. So we cannot avoid some form of notice

I'm just throwing out another option as well as an idea: the WordPress “About” splash page is shown after every update. What about a new tab on that page that is colored to draw attention and dedicated to healthcheck/php version info. It can be colored a warning color when the php version of the site is “old”?

@flixos90
12 days ago

#35 @flixos90
12 days ago

  • Keywords has-patch has-unit-tests added
  • Milestone changed from 4.9.5 to 5.0
  • Owner changed from schlessera to flixos90

I'm not opposed to the alternative approach @nerrad suggests, but I think an admin notice is the most straightforward and on-point solution here. Per the discussion on Slack, let's rather aim for 5.0 instead of a minor release, as seeing the notice after a minor release may indeed feel weird. 41191.2.diff simply adjusts the version numbers accordingly.

Per the suggestion by @clorith, we should also consider using a warning color for the notice. While each of us probably considers a site running PHP 5.2 "broken", we have to be honest to ourselves: It is not broken. It is insecure and all sorts of other things, but I think a warning actually fits better.

Again, please continue further discussion [on GitHub](https://github.com/wp-core-php/wordpress-develop/pull/1).

This ticket was mentioned in Slack in #hosting-community by flixos90. View the logs.


12 days ago

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


9 days ago

@flixos90
9 days ago

#38 @flixos90
9 days ago

  • Keywords 2nd-opinion added

In today's PHP chat, the idea of implementing the notice as a dashboard widget came up, as there is prior art for that with the Browsehappy notice.
I implemented an initial take on this alternative approach with 41191.3.diff (so it does not iterate on the previous patches here!). The original source of the patch is https://github.com/wp-core-php/wordpress-develop/pull/2, where further discussion can take place.

We should compare the two approaches and come to a decision next week which one to go with.

Note: See TracTickets for help on using tickets.