WordPress 5.2 is officially here and there were quite a few impressive changes made to our favorite CMS. This release is named “Jaco”, not after the popular destination in Costa Rica, but after famed jazz bassist Jaco Pastorius.
The big news in this release are some of the new security features, however, there are all sorts of new bells and whistles running under the hood. Let’s take a look at a few of the key updates.
Keeping Sites Safer
It would seem the biggest focus that the WordPress core team had for this version of WordPress was to improve core security. The new version includes a number of robust tools that can be used to identify and fix configuration issues, site health issues and fatal errors in your WordPress installation. Here are a few of the key tools
WordPress Site Health Check
The new Site Health Check tool improves on the Site Health features that were first released in WordPress version 5.1. This feature performs a variety of tasks including configuration debugging, protecting against supply chain attacks, and checking plugins for incompatibilities at the time of installation.
WordPress 5.2 now includes features like PHP Error protection in the Site Health Check tool. This tool will allow for website owners, WordPress developers, and website administrators to more easily debug website errors without dealing with the “white screen of death”.
The Site Health Check also looks at a variety of common security configurations like whether or not your site is running HTTPS, whether you have any themes or plugins that require updates if you are running an appropriate version of PHP and much more.
The WordPress community has been asking for quite some time to beef up the security features and it looks like WordPress and Automattic are definitely listening.
PHP Fatal Error Recovery
Most WordPress website owners and WordPress website developers have dealt with the dreaded “white screen of death” at one point or another. This is caused by a fatal PHP error, or (usually) a “500 error”.
These situations are usually caused by upgrading plugins, adding new plugins, or including untested code in your production website. Usually the best bet is to just disable or remove the offending plugin or code, however, sometimes this can be a complex process.
As a web developer, my first move would be to check the error logs for the code throwing the error. Most of the time, the issue is fairly easy to backtrace and resolve, however from the time it can take a little digging or there’s some data that is corrupted.
For the novice website designer or website owner however, this situation could be catastrophic.
The new PHP error protection features allow for an admin to enter into an “error recovery mode”. Normally, once you get the “white screen of death”, you are no longer able to access the WordPress dashboard. In the new error recovery mode, you can log in and pause the plugins or themes that are throwing the errors so that you can log back in and restore your website.
Enter WordPress Recovery Mode
When you enter into recovery mode, plugins and themes that are causing a fatal error are paused. This ensures that the admin can work around the errors and access the WordPress 5.2 dashboard.
Once you log in to the WordPress dashboard, you should see a notice showing that recovery mode is enabled. The notification should also tell you which plugins or themes are throwing the errors and being paused. It will also give you information as to what exactly the errors are.
Now, instead of sitting on their hands waiting for a developer to fix the site, WordPress admin’s can deactivate the extension and restore the site back to working order before it can have any major impact.
The admin can exit recovery mode by clicking the exit button in the admin navigation bar. Keep in mind that if an extension is broken and you then disable it in Error Recovery Mode, this does not mean the extension is fixed. This simply means that the code is no longer running on your site. If the extension that you disabled was crucial to the functionality of your site, it’s important that you reach out to your developer right away.
WordPress 5.2 Security Updates
WordPress is often given a bad rep for being “insecure”. While it’s true it hasn’t been the most secure CMS historically, it’s also the most popular CMS in the world making it a huge target.
One of the recent updates addresses a security concern caused by the automatic update feature – supply chain attacks. Several versions of WordPress back, an auto-update feature was introduced that was intended to improve security.
Unfortunately, it had the opposite result.
This new update made WordPress websites vulnerable to what is known as a supply chain attack. In short, a supply chain attack would involve the WordPress update server being hacked, ultimately resulting in tens of millions of websites being infected with malware (if not more).
WordPress Offline Digital Signatures
WordPress 5.2 now includes offline digital signatures. Without getting too technical, this means that a hacker would not only have to hack the WordPress update server, but they’d also have to steal the core signing key from the WordPress development team.
While this isn’t necessarily impossible, it’s highly improbable that this would occur, and a major step forward in improving WordPress website security.
A New Cryptographic Library
The verification of the digital signature will be handled by the WordPress installation. This verification will be handled through a newly implemented cryptographic library called Sodium Compat .
Sodium Compat is “a pure PHP polyfill for the Sodium cryptography library.” As a comparison, Sodium Compat has been adopted by other popular content management systems like Magento and Joomla!
The best part of the upgrade is that developers can begin to migrate away from Mcrypt. This is a great thing as Mcrypt was deprecated and removed in PHP 7.
Setting up a new environment is fairly straightforward. First, you will want to make sure you have Node installed, and then run:
‘npm install --save-dev @wordpress/scripts’
Once you’ve installed the WordPress scripts package, you can now update the package.json file found in the root with:
"start": "wp-scripts start",
"build": "wp-scripts build"
Unlike other frameworks, WordPress will handle the rest of the heavy lifting for you. You won’t need to configure any additional Webpack files or Babelrc files to get everything running.
The build system expects to find the main JS file at ‘src/index.js’, however, you can import whatever JS you’d like to into this file to keep your code scalable. The compiler will then output the build to ‘build/index.js’.
To get started you will first want to install Node. You can find instructions on how to do that here.
Next, you can run the following commands:
- ‘npm install’ to install all of the package dependencies
- ‘npm build’ is what you will run once you’re finished, create a final build version using
Privacy Updates in WordPress 5.2
- A new function, ‘is_privacy_policy()’
This function can be used to test whether the user is on the Privacy Page or not. It can be used for things like triggering conditional messages, additional cookie tracking and more.
- ‘Privacy.php’ Theme File
- ‘.privacy-policy’ Body Class
- ‘.menu-item-privacy-policy’ Class
For more information on the WordPress 5.2 update and a deeper dive into all of its great new features check out the WordPress 5.2 field guide.
You can also watch our video walkthrough of some of the new WordPress 5.2 features below
If you’d like to find out more about updating your WordPress website to WordPress 5.2 schedule a strategy session with us today!