Felix Arntz 6:12 pm on August 3, 2017
Tags: core-php ( 68 ), PHP ( 71 ), summary ( 898 )

PHP Meeting Recap – July 31st

This recap is a summary of this week’s PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 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

Chat Summary

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 coreCore 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, pluginPlugin 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!

#core-php, #php, #summary

Aaron Jorbin 6:54 pm on August 3, 2017

The strategy should possibly be to slowly catch up with PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher development. While PHP’s version upgrades are rapid, coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.’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.

I disagree with tying core’s policy to PHP internals, in large part due to the fact that PHP internals isn’t the only team maintaining PHP. It ignores the Linux distros that backportbackport A port is when code from one branch (or trunk) is merged into another branch or trunk. Some changes in WordPress point releases are the result of backporting code from trunk to the release branch. fixes and maintain support for versions of PHP years beyond what PHP internals supports. Dropping support for these LTR distros would be a mistake.

Our PHP version support policy should be based upon what our users are using. Having an unmaintained version of PHP and an unmaintained version of WordPress increases the attack surface for our end users.
- J.D. Grimes 9:25 pm on August 3, 2017
  
  Yes, this is something that definitely needs a lot more thought and discussion.
  
  In my thinking at least, the purpose of the goal/strategy is not to decide to do something and then force users to go along, but to think about where we’d ideally like our users to be someday, and work toward that. Users would still be dictating the minimum version, we wouldn’t be leaving many millions of users on an unmaintained version of WordPress. We’d only be able to reach a goal of following PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher internal if users and hosts could keep up with that (which obviously isn’t the case right now).
  
  I think it is important to consider that WordPress can’t just set a goal in regard to this and make it happen. If we tie ourselves to PHP internals, we’ll be at their mercy, and the only way to keep pace will be at the expense of our users. We need to remember that the driving force here is the PHP development and maintenance timeline itself, which is not without its downsides (and detractors).
  
  If we want to set a goal tied to PHP internals, I think that we’d need to look at things from a perspective that is one level higher, and consider whether PHP itself could change some things to improve this situation. Of course, we don’t control that, and probably would have little success there. Which means that if we pursue a goal aggressively, we’re inevitably going to end up being too aggressive in the only other direction we can be: our users.
  
  So I understand the desire for a little pragmatism here. PHP has in the past, and may in the future, make it difficult or impossible for hosts and users to keep up with its timeline.
  
  I think we’d need to take a good hard look at PHP’s long-term goals and roadmap and consider whether following it will really be in the best interest of our users.
  
  Which is to say, that regardless of any goals that we come up with, we need to make it absolutely clear that our over-arching philosophy is that we put our users first by trying to follow the path that will minimize the greatest real-life risks to them, hopefully resulting in a better overall experience, even if not ideal. And this sometimes requires pragmatism, meaning that any strategy or goal that follows arbitrary timelines, or processes outside our control, may be subject to change.
- Felix Arntz 8:12 am on August 4, 2017
  
  I completely agree, that users should be the driving force for planning the long-term strategy. I think however that slowly catching up with PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher in the long run makes sense in order to not fall behind in the way WordPress currently does. Being more efficient and less error-prone will also benefit the user – of course only as long as it doesn’t come at the expense of them being required to constantly check whether they need to upgrade or whether their site is going to break.
  
  It’s a complex problem that needs careful research and investigation. Users are obviously much more important than PHP is, but we also shouldn’t ignore the latter as much as we have done in the past.
- jeichorn 9:31 pm on August 4, 2017
  
  There has to be some pragmatism here, but at what point are you just doing users a disservice. There is no Linux vendor who is still supporting PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher 5.2. The CVEs get published, the exploits are there to be written and the patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing. will never come.
  
  On PHP 5.3 it looks like Suse and possibly Redhat are still doing some backports.
  
  Example backports 5.3 as oldest
  https://www.suse.com/security/cve/CVE-2016-7411/
  
  Redhat not backporting same CVE
  https://access.redhat.com/security/cve/cve-2016-7411
  
  Note that this example is remotely exploitable on many wordpress installs (there are still lots of plugins accepting serialized php parameters). The impact might be rated low in a global PHP sense but its higher in wordpress with our pluginPlugin 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 mix.
  
  Seems like at a minimum even if we are not going to cut off EOL PHP versions, we need to be clear that its risky behavior from a security standpoint.
J.D. Grimes 9:34 pm on August 3, 2017

In regard to a goal/strategy, I think we may want to think about other practical considerations beside just EOL dates for PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher.

For example, when PHP 8 eventually comes out, it will require some things to be the exact opposite of the way that they were in PHP 5. While it might still be possible to provide a compatibility shim that would allow the same code to run on both PHP 5 and PHP 8, it may be difficult. (And we can’t even necessarily foresee all of the potential technical issues at this point.) So requiring PHP 7+ by the time that PHP 8 is released might be a worthy pursuit. (Of course, if it was really necessary, we could delay support for PHP 8 until our users had moved off of PHP 5, but that’d be nice to avoid.)

There are probably also other considerations not just about EOL PHP that I’ve not thought of. These may be things that would require a more or less aggressive goal timeline, depending.

Comments are closed.

Welcome!

Communication

PHP Meeting Recap – July 31st

Chat Summary

Next week’s meeting

Welcome!

Communication

Chat Summary

Next week’s meeting

Share this:

Site resources