PHP Meeting Recap – July 17th

This recap is a summary of the second weekly 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: @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 core 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.org, that the notice could link to either as a fallback or in addition to the host-specific URL. 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 GitHub 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 plugin 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 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

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

Announcement for weekly PHP meetings

As you may have noticed, there is a new Slack channel named #core-php around. This channel is a result of several conversations at WordCamp Europe and a response to the #core-js channel for those who are more focused on PHP development.

While JavaScript is a hot topic in the WordPress space and requires a lot of attention given recent focuses such as Gutenberg or the Customizer, there have also been long-time concerns about PHP-related topics in WordPress core scope, which still lay the foundation for how WordPress works. The new channel aims to provide a space to discuss those topics to make the WordPress PHP codebase more sustainable in the long run.

Weekly meetings

There will be weekly meetings in the #core-php channel, happening every Monday at 18:00 UTC. The initial meeting will take place next week, on Monday 18:00 UTC. The agenda for the initial meetings will revolve around determining the objectives for the channel and which areas to work on. Before looking at code though, the first meeting in particular will focus on the ongoing efforts to increase the number of sites that run on a supported PHP version and to get sites away from the ancient PHP 5.2 so that we get closer to the point where we can raise the minimum required version.

Since we are dedicated to backward-compatibility as much as possible, we need to carefully examine all our steps which will take time. Therefore progress will likely be slower than what is currently happening in #core-js, which at the same time will make the outcome of all efforts as solid and seamless as possible.

Objectives

While it only took about six hours after the channel was created to find a proposal to rewrite the entire WordPress codebase, our steps and decisions should be small and sophisticated, of course considering longevity as well. As stated before, the actual objectives of the channel and weekly meetings will be determined during the initial chats. The following list is a small collection of ideas that have come up already:

  • A major purpose of the #core-php channel could be to look at existing code and figure out how to integrate improved patterns into it. Most core components handle their code changes individually, causing many inconsistencies in the codebase, and one goal of the weekly discussions could be to come up with realistic best practices that could then be documented and enforced for the future and, if possible, also for the code already present.
  • There are also thoughts about a more drastic refactor of specific parts of the codebase, which could use an abstraction layer to maintain backward-compatibility with the way things currently worked. While such efforts would take a longer time and even more solid reasoning to push through, the results may be worth the energy and time investment.
  • Moving to a more modern PHP version is, as mentioned before, another goal. We should continuously investigate possibilities to put pressure on hosts (and reasonably on users as well) so that the number of sites on outdated PHP versions will lower. We can already work on long-term plans in the mean time as our code-focussed enhancements, especially modern coding standards, should preferably take shape before we raise the minimum requirement.

Ideas in addition to the above are always welcome, and we will discuss those one by one. Once there is a consensus about something, we will spread the word to gather further opinions, for example during the weekly core dev chat or in another blog post.

Once we have determined the objectives, we will furthermore need to figure out how to efficiently collaborate on these projects, possibly in smaller working groups.

If you’re interested in making PHP great again, please join us on Monday 18:00 UTC in #core-php. If you cannot make the meeting but have further ideas, you can also leave a comment on this post prior to the meeting.

#agenda, #core-php, #php