PHP Site Health Mechanisms in 5.1

Update: 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

PHP Meeting Recap – October 22th

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

    • We started discussing roadmap and priorities for Servehappy. It was not clear for everyone what the current state of the project is. Based on latest information we had, we settled on the fact that Servehappy is still considered a blessed task and that it was just moved out of 5.0 because of time constraints. Current goal is to get it included in a minor release following 5.0, as already suggested by the 5.0 release lead.
    • There’s an immediate need for getting more testers to actually test WSOD protection on real, complex sites with multiple plugins and custom code.
    • We discussed including the WSOD protection fork in the beta tester plugin so people can easily switch, but this would violate the plugin repository guidelines.
    • We also discussed what it would entail to commit it early into trunk to get it to run on the wordpress.org infrastructure. We should create a #meta ticket to discuss the details of this.

Next week’s meeting

  • Next meeting will take place on Monday, October 29th, 2018 at 15:00 UTC in #core-php.
  • Agenda: Continue discussion about getting more people to test WSOD protection.
  • 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, #core-php, #servehappy, #summary

PHP Meeting Recap – October 15th

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

  • We discussed how the php-error.php drop-in in WSOD protection and the 500.php in the PWA feature plugin would relate to each other and how work could potentially be deduplicated/harmonised.
  • The php-error.php drop-in in WSOD protection is used server-side when a fatal error was caught. As it could be triggered by a theme or before the theming functionality has actually been loaded, it cannot be styled through a theme. It is “always-on”, though, and catch fatal errors very early on in the bootstrapping process.
  • The 500.php template from the PWA feature plugin is displayed by client-side code when the request made by the service worker returns a HTTP 500 status code. To achieve this, an offline cache is built through the service worker, and the site is requested to do a server-side rendering of the 500.php once so that it can be cached for the case where it is needed. Because of this, it can be styled through the theme, as the request to actually render is is a normal “render a page template” request. It requires for the service worker to have been installed previously and the server to have successfully rendered the page template once so that it can be cached. This means that there scenarios where this mechanism is not yet available.
  • There is an error query variable that would be a good fit to reuse for the 500 and offline mechanisms of the PWA feature plugin, but this would first require a change in WordPress Core as this query variable is currently being unset. There is already a Trac ticket to change this. For now, the PWA feature plugin uses a custom query variable wp_error_template instead.
  • Currentl functionality already should work as-is to always catch fatal errors on the server side and display the php-error.php drop-in, and if the service worker is active and the 500.php has already been cached, it will be used to progressively enhance the php-error.php drop-in to style it according to the current theme.
  • @westonruter suggested a change to make this more reliable and explicit by adding header information to the WSOD screen along the lines of X-WP-WSOD: true.
  • We should also add some token to the rendered page, as the headers might already have been sent in some scenarios, like a special form of HTML comment.
  • @joyously has added that for diagnosing errors, having access to even half of a HTML page can help, so cleaning everything out might further obfuscate the nature of errors.
  • @flixos90 argued that the php-error.php might not even be needed, with PWA as a later option in the future.

Next week’s meeting

  • Next meeting will take place on Monday, October 22nd, 2018 at 15:00 UTC in #core-php.
  • Agenda: Discuss current 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, #summary