1. WordPress 5.3.1 Security and Maintenance Release

WordPress 5.3.1 Security and Maintenance Release

WordPress 5.3.1 was released on 13 December 2019.

WordPress 5.3.1 is a security release which addresses four security issues.

As with any security release – it’s important that you update immediately.

What does it fix?

Security issues fixed in the WordPress 5.3.1:

  • a bug where an unprivileged user could make a post sticky via the REST API
  • a bug where cross-site scripting (XSS) could be stored in well-crafted links
  • a XSS vulnerability using Gutenberg block edito
  • hardening wp_kses_bad_protocol() to ensure that it is aware of the named colon attribute

There were also 48 maintenance updates covering the block editor, Twenty Twenty bundled theme, accessibility, Admin CSS, internationalization, media library and date/time handling.

How to install update?

As a minor release, by default, the update will install automatically.

If this has been disabled you will need to install by logging into your WordPress administration console and go to the Dashboard -> Updates page.

WordPress 5.3 “Kirk” Release

WordPress 5.3 was released on 12 November 2019.

5.3 is a major release that includes 386 bug fixes and 151 enhancements.

Code named “Kirk” in honour of jazz musician Rahsaan Roland Kirk.

It brings significant new features:

  • improved wp-admin accessibility
  • 150 Gutenberg editor enhancements
  • automatic image rotation (plus more!)
  • improved Site Health
  • administration email verification
  • improved PHP 7.4 support
  • improved timezone date and time functionality

Improved wp-admin accessibility

52 accessibility updates were made in WordPress 5.3.

The most noticeable are changes to:

  • color contrasts on form fields and buttons
  • focus styles on form fields and buttons
  • content behavior on text zoom

150 Gutenberg editor enhancements

Updates to the new “Gutenberg” block editor continue with WordPress 5.3 – with a massive 150 enhancements introduced.

Updates were focused on usability, accessibility and image handling.

For more information see Block Editor Theme-related updates in WordPress 5.3.

Automatic image rotation (plus more!)

WordPress will now attempt to automatically rotate images using image orientation EXIF meta-data.

How uploaded images are handled by WordPress was also changed to decrease server load and avoid critical errors which would previously fail multiple images being uploaded when only one failed.

For more information see Updates to Image Processing in WordPress 5.3.

Improved Site Health

31 updates were made to the Site Health feature – which informs WordPress administrators of performance and security issues for the install – with a focus on server health such as PHP version.

Most notable is the change to the health grading – which was a percentage. There were concerns that the percentage indicator was misleading.

The health grading now shows one of two statuses – needs improvement and good.

And the WSOD emails can now include basic debug information – with a filter for plugin and theme developers to add their own logs.

For more information see What’s new in Site Health for WordPress 5.3.

Administration email verification

Administrators will now periodically be prompted to confirm their email is still valid. Which will reduce the risk of loosing access to a WordPress site through not knowing the administrator login details.

This prompt appears when administrators log in to wp-admin.

Improved PHP 7.4 support

WordPress 5.3 included 5 updates addressing PHP 7.4 support.

This involved depreciating functions which are no longer supported in PHP 7.4.

As a consequence – the native PHP JSON extension is now required to run WordPress.

Improved timezone date and time functionality

Now that the minimum supported PHP version has raised – timezone date and time handling can be moderized to improve this basic, but important, functionality.

The wp_date() function has been introduced which provides a completely new way to handle date localisation.

For more information see Date/Time component improvements in WordPress 5.3.

How to install the update?

As a major release 5.3 will need to be installed manually.

You will need to install by logging into your WordPress administration console and go to the Dashboard -> Updates page.

As always, backing up the site before installing updates is highly recommended.

WYSINWYG – What You See Is NOT What You Get

Online content is often written in WYSIWYG editors – these are known as “What You See Is What You Get” because you can easily format the text to control the output on the website.

The only issue is it’s NOT what you get – the editors are isolated in their own interface, separate from the website design, complicated layouts are difficult and you have to preview the content to finally see it in place.

This is why I feel Gutenberg, the new editor released in WordPress 5.0, is the future WordPress needed.

Gutenberg moves away from the idea of content being a single component – to “blocks” which can be freely added, reordered and layout finely controlled. It opens up a world of possibilities beyond the basic features offered by the previous TinyMCE editor.

Sure there are numerous third-party “page builder” plugins that help achieve this – but without being a core part of the platform compatibility issues will always exist. You might be able to create a pretty page – but what if you want to move the content to another website or the page builder is no longer supported? You’re left with a mess of shortcodes and content which only that plugin understands.

Gutenberg becoming a native frontend editor will be a massive step forward for the estimated 75 million websites managing online content.

WordPress 5.0 is amazing – but for all the wrong reasons

WordPress 5.0 is out – bringing with it the much anticipated Gutenberg editor experience.

Gutenberg changes the way content is created in WordPress. It’s a break away from the TinyMCE editor which has been used for years and introduces a whole new custom built editor.

While I’m not a fan of Gutenberg – what I find amazing is how the update has been managed.

The push to release

The timeline for WordPress 5.0 was doomed as soon as Gutenberg planned as part of the release.

It was first announced for an August 2018 release

WordPress 5.0 could be as soon as August with hundreds of thousands of sites using Gutenberg before release.

This came and gone with more than a thousand unresolved bugs.

Then 19 November 2018 – much to the ire of the community as it collided with Thanksgiving in the US.

This was also cancelled, changing it to 27 November 2018. But it wasn’t until as late as the 23 November 2018 that we saw the first release candidate – leaving too little time for it to be fully tested.

Five Beta and three RC (Release Candidate) releases later WordPress 5.0 was released on 6 December 2018.

