WordPress 5.2 is releasing on April 30, 2019, and new features and enhancements have already been shipping out. Some of the interesting features include Site Health feature, Updated PHP requirement, Fatal Error Recovery Mode, and other enhancements. One of the most promising features in WordPress 5.2 is Fatal Error Recovery Mode.
With the new version of WordPress, administrators will now be able to fix or mitigate fatal errors on their website—no more “white screen of death”. Prior to this, the task would require developer interference and modifying the codebase. Site administrators will now still have the chance to log in and check in case of any fatal error which could make the backend completely inaccessible.
It is the main benefit of recovery mode—informing admins about the fatal error and allowing them to use the backend through recovery mode.
In case of a fatal error, a user-facing error screen will display information for the visitors that the site is experiencing technical difficulties. Whereas, an email will be sent to the admin email address including information about the issue and a secret link to a new feature called the “recovery mode”. The link will lead the admin to enter the recovery mode that works by placing a cookie on the current client. Plugins and themes causing the fatal error will be paused in the recovery mode. This would ensure site admins can still work by accessing their admin backend. Shortly after logging in, an admin will be informed that the recovery mode is enabled and they will also be shown the list of plugins/themes that have been paused. Admins then have the following options to go for:
- 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 afterward, 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.
To exit the recovery mode, click on the ‘Exit Recovery Mode’ button provided at the top. It will wipe the cookie from the client and cause all extensions to run as usual again, even the paused ones. However, the fatal error will still remain, if any extension is broken or having an issue.
- 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_IDthat 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.phpdrop-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.phpdrop-in. This drop-in must return an instance of a class extending the default WP_Fatal_Error_Handler 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().
The major release is nearing and witnessing enhancements like this one, it is safe to say that 5.2 release will be an interesting and exhilarating update.