Month: December 2018

After pushing back the release date of WordPress 5 from 27^th November to an unannounced date, the new release date has, early hours of today, been announced as Thursday 6^th December 2018.

This is a very soon date which gives people little time to plan.

From feedback on the announcement page, it appears the majority think the date is driven by the WordCamp US conference. An event should never be the driver for software release; the driver should be that the software is ready and Gutenberg appears not to be ready.

You can edit your wp-config file to prevent an upgrade (if you host your own site) or can install the Classic Editor to get the old functionality back.

Upgrading to Gutenberg is not necessarily a choice that users of WordPress will make for themselves. If you’re hosted on WordPress.com or deployed your site via a web host, you will have little to zero say about when you upgrade.

Your existing posts will be editable via Gutenberg, and will show with the entire post in a single block; be very cautious about allowing Gutenberg to migrate them to blocks, as in my testing I have found this usually corrupts the post (this may be due to how I’ve created my posts, but the conversion appears to hate any styling.

You can revert to the standard experience, by installing the Classic Editor, but any migrated posts will remain changed. The Classic Editor will remain available via a plugin, but it has already been announced that it will only be supported until 31^stDecember 2021. After this the Classic Editor will no longer be supported.

In the last post, I mentioned blocks a fair bit, but maybe didn’t explain blocks well enough. WordPress has an FAQ which describes blocks:

What are “blocks” and why are we using them?
The current WordPress editor is an open text window–it’s always been a wonderful blank canvas for writing, but when it comes to building posts and pages with images, multimedia, embedded content from social media, polls, and other elements, it required a mix of different approaches that were not always intuitive:

• Media library/HTML for images, multimedia and approved files.
• Pasted links for embeds.
• Shortcodes for specialized assets from plugins.
• Featured images for the image at the top of a post or page.
• Excerpts for subheadings.
• Widgets for content on the side of a page.
• As we thought about these uses and how to make them obvious and consistent, we began to embrace the concept of “blocks.” All of the above items could be blocks: easy to search and understand, and easy to dynamically shift around the page. The block concept is very powerful, and if designed thoughtfully, can offer an outstanding editing and publishing experience.

Basically, every section of a post is a block; headings, paragraphs, images, lists, galleries are all separate blocks. WordPress also recommend that all meta field and shortcodes are upgraded to blocks (this last is more one for plugin developers).

Unfortunately, blocks, unlike current standard plugins, are not created with PHP, but Javascript and a framework such as React JS (which Gutenberg itself uses).

This massively decreases the accessibility of creating extensions for WordPress as PHP is easier to learn than Javascript. Whether you think this is a good or bad thing depends on your view of the world. People often deride PHP, but it has meant a proliferation of plugins available so almost any requirements you might have can be met by an existing plugin. Unfortunately, not all of these plugins are high quality, so some care must be taken with the plugins used.

The bar has been raised for accessibility in that Javascript is harder to learn than PHP, so some of the poorer developers may drop out, but it also means that the slightly better developers will be writing bad Javascript blocks, so the overall quality may not change at all.

What you’re likely to have is less plugins providing blocks.