Fatal Error Recovery Mode in 5.2

WordPress 5.2 will allow administrators to fix or mitigate fatal errors on their site that would previously have been impossible to address without developer interference and modifying the codebase. Even in the case where a fatal error would commonly have made the backend completely inaccessible (for example through a so-called “white screen of death”), administrators will now still have the chance to log in and do something about the issue.

When a fatal error occurs, a user-facing error screen will display that informs the user/visitor that the site is experiencing technical difficulties. More importantly though, when such an error occurs, an email will be sent to the admin email address, informing about the issue and including a secret link to new feature called the “recovery mode”. Clicking this link will have the user enter this recovery mode, which works by placing a cookie on the current client.

When in recovery mode, plugins and themes (also referred to as “extensions”) which are causing a fatal error are paused for that client, ensuring they can work around these errors and access their admin backend as regularly. After entering recovery mode, the user needs to log in. It should be highlighted though that recovery mode itself is not tied to a specific user, but only to the cookie existing on the client.

After logging in, an admin notice will indicate that recovery mode is enabled. Furthermore, the user will be informed about which plugins/themes are currently paused due to fatal errors, and what exactly these errors are. They then have the possibility to address the issue in their preferred way:

  • They can completely deactivate the extension, e.g. when maintaining a working version of the site matters more than that extension’s functionality. This is typically a temporary solution, but provides an immediate resolution.
  • They can fix the problem if they have the technical capabilities, and afterwards resume the extension.
  • They can file a support ticket with the author of the respective extension or contact a developer, pointing out the exact error.

At any time, the user can decide to exit recovery mode, by clicking a button that permanently appears in the admin bar while in recovery mode. Exiting recovery mode will wipe the cookie from the client and thus cause all extensions to run as usual again. Keep in mind that if an extension is still broken, the fatal error will remain.

Admin backend while in recovery mode. Highlighted are the notice and the exit button in the admin bar, indicating recovery mode is active.
Admin backend while in recovery mode

The main benefit of recovery mode is to inform administrators about fatal errors on their site and allow them to still access their backend and decide what to do about the problem, rather than presenting them with the typical “white screen of death” which they cannot do anything about. It is impossible to automatically fix such errors, but recovery mode allows working around them by pausing the broken extensions. Pausing only happens for the client that is in recovery mode, and thus does not have any global implications. With a broken extension, only the user in recovery mode can access the broken areas; for the other users the site remains in a broken state until the issue has been fixed or mitigated.

Developers

There are a couple of ways that developers can integrate with the new recovery mode features:

  • Plugins that would like to enhance recovery mode can call a new function wp_is_recovery_mode() to check for whether it is active.
  • Environments can override the way that recovery mode is set up and validated if they prefer to use a different method or to purely enable it via code. A must-use plugin for example can set a constant WP_RECOVERY_MODE_SESSION_ID that needs to contain an arbitrary session ID, which will then be used to store recovery mode-specific data for that session. Having the constant available will force-enable recovery mode. However, this mechanism must be used with special care, as setting the constant unconditionally would result in recovery mode being globally enabled.
  • The template for the screen indicating that a fatal error occurred can be customized by using a php-error.php drop-in, similar to other previously existing drop-ins such as db-error.php.
  • The entire shutdown handler can be overridden by using a fatal-error-handler.php drop-in. This drop-in must return an instance of a class extending the default WP_Fatal_Error_Handler class. If that is the case, the instance will be used instead of the default one.
  • Environments that would like to disable the fatal error handler and recovery mode functionality altogether can do so by setting a WP_DISABLE_FATAL_ERROR_HANDLERconstant, typically in wp-config.php. The enabled status for the handler should be checked for by using a new function wp_is_fatal_error_handler_enabled().

Background

The fatal error recovery mode is a revised approach for what was originally the fatal error protection mechanism slated for WordPress 5.1, but then reverted due to some critical concerns. The client-specific recovery mode mitigates these concerns, so this time it is here to stay.

For further background information, please refer to the announcement post for the revised approach, the overarching Trac ticket, and generally the list of related 5.2 tickets.

#5-2, #dev-notes, #servehappy

The Improved Fatal Error Protection

