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.

Would you like to write for WP Tavern? We are always accepting guest posts from the community and are looking for new contributors. Get in touch with us and let's discuss your ideas.

8 Comments


  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.

    Report


  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!

    Report


    1. You should remove all unused plugins and themes for two reasons.

      1. Even if they are deactivated in wp-admin, the code is still directly accessible on your server. Here’s an example of an exploit that works even when the plugin is deactivated.

      https://technicalagain.com/2019/04/14/conwell-quotes-wordpress-plugin-with-a-backdoor/

      2. The themes and plugins may fall out of date if inactive and you stop updating them. The more they age, the more likely exploits will become known and published. WordPress has a very active community of security researchers and hackers that make exploits very easy to scan for and execute.

      Bottom line is deactivate and delete anything that is unneeded. Update as soon as practicable.

      Report


    2. Inactive plugins can still run code if you access them directly and they do not have any checks preventing this built in.

      They are also less likely to be updated, think “I’m not using it, so it doesn’t need to be updated”.

      Report


    3. when it’s inactive that just means that its hooks are not scanned and applied in the system. that is really all that it means, if i’m not mistaken.

      Report


  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.

    Report

Comments are closed.