WordPress 5.1 to Introduce New White Screen Protection Feature, Beta 1 Now Available for Testing

WordPress 5.0.3 was released this week with more than a dozen fixes related to the block editor. The automatic background update has gone out and 23.2% of sites are currently running on 5.0+, with 47.2% hanging back at 4.9. Meanwhile, work on WordPress 5.1 charges forward and Beta 1 is now available.

One of the projects Matt Mullenweg identified for 2019 was to merge the Site Health Check plugin into core to assist with debugging and encourage “good software hygiene.” The Site Health Check project, formerly called “ServeHappy,” began with the goal of helping users get their sites running on supported versions of PHP but has evolved to include other aspects of site maintenance and debugging.

WordPress 5.1 brings one of the most exciting aspects of the Site Health Check project into core. It introduces a new white screen of death (WSOD) protection feature that catches fatal errors so that users can still log into the admin to attempt to resolve the issue. In the past, non-technical users would have to contact their hosting companies or FTP into their files to try to fix plugin or theme compatibility issues by turning things off.

In preparation for WordPress’ highly anticipated minimum PHP version increase, 5.1 will display a warning and help users upgrade their version of PHP. The minimum will be bumped to 5.6 in April and, depending on feedback, will be bumped again to 7.0 in December 2019.

“This project benefits not just WordPress users, but also the surrounding PHP ecosystem as a whole,” Jenny Wong said in the notes she published from the Site Health Check Project review at WCUS 2018. “Our hope is that this will prompt a lot of PHP updates across the web.”

If you want to take advantage of more features from the Site Health Check plugin, you can install it from WordPress.org and visit the Dashboard > Health Check for a detailed overview of your site. It also has a very handy troubleshooting mode that enables a vanilla WordPress session, where all plugins are disabled, and a default theme is used, but only for your user. This works without disrupting the way the site displays to visitors.

WordPress 5.1 also introduces some updates for developers, including the ability to replace the cron system with a custom cron handler, set a custom location for WP_DEBUG_LOG, a new wp_blogmeta table, and a few other changes. 

WordPress 5.1 is currently slated for release on February 21. The upcoming release is a big step on WordPress’ journey to becoming even more user-friendly. The idea that users will never again be locked out of their sites due to a WSOD is a major enhancement that will greatly improve the way they interact with WordPress’ plugin system. It also makes the prospect of installing new themes and plugins less daunting for non-technical users.


7 responses to “WordPress 5.1 to Introduce New White Screen Protection Feature, Beta 1 Now Available for Testing”

  1. I saw the WSOD protection on Twitter and was very excited about that. I think this is an important improvement for WordPress as it offers a great user experience when they accidentally install a bad-coded or quick-release-without-testing-plugins. With the access to the admin area, they’re able to see what’s wrong, disable the plugins and get their site back.

  2. It’s easy to poo on poo things like Gutenberg, but we have to count the hits, too and not just the misses.

    This is awesome, and appreciated. Also, who do I kiss for the code editor checking your code before letting it commit so you don’t go all white screen when people won’t give you FTP access? Literally hours of life and …er…mmHg of blood pressure for every errant semicolon or curly brace that normally would have been a time vampire in the past.

    • A lot of people complained about that particular feature. Because it does not work in some situations, where you have unusual server configurations, or poorly made plugins, or excessive “security” rules in place. In all those cases, it just doesn’t allow code changes to be made, and people got furious about that.

      This is the case with pretty much all new features. It won’t work for some people, and they get super vocal about the perceived loss of functionality.

      • Ah, interesting perspective. I guess I meant the idea and the intended execution. In my experience, Dreamhost’s modsec overreach makes most things unusable, but that’s less of a reflection on the things themselves than DH.

        The idea of someone’s setup meaning the old editor leaves their editing impeded vs. having a compatible setup but being shot out of the sky for a simple mistake. I make more simple mistakes than I do run into tricky setups, so I definitely am partial =)

        I will say, one thing I noticed with it is, sometimes it just comes up blank even though the resulting pages on the front end look fine, and even though the same file visited through FTP looks fine.

        At the very least, there’s continuing discussion and progress. Is there a way to shut it off for those people, similar to Classic Editor?


Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.