PHP Meeting Recap – August 21st

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: @brainfork @jdgrimes @mte90 @nerrad @schlessera @screamingdev @sergey @spacedmonkey

Announcements

Before we get to the chat summary, I want to make an announcement first, for the people that don’t attend the Slack channel.

GitHub repositories have moved

The servehappy and servehappy-resources repositories have been moved from the temporary wp-core-php GitHub organization to the official WordPress GitHub organization.

Here are the links to the new locations (the old locations should redirect to these):

Chat Summary

We started with discussing the sections and the section content of the landing page again. We iterated over a couple of different versions of the first section, which we had been calling the Why you want to read this section.

What we came up with was to consider three different approaches to phrasing this first section, with the understanding that:

  • the #marketing team will help us find the best way to write the actual copy for each approach;
  • the different approaches can be A/B tested to optimize them and find the most effective one.

Here’s a preliminary summary of the three approaches we went with:

  1. The “technology” approach:

    One of the important software components that enables WordPress to run on all sites is PHP. On this page you will learn what PHP is, why being on the latest version of PHP is so important for your site, and some steps you can take to make sure your site has the latest PHP version in use.

  2. The “detected issue” approach:

    Your website might not be operating at its full potential. This page will tell you about an important issue we have detected and how to go about to resolve it (no jargon!). Let’s talk about what PHP is, and why you might need to update it.

  3. The “probability” approach:

    You want your site operating at its full potential. Is it? As many as 4.5% of sites running WordPress are not. This page will help you determine if your site is one of them and how you can fix that.

Then we went on to discuss the distribution of the remaining content we need across the different sections. We identified the individual goals that the content needs to achieve and built a preliminary overview:

  • A. What is PHP?
    1. explain what PHP is
  • B. Why PHP version matters to you as a site owner
    1. explain what the problem with old PHP is
    2. explain the benefits of new PHP
    3. explain what an update is
    4. explain why WordPress can’t deal with this problem itself
  • C. How to upgrade PHP for your website
    1. list the potential problems an update might cause
    2. provide steps to prepare an update to PHP
    3. give instructions on updating PHP
    4. help troubleshoot issues

Again, the exact ordering and the copy to use should be discussed with the #marketing team. For the C. section, we are considering a UI component similar to an accordion, to avoid people being overwhelmed with the amount of content on the page. This might need to be discussed with the #accessibility team first, though.

Concerns were raised about how useful the project board on GitHub is for discussing something like the overall structure here. This problem is the reason why we have a “Meta” section on the project board that can contain issues to discuss overarching topics like the main sections.

Finally, it was confirmed once again that the project is meant to be translated in as many languages as possible. However, we only want to start working on the translations once the content is somewhat finalized, to avoid wasted effort.

Next week’s meeting

The next meeting will take place on Monday, 29 August 2017, 20:00 CEST, as always in #core-php, and its agenda will be to finalize the section work we’ve been doing so far and to get it into a shape we feel good about presenting to the #marketing team. If you have suggestions about this 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 – August 14th

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: @afragen @desrosj @dimadin @drewapicture @flixos90 @jdgrimes @mikeschroder @nerrad @pross @schlessera @sergey @spacedmonkey @stevenkword @tfrommen

Chat Summary

