Site Health Check Project review at WCUS

This is a verbose set of notes to record the discussions that took place at WCUS and to reflect the work that has been done across multiple teams.

The Site Health Check project is a collaborative multi-team project with a focus on encouraging better site maintenance.

This project benefits not just WordPress users, but also the surrounding PHP ecosystem as a whole. Our hope is that this will prompt a lot of PHP updates across the web.

It started as a project to focus efforts on getting users to update their hosting version of PHP from 5.2 to something where the End of Life has not already passed.

The project was initially called ServeHappy, homage to the BrowseHappy project which was a global tech effort to move away from Internet Explorer 6. The problem with the project name was that, when tested with users who did not know about the ins and outs of the project, the name was confusing and was not clear what the project’s intentions were.

The project is now known as the Site Health Check project. It encourages and hints to users that if they run a website, they should have a routine of checking and updating not just WordPress but underlying technologies that the site is built on. It also builds positive website ownership and habits.

The project is split into what can be considered 3 parts – changes to WordPress core itself, a site health check plugin and the site health check community support.

Upcoming changes to WordPress Core

The core-centric side of the project still reflects the Servehappy origins. This includes:

  • An information page on WordPress.org explaining the importance of updating PHP. The team has been working on improving the language used to benefit non-technical people and have clear instructions of what to do if they find out their site is running an old version of PHP.
  • A dashboard notice that will inform users if their site is running on a PHP version that WordPress considers outdated and plans to drop support for in a future update.
    • The version shown in the dashboard is API-driven which means that WordPress leadership has a centralized “knob” to tune the PHP version distribution.
    • The dashboard includes a link to wordpress.org/support/update-php which has generic information on what the notice means and how to update PHP on their servers.

  • There will be an environment variable or a filter which allows hosting companies to modify the link to the “Update PHP” page on their servers so that it goes to something more relevant for their customers.
    • There are some concerns of security problems and abuse over the link redirection.

  • The team has been working on a feature to add white screen protection, which the hosting group felt was helpful and cool. The white screen protection catches any fatal errors that a PHP update might produce. From the front facing side of the website, the site will still be white screened, but with the protection in place, the user can still access the admin panel.

  • There was a discussion whether it would be better for the site to be slightly broken rather than completely broken, but the general consensus was that it is better to white screen because from the Core Team perspective, they cannot be sure of what the PHP error causes, and thus can’t be sure that all the information being shown is meant to be public.

    It is better to white screen the whole website but ensure that access to the admin panel is still accessible. Once logged in, there will be a general notification regarding the WSOD.

PHP minimum required headers

Plugins

For a while, WordPress plugins have been able to set a minimum PHP required comment as part of the plugin header. To date it has not done anything but set the intention that the plugin author is able to declare what PHP minimum version they are willing to support.

Work is being done so that the Add New Plugin admin screen will show all plugins a user searches for, but will not be able to install any plugins that require a newer version of PHP without updating that first. Another task being worked on is blocking plugin updates if the newer version requires a higher version of PHP, same as it currently works if the update requires a higher version of WordPress.

This gives plugin authors better control of what PHP versions they are willing to support, and will hopefully encourage people to upgrade their version of PHP at the same time.

This change will allow plugin authors the choice to use more modern PHP functionality and syntax without worrying their plugin will break for the end user.

Themes

For themes, the Requires PHP header is not implemented yet, as they didn’t have the same readme.txt file up until recently: https://make.wordpress.org/themes/2018/10/25/october-23rd-theme-review-team-meeting-summary/

Now that new themes do have that requirement, there is an expectation that the header will be implemented as well in the foreseeable future. Here’s a ticket for that: #meta-3718

Relevant Trac Tickets

  • #43986 Disable “Install Plugin” button for PHP required version mismatch. This has already been committed to core.

  • #43987 Block plugin updates if required PHP version is not supported – Plugins screen

  • #44350 Block plugin updates if required PHP version is not supported – Updates screen

The latter two trac tickets are currently slated for 5.1 as well, planned for February 21: https://make.wordpress.org/core/5-1/

