This recap is a summary of this week’s PHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher meeting. It highlights the ideas and decisions which 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: @desrosj @drewapicture @flixos90 @jdgrimes @mikeschroder @nerrad @schlessera @screamingdev @sergey @sobak @spacedmonkey @swissspidy @xkon
There were two main topics that were discussed during the meeting. The first one was the planned .org page that would inform users about PHP, its outdated version problem connected with WordPress and how to upgrade. Here are the thoughts shared about such a page:
- Once ready, it should be ensured that polyglots learn about that page and translate it into the respective languages for each rosetta site.
- The page should be aimed at users and not contain technical details that would bore people. It should be on point, describe the problems an outdated version causes as well as the benefits of a more modern version in easy-to-understand language. Images and graphics could be used to present key takeaways at one glance.
- There are obviously several benefits when using a modern PHP version, however most of them are not immediate and thus might have a hard time convincing a user to upgrade. We need to spend more time on looking for immediate benefits, such as improved performance (PHP 7+) or compatibility with specific popular plugins that require a higher PHP version.
- The marketing team’s help with this would be much appreciated.
- Catch phrases like “xy% upgraded their PHP, when do you?”, “WordPress is more … with the latest PHP” and altruisms like “WordPress can be much more better when you …” could be used on the page.
- Most hosts that still have their users on unsupported versions are probably just cutting costs and do not care about much else. However, officially supporting minimum PHP requirements for plugins and linking administrators to the .org page could cause several support tickets, organically increasing pressure on those hosts. They may very well upgrade once they notice a significant amount of people asking.
- An article by WP Engine was highlighted on how they first introduced PHP 7 support. They created a compatibility checker plugin, which is something that could benefit core Core is the set of software required to run WordPress. The Core Development Team builds WordPress. in general for such cases.
- The WordPress requirements page already has a few bits and pieces that we might be able to reuse. Eventually that page should also link to the new page we’re working on.
- Searching for further material on PHP and its upgrades and how other parties dealt with it should be the primary objective for everyone interested in such a page. Others have come before WordPress core, so we need to learn from their experiences, possibly their mistakes and use their content as inspiration.
The second topic that came up during the discussion was to plan a more long-term strategy for version upgrades beyond the jump from PHP 5.2 to 5.3. Without such a strategy, we will run into the same problem over and over again.
- Such a roadmap should eventually be placed on the PHP information page on .org (see above). It will make the strategic reasoning much clearer how and what exactly to communicate.
- There do not need to be any dates on it, but it should provide a long-term overview on when WordPress is planning to raise the minimum requirement.
- A long-term roadmap gives people enough time to prepare. While it was a less critical step than upgrading PHP, this year’s decision to drop support for IE8 came pretty much out of the blue, and this must not be the case for any PHP requirement bump.
- We must ensure that the strategy is based on our experience with upgrading PHP versions, investigations and statistics. The roadmap should be dependent on when people can reasonably upgrade, not the other way around.
- It is very likely going to be a slow process, but even then, having somewhat of a schedule will make hosts, and possibly even users that visit the page, aware of the long-term upgrading strategy.
- The strategy should possibly be to slowly catch up with PHP development. While PHP’s version upgrades are rapid, core’s support policy should at least somewhat depend on it, for example with something like supporting versions 2 years longer. To get there, we will need to carefully plan reasonable bumps over a long transition period to slowly close the (much bigger) gap that there is now. Of course it will take a while until a goal like this can be achieved – but even if it takes 10 years or more, a roadmap will communicate this way in advance for both WordPress users and developers as well.
- It can be really long-term, as long as it’s a systematic and reasonable approach.
- At some point, we will get to where PHP is right now. It is in our favor that PHP has matured and the version differences become smaller, which makes it much easier to change the version installed on a hoster’s server.
- The first upgrade (from PHP 5.2 to 5.3) is certainly going to be the toughest one, both because we first need to do the heavy lifting of informing generally and also because the enhancements from 5.3 over 5.2 are among the most significant between two PHP versions, for example there was some pretty big breakage with non WordPress code on Dreamhost when they made the switch. The following versions were much easier.
As a result of the discussion, we figured that we now have two primary goals: The primary goal is still accelerating the current upgrading path (through the aforementioned .org page, plugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party PHP version requirements etc.). The other important goal is to investigate a reasonable long-term strategy for PHP requirement bumps.
Next week’s meeting
The next meeting will take place on Monday 18:00 UTC, as always in #core-php, and its agenda will be to continue discussing the two topics, particularly how to proceed with them as they are quite different. If you have suggestions but cannot make the meeting, please leave a comment on this post so that we can take them into account. See you next week!