What’s New in WordPress 5.2 Release Candidate

The first Release Candidate for WordPress 5.2 is now available for beta test and final release on May 7, 2019!

This is a significant momentous as WordPress advances towards version 5.2 publication date of its first “Release Candidate” which means that the novel version is prepared for release, but with billions of operators and millions of plugins and themes, it is quite possible something may have missed out. The new WordPress 5.2 Release Candidate is planned to be released on Tuesday, May 7. But WordPress requested the help of developers or users to get there. Unless you as a WordPress user not try the new 5.2 version, it will be almost impossible to figure out the missing parts. So, if you have not tried it yet, now is the time!

How to test WordPress 5.2 Release Candidate?

There are two methods available to examination the WordPress 5.2 release candidate: Firstly, try with the WordPress Beta Tester plugin (you would want to go with the “bleeding edge nightlies” option), or secondly, you can download the release candidate here (zip file).

What’s in WordPress 5.2?

Continuing with the theme from the last release, WordPress 5.2 gives you even more robust tools for identifying and fixing configuration issues and fatal errors. Whether you are a developer helping clients or you manage your site solo, these tools can help get you the right information when you need it.

The Site Health Check and PHP Error Protection tools have brand new features, giving you peace of mind if you discover any issues with plugins or themes on your site. There are also updates to the icons available in your dashboard, fresh accessibility considerations for anyone using assistive technologies and more.

Plugin and Theme Developers

Please test your plugins and themes against WordPress 5.2 and update the Tested up to version in the readme to 5.2. If you find compatibility problems, please be sure to post to the support forums so we can figure those out before the final release.

The WordPress 5.2 Field Guide has also been published, which goes into the details of the major changes.

WordPress 5.2 Field Guide

WordPress 5.2 is officially the best WordPress 2019 has seen that rhymes with wp_nav_menu()! Users will see new core blocks available, and an added ability to enable or disable blocks within the block inserter, along with a multitude of other block editor updates.

There are also new features to protect sites from the dreaded “White Screen of Death“, a new area for users to view, copy, and share important debug information, improvements to Accessibility and theming Privacy Policy pages. Developers will love the various new filters and functions, and will also be able to take advantage of 62 enhancements and feature requests, 228 bug fixes, and more! Let’s look at the many improvements coming in 5.2…

Site Health and WSOD Protections

WordPress 5.2 includes portions of the Site Health and Servehappy projects. A new Site Health page nested under the “Tools” menu will run a series of tests on a site pointing out potential issues that site owner should be aware of. Plugins and themes may add their own tests, or modify/remove existing ones using filters. More debugging and support information is displayed within an “Info” tab in the same area of the admin. This information can help developers troubleshoot user issues.

WordPress Security Essentials

From the Servehappy project comes the addition that allows 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. This includes five ways that developers can integrate with the new recovery mode features.

Site Health Check in 5.2

WordPress 5.2 will include two new pages in the admin interface to help end users to self-service their site through common configuration issues and other elements that go along with having a healthy online presence. It also provides a standardized location for developers to add debugging information.

The new pages can be found under the Tools menu, as Site Health, and presents the user with a fresh new admin interface. As we hope users will regularly ensure their site is up to standards, focus has been put on creating an interface you want to return to in the future.

Site Health Status

 Screenshot of the WordPress Site Health Status page

The first page runs a series of tests on the user’s site, and will be categorized as critical, recommended, or good responses. These outcomes also affect the percentage of completion you have (where critical is weighted more heavily than recommended).

Each test result can be expanded to get an explanation of what you as a user should be paying attention to, and which problems are there if any, that need addressing.

Most of the bundled tests will also have actionable items, and provide links directly to the appropriate areas of your dashboard where you can improve upon the relevant settings.

Filtering the Tests

The tests are filterable via site_status_tests, meaning plugins or themes may add their own tests, or remove existing ones. We’ve also split these into two different types of tests: direct  and async. This was done as some tests may require more time to run, so to avoid potential timeouts within admin pages, any tests added to the async section will be run in succession via AJAX calls after the page is loaded.

Specifically of interest to server admins is the companion filter site_status_tests_php_modules, which is based off the WordPress Hosting Team list of recommended and required PHP extensions.