The feature merge deadline is January 10 though, so it needs to be discussed at the next #core-php meeting whether making it into 5.1 is still feasible.

A prerequisite for these changes is the WSOD protection that needs to be completed and committed by the deadline: #44458

Join in

The group has weekly meetings on Mondays 16:00 UTC on in the #core-php channel of WordPress Slack.

GitHub: https://github.com/WordPress/servehappy

Site Health Check Plugin

The site health check plugin is a way for users to be able to see technical details of their website setup without going into the server side of things. It is useful to conducting top level investigation work without accessing the server directly.

The beta version of the plugin takes the best practices from the Hosting Team’s documentation and checks the server against that. This includes: WordPress version number, plugins and themes are up to date, PHP version number, if HTTPS is active across the whole site as well as a number of other things.

When Health Check gives notifications about upgrading things, it hands users off to plain English documentation to walk them through the process. For example: https://wordpress.org/support/update-php/. Notifications for plugins and themes being up to date are based on the version inside the plugin and theme repo. If a theme or plugin is not present in the repo, it will assume it is up to date and will not give an error.

Eventually, a lot of the Site Health Check plugin will be in core.

The Site Health Check Plugin uses a traffic light system to flag up the importance of a suggested change. The definition of critical vs non-critical update notifications is from a security perspective. If it is a security issue, it’s critical.

Early user testing with the community has shown that the plugin suffers from a lack of designer eye. During WCUS, we have had a designer volunteer to review the interface and give feedback.

This should help with the usability of the plugin and balance it between positive reinforcement of things that are set up as guided by best practices whilst not over-burdening people with extra technical information.

There is some useful documentation on how to use the Site Health Check Plugin: https://make.wordpress.org/support/handbook/appendix/troubleshooting-using-the-health-check/

Join in

– Github: https://github.com/wordpress/health-check

– WP.org : https://wordpress.org/plugins/health-check

Site Health Check Desks & Community Support

In-person support is invaluable. When a user is unsure of what to do, they can find in-person support at their local meetup and WordCamps. To omit any surprises, we can encourage our community to pre-warn and prepare as many people as possible.

The idea of Site Health Check desks has been tested in 3 different WordCamps and 1 meet-up with improvements and suggestions being fed back to the plugin and fliers.

Site Health Checks is an extension of the Happiness Bar, and by asking the simple question “Do you know what version of PHP your website is running?”, people either:

  • Know & it is up to date – get a high-five. Say Awesome and keep up the good work. Pre-warn the next EOL of PHP Dates.
  • Know & it is out of date – highlight the EOL date has already passed and recommend they update their PHP version.
  • If they don’t know, Check if they know how to check. If they do, suggest that they check and that they want it to be 7.2 or higher. 7.1 EOL is in a year.
  • If they don’t know and don’t know how to check, invite them to sit down and the volunteers can help them check using the Site Health Check plugin. DO NOT scrape the site. They can end up being blocked off the servers.

Postcards were created with 5 core things to check. As well as printable table toppers. They are used as fliers for people to know where to download the site health check.

Meetup organisers have also shown an interest in running the site health check and promoting it at their meet-ups.

This is where much of the user testing of both the “Update PHP” information page and the Site Health Check plugin is happening.

Plugins and Themes Plans

Plugins and Themes served from WordPress.org can be automatically checked and updated to be compatible with 7.X. This is because there is access to the SVN where these plugins are being pushed from.

Ideally, plugin authors who have a plugin in the plugin repo will update their plugins to be compatible with PHP 7.X. There are already plugins such as the PHP Compatibility Checker which people can use to check how compatible their websites are with a version of PHP.

How are premium plugins and themes going to be handled?

The plugin team at WordPress.org can contact authors, but ultimately it is up to the plugin author to action the suggestions that are made from the WordPress.org team.

If there is no answer, or the author does not wish to fix errors, then this is a dead end.

Target Dates

WordPress 5.1  ->  ServeHappy notice + White Screen of Death protector

WordPress 5.2 ->  Site Health Check plugin

Where hosting companies come into play

