Gutenberg. It’s here. The editor we’ve all been huffing and puffing over is finally gonna land in WordPress core and damage all our livelihoods forever…
…or is it?
Up until recently, I’d just kinda resigned myself to very basic testing with Gutenberg. I’d really just installed the plugin, created posts, and developed a feel for how it works. And this is not because I have some hardcore stance against the new editor. On the contrary, I actually have it installed here on my own site and am writing this very post with Gutenberg and, despite some of the major issues still looming (I’m looking at you, a11y) I don’t mind it. Really, I’ve just been super busy with work and my two boys and have been forced to prioritise.
Now that Gutenberg is just around the corner, however, I needed to get my shit into gear and take some time diving into the code behind the new editor.
Personally, I don’t see deactivating Gutenberg as a sustainable solution. The classic editor will only be supported for three more years, which is something I just wouldn’t feel right delivering to a client. So this got me wondering how I might continue to do something I do a lot of – use custom post types as structured entities that remain queryable with a nice user admin experience.
The common approach in recent years has just been to register the custom post type without editor support and use an ACF field group (or similar system) to control all the fields for that entity. Then, if I needed custom tables for that structured data, I would use the ACF Custom Database Tables plugin that I developed with Hookturn. The resulting admin experience looks a little something like this:
This approach has worked so well for so many people over so many years that it’s become a bit of an ingrained standard and dependency for custom WordPress development. The possibility of losing this approach, I think, has a lot of people very worried, which I can understand, as this kind of work takes time to learn, time to organise, time to standardise, and time to deliver. The thought of having to reinvent everything you know can be a scary one.
I was pleased to find from my dive through WordPress 5.0 Beta 5 and ACF 5.8.0-beta3 that I can still use this same approach directly in Gutenberg using ACF:
This above might just look like regular old Gutenberg but the important thing to note is that the user can’t use blocks on the post type and they can’t type any text into the editor – it’s just a title and the ACF meta box.
Especially awesome for a lot of my work is that I can continue to use the ACF Custom Database Tables plugin to store the ACF meta in structured tables, like so:
It’s actually super easy. All you need to do is hook into two places in Gutenberg to:
Modifying the following snippet should get you there – it’s exactly what I used:
add_filter( 'allowed_block_types', 'pdk_make_lean_types', 10, 2 );
function pdk_make_lean_types( $bool_or_array, $post ) {
$lean_types = [ 'book' ]; // your post types here
if ( in_array( $post->post_type, $lean_types ) ) {
add_filter( 'user_can_richedit', '__return_false' );
$bool_or_array = false;
}
return $bool_or_array;
}That’s a good question and a totally reasonable approach. However, I like the continuity this brings to the user experience. Also, if I’m honest, I don’t mind the fresh white editor. The title could be a little smaller, but I can deal.
Regardless of the approach here, the important takeaway for me is that I can continue to use post types as entities with structured data that I can then store in custom database tables where necessary and query either via meta queries or via custom SQL.
