As a custom theme developer, with hundreds of sites under my belt, the prospect of “all change” when Gutenberg comes into existence is scary.
As I will be the first port of call for the many sites I have built over the years, it is vital that I quickly got up to speed with what Gutenbery is and will do, but most importantly, what it will do to all the lovely custom sites I have already built, and even more importantly what I can do to prevent and fix problems
Gutenberg has three planned stages. The first, aimed for inclusion in WordPress 5.0, focuses on the post editing experience and the implementation of blocks. This initial phase focuses on a content-first approach. The use of blocks, as detailed above, allows you to focus on how your content will look without the distraction of other configuration options. This ultimately will help all users present their content in a way that is engaging, direct, and visual.
These foundational elements will pave the way for stages two and three, planned for the next year, to go beyond the post into page templates and ultimately, full site customization.
Gutenberg is a big change, and there will be ways to ensure that existing functionality (like shortcodes and meta-boxes) continue to work while allowing developers the time and paths to transition effectively. Ultimately, it will open new opportunities for plugin and theme developers to better serve users through a more engaging and visual experience that takes advantage of a toolset supported by Core.
The Gutenberg project is actively addressing compatibility concerns. Blocks are the de facto new mechanism for building content features, and it is recommended that developers migrate any features they offer that are well-encapsulated by blocks. However, support for existing WordPress functionality will remain, and there will be transition paths for shortcodes, meta-boxes, and Custom Post Types:
- Will continue working without changes.
- There is a new “shortcode block” to help inserting them.
- There’s a planned mechanism for previewing them in place.
- * Certain meta-boxes that rely on the specific structure of the current editing screen are not guaranteed to work under Gutenberg, and might need changes before they can be loaded correctly. – Waiting to find out which Metaboxs
- Some will continue to work with no changes under the new UI.
- Some will need updates (particularly those that rely on the DOM for operating).*
- Several can be converted to native blocks (particularly those that are rendered on the front-end).
- Some can transition to new Gutenberg native extension points outside of the content area.
- There will be a mechanism for conflicting meta-boxes to load the classic editor instead with a notice.
Custom Post Types.
- Are supported by Gutenberg.
- Need REST API (show_in_rest) declaration.
- Can opt out by not declaring “editor” support.
- Will be able to declare supported and default blocks.
So.. if you theme or plugin is using Custom Posts, and metaboxes.. steps can be taken to “Gutenberg-proof” your site now – Why wait for the site to break and scramble around paying mega premium support rates?