We would like hosting companies to go aggressively, pushing their communities forward before WordPress does.

We know that, as a hosting company, many of you will see the same issues come up during a PHP update. It would be useful to the rest of the group if any information of any PHP errors that are being seen repeatedly and information about which plugin or theme is causing it. It will allow the rest of the team to prioritise which plugins and themes need attention to be fixed across the whole community.

It will also help the support team if any solutions are found to be shared, so that they know what to be suggesting in the forums. We may be able to add notices before a PHP update into the health check which highlights problematic plugins.

Hosts with PHP lower than 5.6 may see some initial notifications before that date.

Hosting company teams are most likely to know other people working in the hosting sector. Above all else – get the word out.  Big hosts are represented well here, but as a community we are aware and worried about the smaller, independent hosters. Talk to your hosting friends. Let them know this is coming. Invite the small hosting companies to join the Hosting Team on WordPress.org for up to date information of what is upcoming and will be effecting hosters.

The more we can update in batches the less burden there is across the whole industry.

Where plugin and theme authors come into play

If plugin and theme authors ensure that their plugins have a PHP minimum version set in their required header, then their plugins and themes will be ready once the PHP requirement is being enforced.

Plugin and theme authors should also ensure that their plugins are compatible with PHP 7.X. Tools such as PHP Code Sniffer (PHPCS) or the PHP Compatibility Checker as mentioned above should help.

Actions from the meeting

– Ensure there is communication with the hosting team regarding release date plans.

–  #core-php should be cross posting ServeHappy notes to the Hosting P2 as well.

– WordPress.hosting has been taken, unsure by who. It would be handy to have WordPress.hosting symlink to Hosting Team P2 to help getting other hosting companies to join the Hosting Team

– Recommend that Hosting Team check and sync up the Best Practices documentation.

– Can someone from the hosting team please review and ensure that Health Check plugin is checking against everything that exists in the “Hosting Best Practices” doc.

– Recommended to Health Check plugin to check out Lighthouse plugin UI.

– Write up more in-depth info for meetup and WordCamp organisers, have postcard and table toppers online so they can be shared and translated easily.

Thanks

The effort to raise the minimum PHP version requirement of WordPress is a big cross- team effort. Big thanks to

  • @brettface for the notes.
  • #core-php, #plugins, #themes and #meta team for their hard work
  • the #hosting team for their input and support
  • @alexdenning from #marketing team for the content review
  • @clorith from #forums for the health-check plugin development
  • WordCamp London 2018, WCEU 2018 and WordCamp Brighton 2018 organisers for allowing us to test the Health Check help desk concept
  • And to the #polyglots team who will be asked in the near future to translate our work for the whole community.

#recap, #servehappy, #wcus

PHP Meeting Recap – November 13th

This recap is a summary of our previous 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: @flixo90 @jdgrimes @jon_bossenger @mikelking @mte90 @nerrad @schlessera

@sergey

Chat Summary

We started the meeting by examining the poll that @flixos90 had made regarding a modified meeting time slot.

As most of the votes went to the 16:00 UTC time slot, and nobody had a specific reason for not using that time slot, we decided to make that new time official from now on.

This means that all subsequent meetings are held at 16:00 UTC from now on.

Then we continued working on the “Before Upgrading PHP” section again, which we are working on in a shared Google Doc.

Here’s a brief summary of the corresponding discussions and decisions:

  • We discussed adding a second “Backup” step after all updates have been done. In case of a rollback further down the line, this would avoid going through all updates again, which incur a big time and bandwidth hit.
  • While discussing how to best add this addition “Backup” step, we came up with the idea of adding small “aside” text boxes to the document, which visually communicate that the content therein is not part of the critical path and should not be considered a blocker in case the user can’t complete that “aside”.
  • We discussed the different animals that Google Docs assigned to the anonymous users, and how they don’t seem to match up everywhere. 😉
  • Regarding the compatibility checker, we discussed whether to include knowledge about the future XWP project that might have an impact here, or not. We decided that we write the content for the current state and context, as there’s no guarantees to when or if any of the WIP projects will be completed and usable.
  • We added an aside to the compatibility checker as well, to warn users against false positives and other detection issues.
  • We acknowledged that our aside might be a bit on the intimidating side, and that we need the help of the #marketing team to rephrase the copy in that regard.
  • We rewrote the “Ask plugin/theme support” topic so that it is clearer and points people to existing resources first before contacting support.

