Servehappy: Roadmap Update and Priorities

At WordCamp Europe 2018, representatives from different teams got together to discuss the state of the Servehappy project, reevaluate its roadmap and priorities.

Meeting Context

While this blog typically contains updates from the core PHP team, it is important to highlight that the Servehappy project is an interdisciplinary effort that has involved several other teams as well. We have been collaborating closely with the marketing and design teams so far, however at the same time several efforts were pursued in other teams which had not been mentioned as much in the weekly recap posts: The community team and support team have been pushing a format called “Site Health Check”, providing support services at WordCamps to increase adoption of modern PHP versions as a part of that. The hosting team has also discussed on how to approach the problem on their end. Due to all these different teams being involved in the Servehappy project, we wanted to revisit the project state together with a representation of those teams.

Participants: @alexdenning, @flixos90, @mikeschroder, @miss_jwo, @pento, @schlessera

Meeting Summary

Short-Term Goals

While the general long-term goals of the project are clear and available in the project’s roadmap, the discussion briefly involved clarifying priorities and short-term goals.

  • Increase adoption of modern PHP versions by being more active and vocal about the necessity of those.
  • Encourage users in a positive manner to update and stay updated.
  • Make the process of updating as seamless as possible.
  • Release a first iteration of the project that warns administrators of sites running PHP 5.2.

Approach: Help People

We agreed that, in line with the WordPress philosophies, the approach to solving the problem should be based on framing the project in the user’s context, most of who have little to no technical knowledge of PHP.

  • We would like to boost user confidence by encouraging the update and educating about preliminary recommended steps to take in order to ensure the process goes without a hassle.
  • By highlighting tools such as Tide, the Health Check plugin, or the PHP Compatibility Checker plugin, we allow non-technical users to easily gain technical insights in a plugin’s compatibility with certain PHP versions.
  • We intend to reduce the risk of updating PHP as much as possible by implementing a sandboxing system to decrease the chance of a site breaking through the update. We need to ensure that site owners are never locked out of the backend due to an incompatibility.
  • We plan to run further Site Health Check desks at WordCamps and related events and encourage organizers to do so, in order to raise awareness of the importance of checking the PHP version on your website. An important side note to this, at this point only updates to PHP 7.2 and 7.1 should be encouraged, as both PHP 5.6 and 7.0 will be unsupported from the end of this year.

Data about PHP Version Updates

We briefly talked about the jumps from and to specific PHP versions, looking at how involved they typically are.

  • The update from 5.2 to 5.3 has known issues which are not small. We should review the support impact for hosting companies, agencies, plugins, themes, and the WP.org support team.
  • The updates between 5.3 to 5.6 are usually unproblematic, there have been no known major issues.
  • The update from 5.6 to 7.0 has many known issues. @mikeschroder will request a list of common issues and errors known to the hosting team when performing that update.
  • The updates between 7.0 and 7.2 have been less problematic, however due to several deprecations more investigations should be made in that area.

Improving the Updating PHP Page

While the nag to inform site owners about an unsupported PHP version has already been merged into core and an Updating PHP page is already available, it is necessary to improve the latter.

  • The above page, which is linked to from the core nag, will to a large extend determine whether the project will be successful or not, as people have to be willing to read its content and then act on its recommendations.
  • Currently the page is a simple wall of text, which will likely scare away visitors. The page content needs to be further reworked, broke down into more obvious sections, shortened, and be visually enhanced so that users are guided through the process as intuitively as possible.
  • @alexdenning will coordinate with @jaymanpandya who had worked on a design for the page before to move this forward.

Community Plans

  • A Site Health Check desk will be available at WordCamp Brighton in mid-August with the goal of testing this approach further and optimizing the process.
  • Following this, we would like documentation to be created about having this format, with the goal of it being ready by WordCamp US in early December. That documentation could then be shared with communities and organizers around the world, encouraging providing this format at more events.
  • Current plans also include there being a Site Health Check desk at WordCamp US, preferably also with more hosting team support at the desk, especially due to their high availability at that event.
  • Another idea was to have wapuus made available specifically for the Site Health Check.