Removing a Test

An example of a filter use would be a hosting provider that does automated updates. They may wish to remove the test for background updates being enabled or disabled as follows:

function myhost_remove_update_check( $tests ) {
unset( $tests['background_updates'] );
return $tests;
add_filter( 'site_status_tests', 'myhost_remove_update_check' );

Adding a Test

This is an example of how a caching plugin might check to ensure that it’s cache setting is enabled.

function myplugin_add_caching_test( $tests ) {
$tests['direct'] = array(
'caching_plugin' => array(
'label' => __( 'My Caching Test' ),
'test' => 'myplugin_caching_test',
return $tests;
add_filter( 'site_status_tests', 'myplugin_add_caching_test' );

function myplugin_caching_test() {
$result = array(
'label' => __( 'Caching is enabled' ),
'status' => 'good',
'badge' => array(
'label' => __( 'Performance' ),
'color' => 'orange',
'description' => sprintf(
__( 'Caching can help load your site more quickly for visitors.' )
'actions' => '',
'test' => 'caching_plugin',

if ( ! myplugin_caching_is_enabled() ) {
$result['status'] = 'recommended';
$result['label'] = __( 'Caching is not enabled' );
$result['description'] = sprintf(
__( 'Caching is not currently enabled on your site. Caching can help load your site more quickly for visitors.' )
$result['actions'] .= sprintf(
'<p><a href="%s">%s</a></p>',
esc_url( admin_url( 'admin.php?page=cachingplugin&action=enable-caching' ) ),
__( 'Enable Caching' )

return $result;

myplugin_add_caching_test() is hooked to the site_status_tests filter. It adds a new test called caching_plugin to the direct tests list. The value of test in this array is the function that will be called when the tests run on the Site Health Status page.

Note: If you add a test to the async test list, then you will also need to register the test function as an AJAX action using the wp_ajax_{$action} hook.

The test function should return an array with data about the result of the test. This array includes:

  • label: What the header of the section should say.
  • status: Section the result should be displayed in. Possible values are good, recommended, or critical.
  • badge: Array containing:
    • label: What the badge should say.
    • color: Applies a CSS class with this value to the badge. Core styles support blue, green, red, orange, purple and gray.
  • description: Additional details about the results of the test.
  • actions: A link or button to allow the end user to take action on the result.
  • test: The name of the test.

In the above example, the test function, myplugin_caching_test() sets an initial baseline value for the result, and then overrides portions as needed if the call to its internal function myplugin_caching_is_enabled() returns false.

Site Health Info

Screenshot of the WordPress Site Health Information page

The Information tab is meant for debug purposes. It provides a plethora of information about the website and server setup for sharing when looking for support in various locations, alongside a button to quickly copy any non-private information so you can easily paste this to others.

The page is split up into sections. Plugins and themes may introduce their own entries to this page using the debug_information filter, either by adding entries to existing sections, or by creating their own sections.

As mentioned, the copied information only includes non-private information, this can of course be subjective, and is therefore also included in the filter. Marking either a full section, or just individual entries as private can be done by setting the corresponding $private value to true.

For example, the database prefix is shown under the Database section, and is marked as private, so when I go to copy all the information, it’s not there:

Example of the database section of the Site Health Information page

The content that gets added to the clipboard for the entire Database section is shown below:

### Database ###

Extension: mysqli
Server version: 5.5.5-10.1.38-MariaDB-1~jessie
Client version: mysqlnd 5.0.12-dev - 20150407 - $Id: 7cc7cc96e675f6d72e5cf0f267f48e167c2abb23 $

A security plugin may for example think that any database information is always seen as private, and would filter this in the following way:

function secplugin_remove_database_info( $debug_info ) {
$debug_info['wp-database']['private'] = true;
return $debug_info;
add_filter( 'debug_information', 'secplugin_remove_database_info' );

Adding a new section may also be of interest. The example below adds your own plugin and its license key, but marks it as private, to the list:

function myplugin_add_debug_info( $debug_info ) {
$debug_info['my-plugin-slug'] = array(
'label' => __( 'My Plugin', 'my-plugin-slug' ),
'fields' => array(
'license' => array(
'label' => __( 'License', 'my-plugin-slug' ),
'value' => get_option( 'my-plugin-license', __( 'No license found', 'my-plugin-slug' ) ),
'private' => true,

return $debug_info;
add_filter( 'debug_information', 'myplugin_add_debug_info' );

Each new section that’s added should use your plugin or theme slug to avoid name collisions. All core entries are prefixed with wp-.

All debug information is added in an unescaped manner, the Information page will run all data through wp_kses, and only allows a, strong, em and span tags (used for emphasis or linking to documentation).
Debug information is expected to be plain text, and is escaped before showing on the page. The displayed data is ran through esc_html(), and data that can be copied is ran through esc_attr().

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.


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().

Block Editor

The block editor has continued its rapid iteration since WordPress 5.0, and now has Gutenberg version 5.4 bundled with WordPress 5.2. The most significant change in core is the addition of a a reusable block-editor module to expand the usage of the Block Editor in a context independent from the post editor without any dependency to the post object (e.g., to other WordPress admin pages like the widgets screen).

A new asynchronous mode for block rendering has also been added, new RSS and Amazon Kindle embed blocks were added, and a block management modal with the ability to enable/disable blocks from the block inserter. Improvements to the end-to-end tests have been made (including support for aXe Accessibility testing), as well as improvements to the accuracy of WP_Screen::is_block_editor(). Core blocks (aside from the Classic block) are also no longer using TinyMCE under the hood.

The Block Editor JavaScript module in 5.2

One of the goals of the Gutenberg project’s phase 2 is to expand the usage of the Block Editor to other WordPress admin pages like the widgets screen.

In order to achieve this goal, it’s important to be able to reuse the block editor in a context independent from the post editor without any dependency to the post object. That’s where the new block-editor module comes in.


In WordPress 5.1 and earlier, the block editor relied on the editor JavaScript module in order to fetch the post being edited and render the block editor corresponding to this post. This module is available as a registered WordPress script using the wp-editor script and style handles and under the wp.editor global variable.

WordPress 5.2 extracts some parts of the editor module into a new module called block-editor. This module is now available as a registered WordPress script using the wp-block-editor script and style handles and under the wp.blockEditor global variable.

Important distinctions about the new block-editor module:

  • The editor module is kept, but is only responsible for fetching/updating post objects, and rendering post specific UI components.
  • The block editor module is a generic module responsible for rendering block editor UI, updating the list of blocks, and providing reusable components for third-party blocks.

Backward Compatibility

There’s no backward compatibility breakage involved in this reorganization, as usage of the editor module provides proxies for APIs that were moved to the block-editor module in WordPress 5.2.

For example, in WordPress 5.1, blocks had to use the wp.editor.BlockAlignment component to support alignment. This component will continue to work as expected, but wp.editor.BlockAlignmentToolbar is now just a proxy to the block editor component wp.blockEditor.BlockAlignmentToolbar.

However, relying on the editor module as a dependency means that your block/code is loading the full editor module, which might not be needed for the block editor that will be included in the widgets screen in the future.

For this reason, it’s recommended that you make your blocks independent from the editor module and any post object. Instead of relying on the editor module proxies, you are encouraged you to your code to target the block-editor APIs instead.

This involves:

  • Using wp-block-editor instead of wp-editor as script and style dependencies for your WordPress registered/enqueued scripts and styles.
  • Using the wp.blockEditor.* components instead of wp.editor.* ones.
  • Using the core/block-editor data module selectors and actions instead of the core/editorones.

Components and Higher-Order Components Moved to block-editor

This is the exhaustive list of the components and higher-order components that were moved to the block-editor module.

  • Autocomplete
  • AlignmentToolbar
  • BlockAlignmentToolbar
  • BlockControls
  • BlockEdit
  • BlockEditorKeyboardShortcuts
  • BlockFormatControls
  • BlockIcon
  • BlockInspector
  • BlockList
  • BlockMover
  • BlockNavigationDropdown
  • BlockSelectionClearer
  • BlockSettingsMenu
  • BlockTitle
  • BlockToolbar
  • ColorPalette
  • ContrastChecker
  • CopyHandler
  • createCustomColorsHOC
  • DefaultBlockAppender
  • FontSizePicker
  • getColorClassName
  • getColorObjectByAttributeValues
  • getColorObjectByColorValue
  • getFontSize
  • getFontSizeClass
  • Inserter
  • InnerBlocks
  • InspectorAdvancedControls
  • InspectorControls
  • PanelColorSettings
  • PlainText
  • RichText
  • RichTextShortcut
  • RichTextToolbarButton
  • RichTextInserterItem
  • UnstableRichTextInputEvent
  • MediaPlaceholder
  • MediaUpload
  • MediaUploadCheck
  • MultiBlocksSwitcher
  • MultiSelectScrollIntoView
  • NavigableToolbar
  • ObserveTyping
  • PreserveScrollInReorder
  • SkipToSelectedBlock
  • URLInput
  • URLInputButton
  • URLPopover
  • Warning
  • WritingFlow
  • withColorContext
  • withColors
  • withFontSizes

Selectors Moved to block-editor

This is the exhaustive list of the data module selectors that moved to the core/block-editorstore.

  • canInsertBlockType
  • getAdjacentBlockClientId
  • getBlock
  • getBlockAttributes
  • getBlockCount
  • getBlockDependantsCacheBust
  • getBlockHierarchyRootClientId
  • getBlockIndex
  • getBlockMode
  • getBlockName
  • getBlockOrder
  • getBlockRootClientId
  • getBlockInsertionPoint
  • getBlockListSettings
  • getBlocks
  • getBlocksByClientId
  • getBlockSelectionStart
  • getBlockSelectionEnd
  • getClientIdsOfDescendants
  • getClientIdsWithDescendants
  • getFirstMultiSelectedBlockClientId
  • getGlobalBlockCount
  • getInserterItems
  • getLastMultiSelectedBlockClientId
  • getMultiSelectedBlockClientIds
  • getMultiSelectedBlocks
  • getMultiSelectedBlocksEndClientId
  • getMultiSelectedBlocksStartClientId
  • getNextBlockClientId
  • getPreviousBlockClientId
  • getSelectedBlockCount
  • getSelectedBlockClientId
  • getSelectedBlock
  • getSelectedBlocksInitialCaretPosition
  • getTemplate
  • getTemplateLock
  • hasInserterItems
  • hasMultiSelection
  • hasSelectedBlock
  • hasSelectedInnerBlock
  • isAncestorMultiSelected
  • isBlockInsertionPointVisible
  • isBlockMultiSelected
  • isBlockSelected
  • isBlockValid
  • isBlockWithinSelection
  • isCaretWithinFormattedText
  • isFirstMultiSelectedBlock
  • isMultiSelecting
  • isSelectionEnabled
  • isTyping
  • isValidTemplate

Actions Moved to block-editor

This is the exhaustive list of the data module actions that moved to the core/block-editorstore.

  • clearSelectedBlock
  • enterFormattedText
  • exitFormattedText
  • hideInsertionPoint
  • insertBlock
  • insertBlocks
  • insertDefaultBlock
  • mergeBlocks
  • moveBlocksDown
  • moveBlocksUp
  • moveBlockToPosition
  • multiSelect
  • receiveBlocks
  • removeBlock
  • removeBlocks
  • replaceBlocks
  • resetBlocks
  • selectBlock
  • setTemplateValidity
  • showInsertionPoint
  • startMultiSelect
  • startTyping
  • stopMultiSelect
  • stopTyping
  • synchronizeTemplate
  • toggleBlockMode
  • toggleSelection
  • updateBlock
  • updateBlockAttributes
  • updateBlockListSettings

Styles and Class Names

The components that moved from the editor module to the block-editor module are internally using CSS class names that follow the package they’re declared in.

For example, the editor-inserter__toggle class name is now renamed block-editor-inserter__toggle.

The old class names have been retained to minimize any backward compatibility concern, but the CSS styles are now targeting the new class names.

Ideally, you should rely on components in your own code instead of the internal class names used in the WordPress admin. But if you do use those classes, make sure to rename them accordingly.

Author: Aliva Tripathy

Taking out time from a housewife life and contributing to AxiBook is a passion for me. I love doing this and gets mind filled with huge satisfaction with thoughtful feedbacks from you all. Do love caring for others and love sharing knowledge more than this.

Leave a Reply