Following the post on Site Health mechanisms released in WordPress 5.1, the feature labelled “Fatal Error Protection” (see #44458) was reverted, resulting in it not ending up as part of that release.

This was necessary due to several security concerns, partly discovered by the team, partly by third-party security experts:

  • A bad request could be made to the WordPress site targeting a specific plugin, for example with a request method or parameters that said plugin does not expect. Following that, the plugin might throw an exception, causing the plugin to be paused – i.e. an attacker could intentionally use such requests to force pausing of a plugin. This was arguably the most severe concern, since, while plugins should absolutely validate parameters rather than causing a fatal error, many have weaknesses in this area.
  • A flaw in one plugin could cause another plugin to be paused, rather than the flawed plugin itself. A good example of this is exceeding the memory limit: plugin 1 runs a way too expensive procedure, but then the memory limit is reached by a random plugin 2, causing the latter to be the origin of the fatal error.
  • A plugin failure in the frontend could affect that plugin to be paused in the backend, although it might not have caused a fatal error there. The frontend is a “non-protected endpoint”, for which plugins or themes should never be paused.

Multiple follow-up tickets were created to mitigate these issues, but eventually the team came to the conclusion that all these tweaks would have only slightly reduced the attack vector, rather than eliminating it.

A completely new approach was required, which would require additional time to be planned and implemented.

This post outlines the new proposed approach in detail. Please share it and request feedback, both from community members and people less active in the WordPress ecosystem – particularly security experts and hosting engineers. We would like to ensure that the approach is solid to proceed with before it is fully implemented.

Goal of the Fatal Error Protection

The primary goal of the feature remains the same as it was originally:

It should be possible for an administrator to access their admin backend, even in case of a fatal error.

While this does not reduce the risk factor of a PHP or extension update, it encourages users to perform an update despite the risks, as they will still be able to at least temporarily fix the problem.

If an update breaks their site, it will currently cause a so-called “white screen of death”. With the fatal error protection, it should display a specific screen informing the user about that there is a technical problem with the site. The administrator should then be able to access their backend. There they can look at the extensions that are broken and either deactivate them to fix the problem, or find out about the error and forward it to a developer of their choice. Even in the latter case, the administrator might see enough value in deactivating the broken extensions to at least temporarily ensure the site’s frontend is accessible again.

A secondary goal of the feature is to inform the site owner about fatal errors that have occurred for visitors of their site, without the owner being involved. This ensures that in case an administrator forgets to check their site after an update or if an error has happened in a rather specific area, they still find out when their site is inaccessible.

Explicitly not a goal of the fatal error protection is error logging. While it should be possible for an administrator to see the latest error which an extension has caused and which has resulted in that extension’s pausing, not more errors than necessary as that should be stored in the database. Error-logging is a different feature focused more towards developer audiences, and an implementation using the WordPress database could easily clutter that and decrease performance of a site, thus introduce negative side effects for minor benefits. It should also be noted that the fatal error protection is not related to recovering a hacked site.

As the feature is targeted towards rather non-technical administrators that do not have capabilities to access or modify their site’s codebase, it should be opt-out via code mechanisms such as constants or filters, so that more advanced developers can disable the feature if they prefer.

The feature is targeted for WordPress 5.2 and will be in support of bumping the minimum required PHP version of WordPress to 5.6, which will happen as part of that release as well.

Introducing a Recovery Mode

What we recognized is that the idea of pausing extensions (plugins and themes) globally is the problem. If an attacker can force-pause extensions, essentially causing them to be deactivated on protected endpoints such as the admin backend or the login page, it can have severe impact for example on security. A security plugin might have a random weakness that, while being an indicator of a lack in quality, is not necessarily security-relevant. However, if that plugin also added two-factor-authentication to the WordPress login page, using the security-irrelevant flaw to pause the plugin would allow the attacker to bypass two-factor-authentication on the site.

The idea of pausing extensions makes sense, as it is impossible to act more granularly on a fatal error due to the lack of sandboxing in WordPress. However, it needs to be ensured that pausing happens only for certain users that have sufficient capabilities to fix the issues, either by permanently deactivating the flawed extension or contacting a developer to take care of it – typically the site owner, which in the case of WordPress is arguably an administrator user.

The new approach relies on the concept of a recovery mode. Only specific users should be able to enter recovery mode, and only in recovery mode extensions should be eligible for being paused. This ensures that a fatal error does not have global impact. If an attacker intentionally triggered a fatal error in a plugin, they would not get any more from that than they would at the moment.

The Intended User Flow

View Original (props @miss_jwo)

There are two different scenarios for when a fatal error happens.

A user is browsing the site (logged-in or not).

  1. A fatal error occurs, causing the user to see a screen saying that the site is experiencing technical difficulties.
  2. At the same time, a notification email is sent to the admin email address, informing about the fatal error, including the error details and a link with a secret nonce to enter recovery mode. This process is rate-limited, so a maximum of 1 notification email will be sent per hour (filterable).
  3. If the user does not have access to the admin email address, the process stops here – they should not be able to enter recovery mode then.
  4. The user accesses their emails and clicks on the included recovery mode link.
  5. The WordPress site verifies that the nonce in the link is correct, sets a cookie containing another secret key on the user’s machine, and redirects them to the login page. At this stage, the user (or more specifically the client) has effectively entered recovery mode. On every subsequent request, the cookie will be verified by checking the secret key.
  6. The user can now regularly login. If a fatal error occurs on the site, the extension causing it will be paused for the user, followed by a redirect to the same URL, until no longer a fatal error occurs.
  7. The user can now reliably browse the admin backend. In the dashboard, they will see a notice informing about which extensions are currently paused for them. On the Plugins / Themes screen, they can either resume these extensions (if they think the problem has been fixed) or completely deactivate them (with that action affecting the site globally, as usual).
  8. If the user wants to exit recovery mode, there is a link in the admin bar that lets them do so. Once the user clicks that, the cookie will be deleted and extensions will no longer be paused for them.

No user is browsing the site.

  1. A fatal error occurs (for example in a Cron request), causing the same screen to be internally rendered (even though technically nobody will see it).
  2. At the same time, the notification email mentioned above is sent (if not over the rate limit), to inform the person associated with the admin email (typically referred to as the “site owner”) for the website about the error.

Further Considerations

There are a number of additional considerations for the feature, other than the user flow:

  • The feature should only support pausing of extensions that are user-controllable, as in that access is not necessary to set them up. It therefore excludes support for drop-ins and must-use plugins.
  • At least in the first iteration of the feature, it should also not support multisite and the pausing of network plugins. While these plugins can technically be altered without access to the codebase, setting up multisite requires access to the codebase and is an advanced and, relatively seen, rare use-case. Adding support for multisite and network plugins would require much additional exploration and work regarding UI (e.g. should only network administrators or also site administrators be able to access the backend and resume those plugins?). Furthermore there are technical quirks that would need to be figured out in addition (cookie constants, which are needed for the new approach, are only available after network plugins have been loaded). While the feature could generally be supported in multisite even without supporting network plugins, it was decided to explicitly disable the fatal error handler and recovery mechanism for multisite in the first iteration, to explore a solid approach in the future.
  • It is impossible to pause WordPress core, which should not be an issue as core defines which PHP versions it supports and should be compatible with all of them. Even more than today though, it is important to ensure that full compatibility with the latest PHP versions is maintained.
  • The feature cannot function properly if a connection to the database or object cache (if used) cannot be established. The implementation will account for these cases so that it does not trigger PHP notices or exceptions, but it is impossible to work around these limitations further.
  • The mechanisms which relate to initiating the recovery mode must all be error proof and therefore executed early, before extensions which might cause breakage are loaded. This technically means execution must happen after the call to register_theme_directory() in wp-settings.php. These mechanisms are:
    • Verifying a request made from a recovery link, setting the recovery mode cookie and redirecting the user.
    • Verifying the recovery mode cookie and based on that enabling recovery mode for the current request.

Future Iterations

While the previously outlined approach is targeted towards WordPress 5.2, there is room for future iterations that can be released in follow-up versions. Current ideas include:

  • Improving the flow of how an administrator can receive a recovery link, since, in several cases, the admin email address does not cover such users correctly. The fatal error screen could show a link to a new screen that looks similar to the password recovery screen. Here a user could enter their email address, and if they had sufficient permissions on the site, a recovery link would be sent to their email address. In other words, in addition to the link going out to the admin email address, administrators could request their own recovery link manually.
  • Adding support for multisite and network-active plugins. Due to both technical and UI complications and the rather small and usually more advanced amount of multisites, it was decided to omit this for the first version. Since network plugins are however still user-managed (contrary to drop-ins and must-use plugins), it would make sense to eventually support them as well. This would also require thinking about a solid flow to network-resume plugins and handle network-wide recovery mode and related user capabilities.
  • Supporting further customization. While the first version allows overriding the feature, in the future more granular adjustments might become possible. Most likely, this will happen naturally through developer requests that can then be evaluated.

Feedback Requested

We would like to get feedback on the proposal, to make sure to get the implementation right this time. In particular, security and UX require thorough reviews. Please share your thoughts, and also spread the word about this post with others you think would be interested. You can also track the implementation via #46130 and the accompanying pull-request.

You can give feedback by commenting on this post or in the #core-php channel on Slack. We also have weekly meetings on Monday, 16:00 UTC.

Props @afragen, @miss_jwo, @nerrad, @spacedmonkey, @timothyblynjacobs for review.

#5-2, #servehappy

PHP Site Health Mechanisms in 5.1

Update (2019-03-04): The fatal error protection mechanism explained here has been pulled out of the 5.1 release as it had several flaws critical enough to postpone the feature. A new path to address the issues is underway via #46130 and is intended to be released as part of WordPress 5.2.

Update (2019-01-21): A few critical naming changes have been made regarding the fatal error protection since the post was originally published. Most importantly, the drop-in to override the new shutdown handler is now called fatal-error-handler.php, and the class to override is called WP_Fatal_Error_Handler. Furthermore, a new WP_DISABLE_FATAL_ERROR_HANDLER constant allows entirely disabling the feature via wp-config.php. The rest of the post is also updated to use these new terms, however you might need to update your code if you built anything based on the previous information. For a history of what exactly has changed since the original post date, please refer to the umbrella ticket #44458.


WordPress 5.1 will start showing notices to administrators of sites that run on long outdated PHP versions. This part of the Servehappy and more globally Site Health projects paves the way to a more secure and performant web and, more specifically to WordPress, to a bump of the minimum required PHP version.

The current threshold for which PHP versions to display the notice will be anything below 5.6. While the lowest PHP version still receiving security updates is currently 7.1, the idea is to not go all the way there at the beginning to limit the support load. PHP 5.6 is the intended version to bump WordPress requirements to, and from then the threshold for the PHP notice will increase granularly, with the goal to over time catch up with the actual PHP version progress. The threshold is managed via a new Servehappy API endpoint on wordpress.org, so the version numbers can be modified independently of a WordPress release.

Warning about outdated PHP version in WordPress backend

The link from the button points to a new support page about updating PHP which briefly explains the problem and then dives into how to prepare for an update and perform it. The link URL in WordPress is a translatable string so that locales can provide their own versions of the page. In order for that process to be straightforward, the content is managed through a page template, with the translation strings thus being available in GlotPress (see https://meta.trac.wordpress.org/ticket/4004). Furthermore, the link can be adjusted via either an environment variable WP_UPDATE_PHP_URL intended for hosting providers or a filter wp_update_php_url for a more dynamic approach on the code level. Replacing the URL should happen in cases where a more specific guide to update PHP on the given environment exists. The hosting provider is the preferred source to set this, so plugins are recommended to honor this priority and not unconditionally override it. Furthermore, if the URL is changed in any way, the URL to the original WordPress resource is still maintained as an additional link, which you can see in the following screenshot:

Warning about outdated PHP version with custom URL and related annotation

For further background information on these changes, please refer to the respective tickets #41191 and #45686.

Fatal Error Protection

To help the process of recovering errors that result from updating the PHP version, a mechanism has been implemented to detect fatal errors and, in certain designated areas of WordPress, recover from them. While updating PHP is mostly fairly straightforward and popular plugins and themes are typically maintained well, not necessarily all extensions are compatible with the latest PHP versions yet. So unfortunately there might be cases where a plugin or theme causes the WordPress site to no longer be accessible after the PHP update by causing a fatal error.

With the so-called WSOD protection (white-screen-of-death protection), WordPress will recognize when a fatal error occurs and which plugin or theme is causing it. When accessing the admin backend, the respective extension will be paused, allowing users to still log in to their site so that they can (at least temporarily) fix the problem. Once the extension is known to be fixed, it can be resumed from the backend. While this does not necessarily make updating PHP easier, it lowers the burden of possibly running into the case where you are completely locked out of your site when you do not have access to the codebase.

Extensions are only paused in the admin backend and a few other areas while for example the frontend stays unaffected, and thus broken. Since it is impossible to predict which functionality the broken extension is responsible for, it would be dangerous to have it disabled in the frontend. It is more clear to a user accessing the site to see a message that it is currently not accessible rather than, without notice, no longer having access to a certain part of the key functionality. In the frontend, a message that the site is currently inaccessible will be displayed via a regular wp_die() call, with a link to the admin backend. Sites that would like to modify this output can use a new php-error.php drop-in that should send the necessary HTTP header as well as the output.

Default output in the frontend when WSOD protection detects has detected an error

Note that, while the primary reason for implementing the fatal error protection mechanism was making the process of updating PHP less “dangerous”, it is technically not tied to the update at all. In fact, it will be enabled permanently and discover fatal errors under any circumstances.

For sites that prefer to alter this behavior or sites that would like to omit the WSOD protection altogether, it is possible to add a new drop-in file fatal-error-handler.php. That file should declare a custom shutdown handler class for treating fatal errors that extends the default WP_Fatal_Error_Handler, and then return the instance of it to use. The default class’s functionality is split into distinct methods so that it is easy to reuse and override as granularly as necessary in a child class. The functionality can also be disabled entirely if that is preferred, via a new constant WP_DISABLE_FATAL_ERROR_HANDLER or, more dynamically, a corresponding wp_fatal_error_handler_enabled filter.

For further background information on these changes, please refer to #44458.

Honoring Plugin PHP Version Requirements

When browsing plugins to install, WordPress 5.1 will display a warning for those plugins that require a higher PHP version than the one currently active. While that screen previously already included such information about WordPress version compatibility, it now does the same for PHP. Furthermore, for both of these potential issues, WordPress will now enforce these requirements, disabling the button to install such plugins.

This is only a first step in enforcing version requirements of plugins and themes. In a future WordPress version, these restrictions will expand also to updating or activating plugins and eventually cover themes as well.

For further background information on these changes, please refer to #43986.

#5-1, #dev-notes, #servehappy

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 – December 17th

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.

You can find this meeting’s chat log here.

Chat Summary

  • The meeting focused on the individual pieces that are left to complete so that the most essential Servehappy parts can become part of the WordPress 5.1 release (planned schedule has first Beta set at January 10th).
  • For the fatal error recovery mechanism (see #44458 or GitHub PR for development) the following steps are needed:
    • Add support for recovering errors by the theme by pausing it. It was determined before that the admin can work without an active theme, so implementation of this should be straightforward based on the existing code that already handles this for plugins.
    • In addition to displaying a note in the frontend when an error occurs (customizable via a php-error.php drop in), an email with the same message should be sent to the admin email address.
    • @schlessera will take care of implementing these two remaining tasks.
    • The multisite team will furthermore have an additional look at the existing implementation of multisite support.
  • A few updates are required for the Update PHP page:
    • Instead of having the content coming from the editor, it should be hardcoded and displayed via a template so that translation of the content is more streamlined and can happen via GlotPress. Furthermore it makes it a quicker process to add visual assets to the page later. @flixos90 is taking care of this.
    • The page slug needs to be changed from upgrade-php to update-php, as previously discussed, including a redirect. @sergeybiryukov has already completed this work.
  • For the actual notice in core itself, a few tweaks need to be added.
    • The version numbers need to be updated for WordPress 5.1.
    • The link URL to the page needs to be updated to account for the slug change.
    • The link URL needs to be customizable via both an environment variable (to be set by hosting providers) and a filter (for later adjustments in the codebase).
    • @flixos90 is working on these updates as part of #45686.
  • In the Servehappy API endpoint, the recommended PHP version should be set to 7.3, and the lowest acceptable version should be set to 5.6 to account for the future version bump. On any version below that, WordPress users will see a warning. Furthermore the information on official PHP version support needs to be updated as both PHP 5.6 and 7.0 are no longer support (or will be in very few days). This update has as of now been committed already as well.
  • During the work on the Meta changes in the aftermath of the meeting, it came up that adjusting version numbers exposed by wordpress.org should become a more straightforward process that can happen in a central location. This part is not crucial to have prior to WordPress 5.1, but is a minor tweak to make maintenance simpler in the future.
  • Still left is enhancing the page content with visual assets. It was agreed that these should not contain any language-dependent text. Among the suggestions were:
    • a diagram of how the server hardware, PHP, and WordPress relate to each other
    • a timeline of PHP version history
  • None of the attendees felt capable or had availability to work on such visual assets. If you can help with this over the next couple weeks, please let us know in the comments or the #core-php channel on Slack.
  • Due to the holidays in many parts of the world, the meetings in the next two weeks are cancelled. Finishing the features for WordPress 5.1 is a high priority though, and communication should continue asynchronously as needed. The next official meeting will take place only a few days before the intended 5.1 Beta release, so at that point everything should preferably be good to be merged.

Next week’s meeting

  • Next meeting will take place on Monday, January 7th, 2019 at 16:00 UTC in #core-php.
  • Agenda: Finalize remaining WordPress 5.1 work in order to be ready in time for the first Beta (Janurary 10th).
  • 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.

#php, #servehappy, #summary

PHP Meeting Recap – December 3rd

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.

You can find this meeting’s chat log here.

Chat Summary

  • @drewapicture announced that he’d start working on a proposal to add modern PHP best practices to the core handbook at WCUS contributor day.
  • The discussion about feature flags from the previous week was picked up again, particularly regarding the trade-offs of relying on a (network) option vs relying on a constant or environment variable.
    • Since some of the processes to be tested are executed very early in the WordPress bootstrap process, a variable that can be set in wp-config.php or earlier should be used. There possibly could be a wrapper function to access that value, including a filter that would allow adjusting the constant value dynamically by code that would run later.
    • WP-CLI could also be used to “more dynamically” set the constants.
    • It was mostly agreed that the Beta Tester plugin should somehow incorporate the feature flags functionality, in favor of core, at least initially.
    • Eventually, it was summarized that the topic should get picked up again later, as the WSOD protection mechanism (see #44458) is not blocked by this and should move forward.
  • Further conversations on the current state of the project will happen at WCUS, with the results being published in a recap. The meeting on December 10th is cancelled because of WCUS and related travel.

Post-WCUS Update

  • As mentioned during the State of the Word, WordPress core aims to raise the minimum required PHP version to 5.6 by April 2019, and to 7 by end of 2019 – a great success for the ecosystem and the Servehappy initiative.
  • A conversation between members of the core, community and hosting teams happened during contributor day, planning the steps ahead for both Servehappy and the overall Site Health project that it is part of. A detailed summary of this will be published separately.
  • The goal for the initial parts of Servehappy is to release them ahead of the PHP version bump, likely as part of WordPress 5.1. Due to the intended version bump, the core notice should be displayed on all PHP versions below 5.6, contrary to the originally intended idea of only targeting 5.2 initially.

Next week’s meeting

#core-php, #php, #servehappy, #summary

PHP Meeting Recap – November 19th

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.

You can find this meeting’s chat log here.

Chat Summary

  • @joyously asked about the current state of Tide. @flixos90 added that he is not clear on where it currently stands, but once it is open for projects like Servehappy to integrate with it, it would make a great use-case. Automating the PHP version compatibility might be more reliable in the long run than requiring plugin/theme authors to manually keep that information up to date.
  • The topic of having a range of supported PHP versions for each plugin was discussed throughout the meeting.
  • Information of a maximum supported version of course helps the user to determine its compatibility, generally. However, it can also have negative implications on the PHP efforts: In case the maximum supported version information is not accurate, it will make site owners hesitant from updating PHP, for no reason. Particularly since this conflicts with the project’s goal, caution is required.
  • Neither the plugin/theme author nor an automated code-sniffing based tool can reliably provide compatibility information. Arguably, the latter will end up with more accurate results in the long run, but it still will include many false positives (or false negatives).
  • Due to this problem, there was mostly consensus that no tested up to PHP version should be exposed at this point. While both the minimum and maximum versions are not reliable, the maximum version is more likely to have a negative impact on the project’s efforts.
  • Another topic discussed was the safeguarding of such incompatible plugins and themes, when they are attempted to be used. A site owner should be prevented to interact with such an extension as early as possible, i.e. when installing it. If it is installed through a way that WordPress cannot control, such as uploading manually, then it should at least apply the same restriction on activation. A follow-up discussion to the meeting questioned whether this restriction should be enforced, or alternatively only suggested, for example by using indicative colors in the UI. 
  • In that regard, it needs to be ensured that the more experienced users are accounted for as well, in case they want to be informed of fatal errors in the more traditional way and get around the safeguarding mechanisms. An idea could be to provide a constant or otherwise configurable flag to disable the safeguarding mechanisms, which could cover both the extension restriction and the WSOD prevention. By default these should definitely be enabled, to account for the majority of users. This being configurable would allow to circumvent the hard restrictions, which are preferable for the common case.

Next week’s meeting

  • Next meeting will take place on Monday, November 26th, 2018 at 16:00 UTC in #core-php.
  • Agenda: Open floor.
  • 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.

#core-php, #php, #servehappy

PHP Meeting Recap – November 12th

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.

You can find this meeting’s chat log here.

Chat Summary

  • @schlessera adapted the README.md in the Servehappy repository so that it just links to the Feature Project page, to avoid requiring both to stay in sync.
  • Adding support for PHP version requirements to themes was discussed (Meta Trac #3718). The current state of the requirement for themes to have a readme.txt file does not seem to be clearly defined, as the only source of truth is the combination of an old blog post from 2015 and its collection of comments.
  • @afragen proposed to split the individual next actions for theme support into separate tickets, just as we did with plugins.
  • We also initiated contact with one of the team leads of the #themereview team (@williampatton) to discuss the current state of the theme’s readme.txt requirements.
  • @schlessera noted that while it seems we need to help move some unrelated stuff forward to get around our own blockers, we should be careful to avoid taking on too much responsibility and wasting our time on unrelated efforts.

Next week’s meeting

  • Next meeting will take place on Monday, November 19th, 2018 at 15:00 UTC in #core-php.
  • Agenda: Open floor.
  • 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.

#core-php, #php, #servehappy, #summary

PHP Meeting Recap – November 5th

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.

You can find this meeting’s chat log here.

Chat Summary

  • Note that, in order to maintain the original time in most parts of the world after the end of daylight saving time, the meeting time has been adjusted from 15:00 UTC to 16:00 UTC.
  • Due to the focus on Gutenberg and the resulting lack of activity in other areas, this and the following meetings should preferably be used for some “housekeeping”, reviewing the project roadmap and planning the next steps after 5.0.
  • @flixos90 asked to review the Servehappy feature project page, since that has not been updated in a long time. The page would later be updated to reflect some of the additional requirements that came up mid-2018 and to show the currently planned timelines for all features in the project’s scope, plus links to relevant resources and tickets.
  • @afragen brought up #44619 which had not been tagged with the “servehappy” keyword before, mentioning that the ticket is close to ready. @sergeybiryukov pointed out that it should receive design feedback first.
  • @joyously asked about the plans for themes requiring certain PHP versions. While nothing has been developed in this regard yet, themes should eventually be able to specify a minimum required PHP version, just like plugins. This information should be available through the Themes API, and WordPress core should implement techniques to restrict installation, updates and activation of such themes if the requirements are not met, again just how it has been worked on for plugins for the past couple months. However proceeding with this is currently blocked by the lack of theme readme support for wordpress.org, since the minimum requirements should be specified via the readme.
  • The Tide project could in the future be used as an additional means to determine PHP compatibility of plugins and themes.

Next week’s meeting

  • Next meeting will take place on Monday, November 12th, 2018 at 16:00 UTC in #core-php.
  • Agenda: Review future proceedings for the project and refine roadmap and priorities.
  • 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.

#core-php, #php, #servehappy

PHP Meeting Recap – October 29th

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.

You can find this meeting’s chat log here.

Chat Summary

  • There was only very little presence/activity on October 29th.
  • Probably as a result of this, @nerrad asked whether it would make sense to “pause” the #core-php meetings until after WordPress 5.0 has been released. A lot of people have to focus on making their products/customer sites Gutenberg-ready and cannot invest the same amount of time into working on Servehappy while this is going on.
  • @nerrad also hinted at the possibility that the current lack of testers for WSOD protection could be due to the same reasons.
  • While discussing what the blockers actually are and what parts of Servehappy could be considered “ready to go”, we agreed that it would be useful to post a “State of Servehappy” recap post. @schlessera will prepare a draft for this to discuss.

Next week’s meeting

  • Next meeting will take place on Monday, November 5th, 2018 at 15:00 UTC in #core-php.
  • Agenda: Open floor.
  • 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.

#php, #servehappy, #summary