PHP Meeting Recap – July 24th

This recap is a summary of this week’s PHP 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 @dnavarrojr @euthelup @flixos90 @jdgrimes @joyously @markjaquith @presjpolk @psykro @ptasker @sergey

Chat Summary

In the beginning of the meeting, the process of defining the problems an unsupported PHP version causes continued, with a particular focus on WordPress. Some problems that were highlighted by @markjaquith and @jdgrimes:

  • WordPress supporting legacy PHP makes it less appealing for developers from outside of the WordPress world to contribute to the project.
  • WordPress supporting legacy PHP will cause the quality of plugins to decrease over time due to the lack of good developers entering the WP marketplace.
  • WordPress supporting legacy PHP causes security issues and a worse performance (the latter especially compared with PHP 7+). Improvements to both would be an immediate result of upgrading, of which WordPress cannot manage the technical debt completely.
  • WordPress supporting legacy PHP results in several users not having access to some of the best plugins as they require a higher version.
  • WordPress supporting legacy PHP results in a higher chance of running unmaintained plugins.

Afterwards the discussion shifted towards the efforts of informing users about legacy PHP.

  • A challenge is that in most cases the next step would likely not be clear when showing users a notice about an outdated PHP version.
  • A more organical way than showing a notice to let users know that their setup is outdated is official support for PHP requirements of plugins (see #40934): When a user sees their plugin is not going to work any longer, they know for fact that they need to do something. It is important though to not just add the warning that the plugin does not work because of the installed PHP version, but also at the same time being able to inform the user about what this means.
  • A wordpress.org page to link to would be a good first step. It should highlight the problems legacy PHP causes for the user, and provide general information on how to upgrade, the latter being the most tricky part. The benefits of such a page is that it could easily be updated without having to wait for a core release. An early Meta Trac ticket has since been opened to work on such a page.
  • It would also be great to allow hosts to integrate with any notice displayed in the admin, for example they could add a link to their own upgrade page through an environment variable. While many hosts that still have their users on unsupported versions are unlikely to follow WordPress and thus would not take care of this, there are also a number of more considerate hosts that however have not switched their users because they do not wanna do it without their consent. In those cases such an integration could work and be beneficial.
  • WordPress itself bumping the minimum required PHP version at some point should also be highlighted to the user. While we need to be thorough in our steps, such efforts should become visible sooner than later to users so that they have enough time to upgrade.
  • Some users will inevitably not have upgraded when WordPress ups its requirement, and those users will admittedly be in a worse state than they are now. But given that such a great amount of others will be in a much better state, we have to be honest with ourselves that there is no way to make this a zero-pain for everyone. Our goal is to get the number of users on those versions as low as possible and then determine a solid point when to upgrade the requirement, based on those numbers.
  • As mentioned before, plugins are a good reason to upgrade as well. The quality plugins that don’t support PHP 5.2 outnumber those that don’t support PHP 7.0, and that’s only going to increase.

The last topic of the chat was to review the changes proposed as part of #40934 on the Meta side of things.

  • @sergey explained the plans and asked for feedback, particularly for whether they could go in or required more discussion.
  • While the core-related changes in that direction will need more time, particularly with how users are going to be informed, there was consensus that the Meta part of it is ready to be committed.
  • An idea about also being able to specify a “Tested up to PHP” version in the plugin header was brought up, or even supporting semantic version specification like with Composer. After discussing it however, the result was that introducing such a feature would easily cause unnecessary uncertainty among users. Although it could theoretically help users decide whether they should upgrade or not, in most cases it will without a good reason show a warning that the plugin has not been tested. That is because while many plugins would still work on a new PHP version, users would often still see it as not tested just because the plugin developers have not updated the header yet. This is already a commonly known issue with the existing header about which WordPress core version a plugin has been tested with. Therefore such a header should not be introduced.

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 brainstorm how a wordpress.org page informing users about legacy PHP could look like and what it should contain. 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