Next week’s meeting

The next meeting will take place on Monday, November 20, 2017 at 16:00 UTC, as always in #core-php, and its agenda will be to finish the rest of the “Before Upgrading PHP” document that we will hand over to the marketing team to get their help with writing the copy. 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, #core-php, #php, #summary

PHP Meeting Recap – September 25th

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 @chasecm @flixos90 @jdgrimes @joyously @mte90 @nerrad @schlessera @sergey @spacedmonkey

Chat Summary

Continuing what was started last week, the agenda for this week was to review the second half of the copy for the “Servehappy” page, which the marketing team has worked on.

  • The first part of the meeting was about reviewing the “Are there risks when upgrading my PHP version?” section:
    • The first paragraph should emphasize more how WordPress consists of multiple parts by individual parties that may cause different kinds of compatibility issues when used together. There should be less focus on the open source part of it.
    • The first two paragraphs can be merged into one:

      In a perfect world, the answer would be “no”. However, the WordPress ecosystem is made up of thousands of themes and plugins (built and maintained by developers all over the world). All the various combinations of these parts that can be added to your site increase the potential for incompatibilities with certain PHP versions. WordPress cannot detect all those possible conflicts automatically.

    • The third paragraph should be omitted since talking about the different possibilities regarding PHP version upgrades does not belong into the section describing risks. The fourth paragraph will not be part of this section either, but can instead be reconsidered for an additional “Before Upgrading PHP” section, which will be worked on later.
    • An extra paragraph should be added to clarify some of the actual issues that may occur:

      Some of the things that could happen when these incompatibilities affect your site, are white screens or unexpected behaviour. If any of these happen to you, you can troubleshoot them (this should link to extra troubleshooting steps elsewhere) or roll back the php version on your server (the rollback part may not always be applicable, so it may be better to strip it out). However, by following the suggestions in the next section, you can drastically reduce the chance to run into any of these issues.

  • The second part of the meeting was about reviewing the “How to Upgrade PHP for your Website” section:
    • The first two paragraphs are good as is.
    • In the third paragraph, it should only be recommended to send an email to the host if the site owner does not find any resources about how to upgrade. The part about them feeling comfortable doing it should be removed, as upgrading PHP itself is a rather simple task compared to some of the steps recommended before the PHP upgrade. When the host provides an interface for it, the upgrade is usually only about navigating to the right area and hitting a button. The paragraph should therefore start like this:

      If you cannot find instructions for your specific host, the best thing you can do is ask them. […]

    • The email template itself should not use specific PHP versions and rather ask for the latest version (this may be revisited, see below):

      I want my website to be as performant and secure as possible with the latest version of PHP. For the server my WordPress site is hosted on, I want to ensure that is the case. If I am not already on the latest version of PHP, please let me know what steps I need to take to upgrade.

    • It may be useful to highlight that, if the hosting provider is unable to upgrade the PHP version, the site owner should consider switching to another host. On the other hand, it could also be clarified that if the site owner is uncomfortable / unable to upgrade to the latest PHP version due to some incompatibilities detected, it is also worth upgrading to the highest possible version that is still actively supported if there is no other way.
    • The section about self-hosted setups and servers managed by the site owner themselves should be removed as it is very unlikely those people are not already aware about PHP upgrades and how they work. This page is for non-technical people, and self-hosting a site does not fit into that scope.
  • Whether it is really the right decision not to mention any specific PHP versions should be revisited. Not mentioning any version will make the information on the page more vague, and regularly updating the page to use the current version should be an easy task, when done right initially. There could be a shortcode for the latest PHP version (currently 7.1) and another one for the lowest PHP version to recommend (currently 5.6), both of which would be used throughout. This would allow to only change the version numbers in one place and have them updated throughout the entire page.
  • As mentioned before, the page should also contain a section about which steps to execute before actually upgrading PHP. This could include things such as using a PHP compatibility checker plugin, checking how well the themes and plugins used are maintained, backing up the site, and more. This is currently not part of the Google document because there isn’t a clear idea for the section yet.