The agenda for this week’s meeting to continue our efforts for the planned .org page to educate and convine mainly non-technical users about the benefits and necessity of PHP upgrades. Here are the highlights from the discussion:

  • There is now a new GitHub organization for the core PHP team, and a repository as a central location for the work towards the new page, which now lives under the temporary codename “servehappy”.
  • There’s furthermore an additional repository as a collection of third-party resources on the topic, such as articles or hosting-/tool-specific upgrade tutorials. Some of those will be good references and inspiration for our own version.
  • Everyone is welcome to contribute to both of those.
    • The primary task for the “servehappy” repository will be to open issues for the benefits we’ve come up with over the past few weeks, and discuss them one by one, whether they qualify for the page and how they can be framed in the most convincing way. A project board exists to get a quick overview about where each of those benefits stands in terms of workflow.
    • Any useful resource found about the topic should be added to the resources repository. This can happen in a very intuitive way, as you don’t even have to fork the repository to enhance it. Simply use one of the file editing buttons to make your changes, and create a pull-request from it. Enhancing the resources list is much appreciated too.
  • @nerrad suggested to also have issues for the different sections planned for the page (see last week’s recap for the proposed outline). A project view for these has been created since, which is a work in progress.
  • While we call the first section “What we want from you”, this title should only be used for ourselves to remind us what we’re using the page for and that this should be conveyed in the first section. However, that should be phrased in a way so that the site visitor does not feel put under pressure. It should go more into a direction like “Once you’ve read this page, you will want this too”.
  • The section “What should you need to know before doing an update?” must not unnecessarily make the user worry. Let’s highlight possible issues, but not overestimate them. People should see upgrading as a good thing, and we should point them at how they can determine whether their sites are ready.
  • Users should briefly be educated about the natural requirement of software updates, and that PHP is just the same. Phrases like “Now you need to do this every … months” must not be used, but a more general way that highlights the benefits of staying up to date and that, in order to do so, upgrades are occasionally required. If site owners are not made aware of this, the next upgrade request will be just as painful as this one.
  • An important goal of the page is to improve the distribution of the PHP versions as collected by the installation/update stats of WordPress.org.
  • At the end of the chat, we talked about PHP versions a bit, and which jumps were more critical or problematic than others.@mikeschroder highlighted that the jump from 5.2 to 5.3 was actually one of the hardest, while 5.6 to 7.0 was quite smooth. @schlessera added that 7.1 is a bit more problematic than 7.0 because of some of the changes involved.@mikeschroder will try to see if they still have data at DreamHost about the 5.2->5.3 jump that they could share. He furthermore reminded ask to ask more of these questions in the #hosting-community channel.

The takeaway of this week was that we should finally get in touch with the marketing team. Let’s work on adding a brief one or two sentences for each of the sections that were proposed in last week’s meeting to give them more context, to provide a better foundation for the #marketing team. This can happen via GitHub. More benefits should be added as issues on GitHub as well.

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 page outline, benefits and further coordination. 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

PHP Meeting Recap – August 7th

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: @chetansatasiya @clorith @desrosj @flixos90 @tfrommen @jdgrimes @kelseyfecho @mikelking @mte90 @nerrad @schlessera @screamingdev @sergey @sudar @xkon

Chat Summary

@flixos90 started by letting everyone know that he will be alternating with @schlessera in running the weekly meeting.

As we had split up the discussion into two main topics during the last PHP meeting, we wanted to concentrate on one topic only this time: making progress on providing the informational page that should educate people about PHP updates.

As we noticed that some benefits we had identified in prior meetings only applied to specific subsets of our target audience, we discussed the need to more explicitly subdivide the audience into individual segments, and adapt the language we’re using for each of these. We distilled the following list of main segments to begin with: site-owners, developers, hosters.

We agreed that it does not make much sense to have separate landing pages for each and that we’d rather have one single default landing page for the site-owners, with links to other sections/subpages for the other segments. The reason for that is that the page should start with adapted language for the least tech-savvy group, with additional details as needed, so as not to overwhelm the page’s visitors.

For site-owners, we also want to provide a convenient email template that they can send to their hosting provider to get an update. We could potentially discuss this with hosting companies to know what their preferred ways of contacting them about updates are, to make the process as frictionless (and cost-effective) as possible. This would mean that the provided template could change depending on what hosting provider was detected for the current site.

The list of benefits should be done as real copywriting, as we are basically building a sales page, trying to sell “updating PHP” to the site-owners that have to pay the price for that. The page should use proper marketing language, convincing stats and diagrams, and story-telling techniques to finally end in a call to action.

The page we’re building should also include a section on the more tricky technical aspects of updating PHP, like checking plugin compatibility and troubleshooting issues.

Given all of the above, we decided it is time to contact both the #marketing as well as the #hosting-community teams/channels to ask for help.

And although we decided we need to deal with different audiences and adapt the page to each of them, we also realized that this multiplies the amount of work to be done. In order to get first results as quickly as possible, we agreed to concentrate on initially building the section for site-owners first, and adding the other segments afterward.

As for the structure of the page, we discussed a first general layout like the following:

  1. What we want from you
  2. Call to action
  3. What is PHP?
  4. Why do you need an update?
  5. What should you need to know before doing an update?
  6. How do you do an update?
  7. Call to action

The main location to persist decisions, for now, is Meta Trac ticket 2996. However, we’ll prepare some shared document space to gather all intermediate materials.

Next week’s meeting

The next meeting will take place on Monday, 14 August 2017, 20:00 CEST, as always in #core-php, and its agenda will be to discuss the more organizational aspects of making progress. We want to agree on one tool where we can collaborate on archiving our current results and on producing first deliverables. If you have suggestions about this 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 31st

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 @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 core 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 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

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

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