PHP Meeting Recap – July 10th

This Monday the initial weekly PHP meeting took place. This recap is a summary of which ideas and decisions came up during that meeting, both as a means of documenting and to provide a quick overview for those who were unable to attend.

The meeting’s chat log.

Attendees: @flixos90 @jdgrimes @joyously @mte90 @ptasker @psykro @schlessera @screamingdev @tfrommen

Chat Summary

The topic we discussed this meeting was solely the current minimum PHP version requirement of WordPress, as it is the foundation that many code improvements are likely to rely on.

We came up with several ideas on how to raise awareness and increase pressure on hosting companies to upgrade PHP in a reasonable manner. We did not discuss these in detail yet, it was mostly a brainstorming session. Here is a list of what we came up with:

  • The first item has already been around (see #41191): There should be a nag in the WordPress admin dashboard indicating that an unsupported PHP version is being used. Security and performance are two examples of how to make an upgrade attractive to users. The most important part though will be to make it understandable and reasonable to people not tech-savvy.
  • The second item also exists already (see #40934): It should be possible to specify a minimum required PHP version for plugins. Once this is supported by core, it is likely that more plugins will raise their minimum requirement, so it will eventually be another way to make people aware. It should probably only happen in combination with the point above though, since otherwise there would not be a clear explanation of what PHP even is and why a supported version matters.
  • Related to displaying an admin notice, it could be valuable to gather data on which sites the notice appears to make a solid case for the business benefits of upgrading. However there were concerns expressed about privacy. The good part is that WordPress already collects some information during the update API requests and we could use some of that data to evaluate. A GitHub repository could be used to document the results.
  • Until core provides a solution, every plugin developer should consider showing a nag about the PHP version itself in case the plugin requires a higher version. This implies that the plugin’s main file must be PHP 5.2-parseable, even if the rest of the codebase requires a higher PHP version. Plugins that simply use modern PHP syntax in the main file provide a bad user experience by deliberately causing a fatal error and do not educate users about why the plugin does not work. There is a library by Yoast that can easily be integrated into any plugin and even provides more help than simply saying that the PHP version is outdated. It even makes sense to be integrated if the plugin supports PHP 5.2, in order to raise awareness, and the PHP versions for which it shows can be manually set by the plugin integrating it.
  • It could be helpful to have an article about the issues with a title like “Your WordPress might be insecure” and have that post appear in the admin dashboard news feed. This would be an easy way to raise at least some awareness and would not even require a WordPress update.
  • We could also reach out to the authors of very popular plugins and ask them to publish a post about the topic. It would reach a lot of WordPress users, also via newsletter.
  • The topic could be addressed in WordPress meetups around the globe. If you are a meetup organizer, consider bringing up this topic to educate people why they should upgrade and how to do it.

In addition to the above ideas we took the second half of the meeting to take a closer look at #41191 and think a bit more about the details of how the admin nag should work. These are the results of our discussion and the rough plan going forward:

  • The notice should recommend to jump to a PHP version >= 5.6. In addition it should highlight that jumping to a version >= 7.0 would be even better (especially for performance), but also carefully indicate that outdated plugins might have a higher chance of not working there properly.
  • The notice should initially only show on PHP 5.2 setups. While we want sites to go to a maintained version, this is a huge task and for WordPress to raise the minimum required PHP version it is most important at this point to decrease the number of sites running on PHP 5.2. Only showing it on 5.2 setups instead of everywhere below 5.6 will also reduce the support burden for hosts. Over time, once we are satisfied we can iterate to show the nag on higher versions as well, until we reach 5.5.
  • Once the number of PHP 5.2 sites is low enough, we can bump WordPress core’s minimum requirement to PHP 5.3. While that version is still outdated, the language-specific features of that version justify an upgrade more than any of the other planned upgrades, and furthermore the bump is already drastic enough like that. Jumping from PHP 5.2 to PHP 5.6 would likely result in a disaster. Again, over time we can iterate and bump the requirements until we reach a supported PHP version.
  • Once we are convinced that the time is right to move away from PHP 5.2, it would make sense to set up a clear roadmap for the subsequent version bumps. This gives hosts as well as developers a solid plan and overview so that they are prepared.
  • We still need to figure out which specific goal we should set, in order to determine when to bump the minimum requirement of WordPress to PHP 5.3. This will be a topic in a future meeting.

Next week’s meeting

The next meeting will take place on Monday 18:00 UTC, and we will continue talking about the PHP version bump and related plans there with the goal of figuring out which of our ideas are realistic and which timeframe we should be prepared for. If you have thoughts on the above or other ideas but cannot make the meeting, please leave a comment on this post so that we can take it into account. See you next week!

 

#core-php, #php, #summary