Well today marks 1 week since the release of WordPress 5 – one of the best known Content Management Systems on the market; and what better way to celebrate than with an update to version 5.0.1! 

It’s pretty common that shortly after a major release of this scale a further release comes out, which leads many people to leap to the advice “Don’t upgrade yet”. That’s all well and good – but when should we upgrade then? Well we have spent this past week playing around with WordPress 5 to ensure that when we are ready to move all of our clients to WordPress 5 we are ready – and our thoughts so far? Pretty impressed!

The key difference is one which your clients will notice, the old text editor is gone, replaced by the incredibly sleek and up to date Gutenberg. This has been an option in previous versions of WordPress – but given it has been there as an advanced preview, it’s been a wise choice to steer clear. The good news is that for the time being with WordPress 5, you can do the inverse and continue using the classical editor if you like – in fact further to this you will be prompted to install the classical editor when you complete the upgrade! I wouldn’t bet on this hanging around forever though, the upgrade to Gutenberg is marking a huge step forward for WordPress and is something we should handle as soon as we can – keeping in mind we’ve all got our work cut out making sure the updates go smoothly across all sites. 

So how does the upgrade work? You will be pleased to hear we found it rather smooth on all the sites we tested on. Of course it’s worth mentioning that we don’t use a great deal of plugins where we can avoid it, so the ease of having an understanding of the plugin code would probably somewhat help here in case you did find any non-compatible plugins. The entire process worked it’s magic and we were getting through a number of duplicate sites in our sandbox environment without any trouble… But then of course we hit a snag. Of course WordPress is known for its versatility and its ability to be modified to fit just about any scenario – frequently far away from its initial “intended purpose” as a blogging website. So what happened in our case? Well believe it or not the upgrade was smooth, the site continued to operate completely as before. But when I say completely as before, I mean completely. The only visible change in the CMS was that it said it was running WordPress 5… But when we tried to edit the posts, we still saw the classic editor! Baffled by this we tried the normal “Oh this hasn’t properly upgraded” procedures of logging out and logging back in, re-running the installation. And so on until eventually we had to accept that we had upgraded to WordPress 5, and just for some reason kept seeing the Classic Editor! Eventually, we got to the bottom of it – Gutenberg had been installed and indeed was the default editor, however as I had mentioned, the classic editor is still an option in WordPress 5 – our clients installation of WordPress contained custom posts only. We had removed the standard “Posts” and “Pages” from WordPress all together, as we needed to specify how both the Front and Back end worked. But even with Custom Posts, we should have had access to Gutenberg right? Well you can, but not always. When we created the Custom Posts, we weren’t thinking about possible interactions with any REST API or anything along those lines, when it isn’t something you will need you often tend not to think about it, so in creating these Custom Post Types, we had left the “show_in_rest” setting to default itself to false. This is something we must remember not to do in the future, as Gutenberg accesses the posts via the REST API. Prohibiting access to REST prohibits Gutenberg from being able to access the post, and therefore requires you to go back to the classic editor. Now as I mentioned earlier, this client has a very specific set of requirements for their items, so this isn’t a huge issue – the posts themselves actually contain no content, just a range of metadata through custom meta-boxes, but it does make us wonder how WordPress will handle such a situation should they remove the classic editor from WordPress all together – or will this remain much like the outdated jQuery library to ensure compatibility?

For those wondering, the minimum requirements for Gutenberg to function on a Custom Post type are that show_in_rest must be set to true, and if you want to defines what your custom post type supports you must include “title” and “editor” as a minimum. 

But what is the verdict on Gutenberg – the key change to WordPress 5. Indeed it’s cheeky to brush over WordPress 5 as if it is uniquely Gutenberg that changes things – but this is the largest change and the most noticeable. For a long time we have been using plugins to allow for a simplistic drag and drop style widget for our customers – finally thanks to Gutenberg and it’s “Blocks” feature, we no longer need to use Plugin’s to add the features missing for a specific clients website – finally we can extend WordPress itself to include the widgets we need! The jury is still out on the use of JavaScript to write these plugins rather than using a PHP function – the fact that this is directly built in to WordPress and unlikely to be “upgraded” overnight in a manner which breaks all our existing plugins is a huge win for us! It will make our development more stream lined, and make the end user experience much simpler. We still have a little bit to get our head around – but the future with Gutenberg is exciting. It’s a yes from us!