This constant push for release seemed to only align with the WordCamp US 2018. Or perhaps the developers were frustrated with a project that would never end. But with an estimated 75 million WordPress installs the users and community deserve a release that is ready.

Released with known bugs

On the day of release Gutenberg had 1,435 open issue tickets on Github, including 286 known bugs.

The bugs included all sorts of bad behaviour such as:

These aren’t edge cases – these are real world scenarios in a real world WordPress release.

Not only do they put websites and content at risk, but also the reputation of WordPress as a reliable platform.

Accessibility last

I’m a big advocate for accessibility, and feel that for it to be properly achieved it needs to be considered from day one.

Gutenberg, however, is plagued with accessibility issues.

It even led to the WordPress Accessibility Team Lead quitting. Rian explains the up-hill battle experienced trying to keep up with the Gutenberg developers and inability to get enough support for working on accessibility issues.

TinyMCE was not the most accessible editor, but Gutenberg was a massive step backwards with issues such as:

Thankfully a full accessibility audit has been promised – but releasing with known accessibility for such a critical part of WordPress is not OK in my book.

Automattic will be funding an accessibility study of WordPress, Gutenberg, and an evaluation of best practices across the web, to ensure WordPress is fully accessible and setting new standards for the web overall.


WordPress Gutenberg – what happens when developers go wild

Since early 2017 WordPress developers have been working on a new content editor for WordPress – code name  “Gutenberg”.

The intent is to replace the current content editor, TinyMCE, but for the meanwhile Gutenberg is a plugin in it’s beta development phase.

Gutenberg is attempting to completely reinvent how editors interact with content – most significantly:

  1. separating the parts of content into “blocks” – for example, paragraphs, lists and images will all be separate blocks. A concept that has remained in desktop word processors, such as Microsoft Word, since their invention
  2. providing a minimalist interface which only provides buttons contextually when they can be used.

The good

I  can understand the desire to be innovative and provide improvements – in fact, I  applaud it.

The current editor, TinyMCE, was introduced to WordPress in version 2.0 in 26 December 2005.

Since then it’s seen several updates but has remained a traditional WYSIWYG content editor – one large block for all content, buttons at the top, ‘visual’ and ‘code’ mode etc.

During the same time other areas of WordPress have changed significantly – leaving the perception that the content editing experience also needs a revamp.

I’m not convinced that a revamp of this scale is necessary – specifically separating content into to blocks. 

But to be fair I do see one benefit – it will pave the way for developers to provide “block plugins”, much like WordPress widgets but for content. For example, you could create a button or an AdSense unit exactly where you want in the content with a few clicks of the mouse.

The bad

Change can be good – but it needs to be tested and refined based on feedback.

I’m concerned that Gutenberg went too far before user testing and now even after user testing is revealing its faults the ship has already sail.

Developers tend to have a “build to improve” mindset – an unwillingness, or inability to accept some features are not good and will focus on building on the feature when sometimes you just need to accept that some faults are not fixable, or at least not with code.

Just take a look at the Gutenberg reviews – at the time of writing there are 38 1 star reviews, compared to 15 5 star reviews.

Will the developers listen to this feedback?  Will they refocus on the usability and functionality shortfalls?  Or will they just focus on the technical implementation?

The ugly

The truth is – the Gutenberg plugin leaves a lot of room for improvement.

By removing all the traditional editor buttons and trying to make a minimalist design the usefulness and ease of use has been drastically reduced.

Extra clicks

Using Gutenberg I found myself to click, hover and look for the buttons – instead of them being visible and available immediately.

I accept that once you learn a new user interface you things get quicker – but even after learning how to change a heading to a list it still took 8 seconds in Gutenberg, compared to 2 seconds in TinyMCE.


Failing to recognise vastly different WordPress uses

I feel like it fails to recognise the vastly different ways WordPress is being used to manage the different types and formatting of content.

For example, I manage a how-to blog. Listed items (UL or UL) and pictures are fundamental to providing how-to-instructions. But with Gutenberg even this very basic requirement is not possible – to add an image you need to end the list, insert the image then start a new list – returning the list back to 1.

Clunky reformatting

In content creation I often reformat text, for example changing listed items to headings or switching an H2 to an H3 to create a better structure. Gutenberg did not handle this well at all. Turning a list to headings created some hideous heading block with <br>’s (not that I can check due to the lack of a “Source” option).

Learning curve

The platform may be web/browser – but the end users are used to desktop word processors and will be expecting a similar user experience when trying to use HTML WYSIWYG editors.

If the usability testing has said anything – it’s that there will be a lot of end user support and hand holding to train non-technical users in how to steer it. Not something I’m particularly keen to spend time on.

For example, select-all – this should select EVERYTHING in the document — not just the current content block.

No source view

For the more HTML literate users – the lack of a “Source” option to view and manually change the HTML will be significant. If you’ve ever needed to paste content in HTML format into a post, add custom formatting, edit/clean HTML – you’ll be at a complete loss with Gutenberg.

Third-party TinyMCE

Some people have argued that there will always be third-party plugins to re-introduce TinyMCE.

But I don’t think this is enough – the content editor needs to be a consistent user experience for ALL WordPress users and MUST have core support.


I acknowledge that Gutenberg is still in beta, and that the developers have put a lot of work into getting it to where it is now.

But I find it hard to see the Gutenberg editor providing an easier experience for any content management scenario I’ve dealt with.

I feel like they’re trying to solve a problem that just doesn’t exist, not at least for the majority of users. To me it seems like there are enough solutions like TinyMCE and CKEditor to not justify recreating an entirely new editor and new editor experience.