Next week’s meeting

The next meeting will take place on October 2nd, 2017, 18:00 UTC as always in #core-php, and its agenda will be to think about and plan the “Before Upgrading PHP” section mentioned above. Ideas are very welcome and it would be great if you could take some time to think about possible steps in the meantime so that there is already something specific to discuss next week. 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, #marketing, #php, #summary

PHP Meeting Recap – September 11th

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 @dnavarrojr @espellcaste @flixos90 @joostdevalk @jdgrimes @milindmore22 @nerrad @pbearne @schlessera @sergey @sobak @vizkr

Chat Summary

The agenda for this week was to review the current progress and plan how to proceed in the upcoming weeks.

  • @flixos90 shared the outcome of the meeting with the #marketing team that had happened some days ago (read the full chat log): The marketing team has started work on the copy for the planned Servehappy page, based on the drafts the PHP team created over the past couple weeks. A Trello board has been set up, and the actual text is being worked on in a Google doc. The team has set a deadline for September 15th. As of writing this post, the document has been completed. They also offered their help in the future for other things that the page would need, such as graphics and illustrations. A special thanks to the marketing team for their efforts!
  • The next PHP meeting will be used to review and discuss the document in detail and figure out questions or suggestions, if any. Anyone from the marketing team is also very welcome to join this chat in particular!
  • It was decided that once the document is considered to be in a good shape, it is time to pitch the idea of the suggested Servehappy page further. In particular more leadership people need to be convinced of the efforts in order to successfully proceed. The page must be officially affiliated with wordpress.org, whether it is hosted as part of it or at a separate location. This is a requirement so that it is eligible for being linked to from WordPress core itself.
  • @schlessera suggested creating a proposal document that describes the problem the team is trying to solve, the goals the solution should meet, the current state of things and what is needed to get this launched. This will provide clear documentation and can be used in addition to the page document itself to pitch the idea. With this, the team hopes to be able to at least get a “conditional” buy-in.
  • It was discussed whether the page should be part of wordpress.org or whether it should be hosted as a separate website, such as servehappy.com or servehappy.org (in either case it should be an official part of WordPress).
    • Having it as a separate site would perhaps make it interesting for other PHP projects as well.
    • Having it as a separate site would give more flexibility on what the overall page layout and design should look like while with .org, it would obviously need to integrate.
    • Having it as a separate site would give parity with something like browsehappy.com, however the Servehappy content would be much more specific to WordPress, so it may be better suited as part of wordpress.org.
    • Having it as a separate site would allow to create separate pages for the bits and pieces if it makes sense, and guide visitors through them.
    • In the end nobody had a heavy preference for either, so where to host this can be approached rather flexibly, as long as it is based on a clear decision by the core leadership. The core leads may very well also have their own preferences for this.
  • In order to bring more attention to the efforts, it was decided that the best way to start once both the copy and proposal documents are ready will be to first publish the proposal on the make blog and then bring it up at the weekly core dev-chat. The post should be available in advance so that it gives people time to prepare. It may also be useful to schedule regular update slots in the dev-chat meetings, in order to provide information on where the project is at and maintain traction.
  • The proposal document should also contain all suggested integration points with core.
    • What feature needs to integrate with the page?
    • Where should the link point to?
    • Is dynamic content transported through the link needed? If so, which GET parameters would the page need to support?
  • Using GET parameters for some dynamic parts of the page would give the visitor a better feeling their specific issue is addressed by the page. However, it needs to be ensured that all data passed is not controversial regarding privacy in any way. It needs to be entirely anonymous.

Next week’s meeting

The next meeting will take place on September 18th, 2017, 18:00 UTC as always in #core-php, and its agenda will be to review and discuss the page document the marketing team has worked on, as described above. 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