WordPress 5.2 Pushed Back to May 7, RC 1 Now Available for Testing

WordPress 5.2 was originally scheduled to be released on April 30, but has now been pushed back to May 7, due to the number of open tickets last week (43). There is now only one ticket remaining on the 5.2 milestone for completion of the About page and WordPress 5.2 RC 1 is ready for testing.

The upcoming release will bring major improvements to the block editor (everything released in the Gutenberg plugin prior to version 5.4). This includes the new block management capabilities and several new blocks that were ported from core widgets.

WordPress 5.2 will introduce a new admin interface for Site Health under the Tools menu. It runs tests that deliver results categorized as critical, recommended, or good, along with action items for users to improve their settings. The Information tab was added for basic debugging and provides information about the website and server setup.

A new feature called “fatal error recovery mode” is also included in this release. It pauses themes or plugins that are causing a fatal error and puts the site into recovery mode so the user can still access the admin to troubleshoot the issue. Users should experience fewer “white screen of death” situations with this new feature in place.

WordPress 5.2 brings a host of accessibility improvements to various admin screens for users who rely on assistive technologies. It also makes it easier to customize and design WordPress’ included Privacy Policy page.

Check out the 5.2 field guide for a detailed breakdown of everything that’s coming in the upcoming release. If you want to get a sneak peak and help test the release candidate, the easiest way is to install the Beta Tester plugin and select the “bleeding edge nightlies” option.


8 responses to “WordPress 5.2 Pushed Back to May 7, RC 1 Now Available for Testing”

  1. As I commented on the “Site Health” article at wordpress.org – https://make.wordpress.org/core/2019/04/25/site-health-check-in-5-2/ – if that percentage score/graphic stays, then every site builder/plugin author/web host is going to need to brace themselves for the onslaught of site owners who believe that if they don’t score 100% then there’s a fault that needs fixing, and the resulting wasted man hours spent either applying fixes to non-problems or educating site owners in complex technicalities.

  2. Can someone please explain how an inactive plugin can be considered a security threat? I thought they cannot execute code and are perfectly safe to keep around. I will have to remove about half a dozen of those from my sites now!

  3. If deactivated plugins are marked as insecure because they might have a vulnerability then do these same plugins become more secure if I re-activate them? Nope. So why are deactivated plugins scored any differently from active ones? They have the same objective level of vulnerability. The only difference is an assumption that they are not being watched by the site admin, but does that really have any bearing on the threat level?

    There are certain dev utility plugins which I keep deactivated on client sites and only activate them when I am doing maintenance. I deactivate them just in case they are hooking in and using 1% of resources in wp-admin, or for a number of other reasons . For example: many plugins clutter the sidebar, or a client may have admin rights and I don’t want them seeing Query Monitor, or doing a search and replace!

    I’ll now have to remove those plugins and reinstall them every time I need them.


Subscribe Via Email

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

%d bloggers like this: