PHP Meeting Recap – July 17th

This recap is a summary of the second weekly PHPPHP 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: @drewapicture @flixos90 @jdgrimes @joyously @mte90 @psykro @ptasker @schlessera @screamingdev @sergey @sobak @varjik

Chat Summary

In the beginning of the meeting, the discussion from last week about investigating ways to increase the amount of sites on a supported PHP version was continued.

  • It was highlighted that a possible notice displayed to admins of sites on old PHP versions should have pluggable parts that would allow hosts to serve upgrade instructions specific to their platform. The minimum required there would be a host-specific link to a page with detailed instructions, which could for example be set through environment variables. This should be possible independently from coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. so that further integrations or changes would not require a new core release.
  • There should also be a general “Browse Happy”-type information page on wordpress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/, that the notice could link to either as a fallback or in addition to the host-specific URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org. Such a page should explain what PHP is and why it matters that a supported version should be used. It should be an easy-to-understand and precise document that could also be shared in other instances. A GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ repository could be set up to start work and beforehand gather similar sites that have already been created by third parties.
  • While we have mentioned before that plugins should be able to define their minimum required PHP version (see #40934), it should also be possible to define the PHP version the 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 has been tested up to. Otherwise we could only prevent installs of newer plugins, but outdated ones could still break on a new PHP version without any further notice.
  • In regard to that, while it may be impossible to do that, it would be great if WordPress had the possibility to automatically scan installed plugins and show a message to the adminadmin (and super admin) that, for example all their plugins work correctly with PHP 7 or that some specific plugins might cause trouble on PHP 7. While the recommendation is to upgrade to PHP 7, there are several plugins that are not yet compatible, and a user should not learn that the hard way.

Later in the meeting @drewapicture emphasized that we had so far skipped a significant part: While everyone that was part of a discussion had apparently been convinced that WordPress should push for a more modern PHP version, we had never framed the actual problem (or problems) that this is currently causing. Therefore it was decided to take a step back and think about what those are. Even if WordPress is not going to raise the minimum requirement, the task is to specify why it is worth pushing hosts and users to a newer version. A good idea to approach this is to phrase problems like “WordPress supporting legacy PHP is…”. Here are some of the initial takes that came up:

  • WordPress supporting legacy PHP is making the developers spend more time chasing obscure bugs and less time building new features.
  • WordPress supporting legacy PHP means it will at some point completely lose connection to current PHP.
  • WordPress supporting legacy PHP has become more of a liability than a feature for its users.
  • WordPress supporting legacy PHP means other platforms will outpace WordPress soon.
  • WordPress supporting legacy PHP causes most development to just evaporate as compatibility friction.

These were just a few first thoughts that came up, and it’s important to spend more time on clearly defining the problem before proceeding, and especially consider how this causes a global problem for WordPress aside from specific groups like administrators, hosts or developers.

We need solid arguments to get backers, and we’d also need to figure out who the decision-makers are, get them involved and their buy-in. If you are reading this and you are a lead developer, long-time core developer or another kind of stakeholder in the project, we would be happy to have you onboard, or at least join the meeting for next week to help us frame the problem of WordPress supporting unsupported PHP versions.

In the aftermath of the meeting, there have since been several good thoughts and discussions happening in the channel which should also be considered in next week’s meeting. If you’re interested, please take some time to browse through the recent chats in the channel.

Next week’s meeting

The next meeting will take place on Monday 18:00 UTC, as always in #core-php, and we will take this meeting to bring forward and discuss the problems that supporting an outdated PHP version in WordPress results in. If you have ideas 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