Hosting Plans

  • The core PHP team would like to communicate more and collaborate more closely with the hosting team.
  • The hosting team is an ally to these efforts and would like to be more involved. Some miscommunications in the past were figured out and clarified.
  • It is planned that a representative of the hosting team will be participating in the weekly PHP team meetings, reporting back and voicing views of the hosting team on the topics discussed. As of now, @antpb has stepped up to fill that position.
  • It would be great if documentation for hosting companies could be created on how to integrate with the Servehappy nag in core (read more about the core integration) and on how to provide easy-to-understand documentation on how to safely update PHP in their specific environment.
  • An idea for further down the road that came up was having standardized endpoints as part of an API for upgrading PHP across hosts. CPanel or Plesk adopting this could move the needle across many hosts at once.

Core and Security Plans

  • The security and core teams plan to work on user-facing documentation on why running old versions of PHP or WordPress is dangerous.
  • Furthermore they intend to create documentation for both plugin and theme authors about how to ensure that their code is compatible with modern PHP versions.

Involvement of the Marketing Team

  • Going forward, all documentation created as part of the aforementioned plans should preferably be reviewed by the marketing team.
  • It is important to use an easy-to-understand, encouraging and positive tone of voice for all documentation.
  • We need to ensure that all marketing material documentation is localizable and uses language that is easily translatable.

Requirements for Servehappy in Core

In order for the first iteration of the Servehappy project to be shipped in a core release, we determined the steps that must be completed before.

  • The first iteration should primarily revolve around the core nag warning users about outdated PHP versions. It will only be displayed for PHP 5.2 in the first iteration.
  • Due to that version being controlled by a wordpress.org API, the nag’s visibility can be gradually increased by being shown on higher PHP versions too, without being tied to WordPress core releases.
  • Further efforts of the Servehappy project in core, such as preventing installation or updates of incompatible plugins and themes, are not specifically a requirement for the first iteration. Although not as high a priority at this point, they should definitely not stall and will be merged and released as they get completed, however only at the same time or later than the core nag.
  • The efforts of improving the Updating PHP page mentioned above needs to be completed, with the page being in a solid state. It should be fully translatable, and there should be enough time before the release to encourage the creation of localized versions of the page across the globe. The link to the page in core is localizable as well, being able to link to those versions.
  • A safe-mode functionality needs to be implemented in order to prevent WSODs (white screens of death) and other errors that would lock the site owner out of their backend. It will likely involve some sort of sandboxing system, with plugins being deactivated in the admin as necessary to ensure possible access. Having this will allow the instructions in the Updating PHP page to be more positive and confirming. @schlessera has since been making quite a bit of progress on this already in #44458.
  • It should be possible for hosting companies to hook into the nag and provide their own instructions of how to upgrade to WordPress users on their stack.
  • It is currently envisioned to have the first iteration ship as part of WordPress 5.0, however depending on when that version is released, this may change. It is certainly no hard deadline in that regard.

Project Name Proposal

  • Based from the Site Health Check desks, there is a suggestion to refocus the project to be the WordPress Health Check Project which encourages people by name to check for updates continually.
  • However, the problem has arised about defining what is in scope of the site health check. It needs to be clarified what kind of health check this is, as some users so far have looked at it as a performance check.
  • The name change would allow for a more positive mindset and for the scope of the project to change as the WordPress project needs it to.
  • Unless there are objections, the name Servehappy for the core efforts is solely an internal codename and will not be exposed to the user anywhere.

Get Involved

If you’re interested in these efforts, please get involved and get in contact with the respective team whose work you are interested in. The easiest way to do so is participate in their meetings. We need your input and ideas, specifically we would like to ask for your feedback on the outcome of the discussion that is part of this summary, as most of it is not set in stone. If you cannot make it to the respective meeting, posting a comment here is a great alternative.

As far as the core efforts go, the next meeting will take place on Monday, July 23th, 2018 at 15:00 UTC in the #core-php channel on Slack.

#core-php, #php, #servehappy