Increasing the recommended PHP version in core

The recommendation to update your PHP for users running version 5.6 or lower is scheduled to go live on August 20th, 2019.

A few weeks back, we outlined the plans to continue the work that was begun around WordPress 5.1 on increasing the PHP version recommended (and subsequently required) by WordPress.

Now that feedback has been gathered from multiple venues, both on various make blogs, and different team chats to spread the word about these blog posts, it’s time to start acting on them.

We had originally wanted to push the changes out sooner, but will admit that with mass holidays happening during the start of August, this fell through.

That said, the plans are now in motion, a meta ticket has been created to keep things on track, and the bump is scheduled for August 20th, 2019.


Proposal for increasing recommended PHP version in WordPress

I would like to propose we trigger displaying the PHP update widget for users of PHP 5.6 in WordPress.

At the time of writing, the WordPress stats show that:

  • PHP 5.6 has a usage share of 29.1%
  • PHP 7.0 has a usage share of 16.2%
  • PHP 7.1 has a usage share of 13.2%
Pie chart showing the usage share of each PHP version used by WordPress sites.

This proposal is based around multiple discussions in Hosting Team meetings, a P2 post and within core-site-health conversations.

A majority of respondents have suggested increasing the minimum requirement to PHP 7.2. The site-health maintainers agree with the sentiment but we would like to get to that point by introducing a series of incremental increases over the remainder of 2019.


Our suggested roadmap to increase the minium PHP version is:

  1. Display the PHP update widget for PHP 5.6. This will trigger the widget for anyone using PHP 5.6 or below and WordPress 5.1+ in their dashboards warning them of the fact we recommend upgrading the version of PHP.
  2. Display the PHP update widget for users of PHP 7.0 and below.
  3. Based around support and stats of points 1 and 2, have a discussion about whether the next step should be displaying the PHP update widget for PHP 7.1 or a direct increase of the required minimum version to PHP 7.2.

We suggest to start showing the update recommendation for users of PHP 5.6 or lower starting August 5th, the timeline for showing the warning to PHP 7.0 users will be announced in a followup post, and relies on factors like support load, and adoption rate from the previous increase.

Why the PHP update widget?

In discussions, multiple people have highlighted that many sites do not update plugins and themes due to paywalls. In some circumstances it can mean their version of the plugin or theme is not compatible with more modern versions of PHP. This is especially the case for many popular premium plugin and theme users.

We hope that the PHP update widget will encourage users to update all their plugins and themes, incluing all premium ones. By doing so, their PHP migration at a hosting level would go much smoother, and help pave the way for raising the minimum requirements of WordPress further in a timely manner.

Another reason for going in with the update widget first is so we are able to drip feed the support requests for the multiple teams which have to handle the support for changes like this. This includes but not limited to community, hosting, plugins, themes and support forum teams.

Screenshot of the PHP Update Widget

Feedback welcomed

If you have any questions, suggestions, or comments, the #site-health conponent would be gratful if you comment on this post with your thoughts.

Thank you.

Site Health Chat Summary: July 8th

PHP Version – soft bump

Note: The soft bump is the term referring to the PHP upgrade notice widget shown in the dashboard, and not the minimum requirement to use WordPress.

The discussion on what version to start recommending users upgrade to is going on in the comments at, but we also covered them a bit during the Hosting meeting this week.

Currently it seems the best approach would be to recommend updating to PHP 7.1 (skipping 7.0 as it’s technically not maintained any more), but we’ll leave the conversation going out the week, then make a decision on this next week. After a version has been decided on we make it known via posts to the make blogs what the intentions are, and what versions we are aiming for, and then make thew bump. This should allow hosts and developers some time to prepare for the potential support requests.

Ticket review

We covered a couple of tickets as well that were brought up by participants.

#47651 – This has been flagged for design feedback, as it needs a UI/UX perspective to help with direction and user flow.

#47644 – This has a patch, but after some discussion it will need a refresh to help with making it a bit more friendly towards the average user.

#47321 – This had some initial discussions in the channel after the meeting, but during the meeting it was covered that it needs some copy-editing. The ticket will have the outcome of the copy-discussion added once a final decision has been made.

#46925 – The ticket is ready, but was unfortunately not reviewed yet. It will get reviewed this week, and we will hopefully be more on top of tickets now that they’re more easily categorized.

Read the meeting transcript in the Slack archives. (A Slack account is required)


New Core Component: Site Health

During Contributor Day at WordCamp Europe 2019, the newest WordPress Core component was created, Site Health. After many months being tested as a feature plugin, Site Health was merged into WordPress core in versions 5.1 and 5.2. Below are several changes that were made during Contributor Day to help organize tasks and efforts around Site Health moving forward.

New Slack Room

The Site Health feature is just one tool that is empowering site owners and hosts to upgrade to more modern versions of PHP. Because of this, most of the discussions around Site Health have happened in #core-php to this point.

However, now that Site Health is in WordPress Core, it’s time to give that Slack room back to the folks discussing how PHP is used in Core (upgrades to patterns, discussing guidelines, style guides, etc.).

All Site Health discussion moving forward will be held in the new #core-site-health channel.

Component Maintainers

The following people have played incredibly important roles in the Site Health project so far and were asked to be component maintainers. All accepted:

Action Summary

Here is a brief summary of the actions taken to facilitate this change:

  • A Site Health component was created in Trac.
  • A Site Health component was created and added to the Make WordPress Core Components page.
  • All open tickets with the site-health keyword were moved into the Site Health component (tickets effected).
  • All open tickets with the servehappy keyword were moved into the Site Health component (tickets effected).
  • All closed tickets with the site-health keyword were moved into the Site Health component (tickets effected).
  • All closed tickets with the servehappy keyword were moved into the Site Health component (tickets effected).
  • The site-health tag has been created for this blog. All Site Health related posts will utilize this tag.

Note: The site-health and servehappy keywords are now obsolete and should not be used moving forward. but they will remain on old tickets.