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.

Category: News, WordPress

Tags: WordPress 5.2

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

David Anderson says:

April 26, 2019 at 10:02 AM

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.

Create forum topic from comment

Loading…
- titi says:
  
  April 26, 2019 at 12:49 PM
  
  join the discussion here :
  
  https://core.trac.wordpress.org/ticket/47046
  
  Click to Edit –
  
  join the discussion here :</p> <p><a href="https://core.trac.wordpress.org/ticket/47046" rel="nofollow ugc">https://core.trac.wordpress.org/ticket/47046</a></p> <p>
  
  Create forum topic from comment
  
  Loading…
Ashutosh Mishra says:

April 26, 2019 at 11:17 AM

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!

Create forum topic from comment

Loading…
- toto says:
  
  April 26, 2019 at 11:46 AM
  
  your plugin code could become a back door even if not activated :
  
  https://example.com/wp-content/plugins/inactiveplugin/somecode.php
  
  Create forum topic from comment
  
  Loading…
- Kyle Pott says:
  
  April 26, 2019 at 9:59 PM
  
  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.
  
  Create forum topic from comment
  
  Loading…
- Clorith says:
  
  April 28, 2019 at 10:19 AM
  
  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”.
  
  Create forum topic from comment
  
  Loading…
- Dan Feidt (hongpong) says:
  
  April 29, 2019 at 5:02 PM
  
  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.
  
  Create forum topic from comment
  
  Loading…
Steve Pheriche says:

April 27, 2019 at 10:20 AM

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.

Create forum topic from comment

Loading…