For more on this topic, see “Where I’m at with WordPress: Gutenberg – as a user“
The awesome development team at Delicious Brains (yes, that’s really their company name) posted this excellent write up of the Gutenberg project today, and it prompted me to write more.
This is actually text taken from a discussion I had with a team that I work with. That discussion was a chance to put my long-mulled-over thoughts into text, and I’m formalising and publicising that here.
If you don’t know what Gutenberg is then go and read my previous post about it.
Context: My business
The context of this is that I’m a freelance software developer whose bread and butter is MOSTLY writing code for WordPress: custom themes and plugins for clients. I’ve been doing this for 6 years now, and some clients have come and gone, but I’ve still got a lot of highly-customised WordPress projects that I maintain and develop, and sites that I host for people.
And WordPress’s current plan with Gutenberg is to have it on, by default, for everyone that updates to version 5.0 of WordPress when it’s released sometime in the first half of this year.
My response
I can see that this will totally confuse most of the people that I look after sites for. Bear in mind that quite a lot of my clients are small charities or very small businesses – some of them very rarely log in to their sites. And when they do log in and see something so very different it will confuse them and I’ll have to spend time helping them.
I’m also concerned about custom fields/meta boxes not working (though I’m trusting that this will all work without change), and the suitability of the Gutenberg interface for editing certain types of content.
So my default position is that for existing sites I will probably install the Classic Editor Plugin until either:
- sites have been reviewed and are ready to have Gutenberg enabled; or
- clients have requested the new editor and we’ve explained the caveats around it; or
- I otherwise become confident that nothing will break and my clients have been adequately briefed and trained.
The response from one person I work with to this was “Do you mean to say that we won’t support this new WP feature? That feels like a big step – essentially the 1st time we’ve done such a thing.”
And to respond to that I put forward some of the issues in more depth.
Gutenberg Issues
1 – This is a drastically new interface.
Allowing all sites to suddenly have it will probably result in a raft of support requests and confusion. My opinion (and I’ve made this clear to core developers) is that NEW sites should have it enabled by default and existing sites should have it as opt-in. BUT it looks like they’re just going to push it out to everyone as of v5.0.
2 – The Gutenberg interface simply isn’t suitable for quite a lot of applications.
You might not want Gutenberg for editing some custom post types like events or countries. And to have it enabled for some post types and not others will be doubly confusing for users.
2a – Selective disabling will require code changes
In any case disabling Gutenberg on a per-post-type basis will PROBABLY require code changes on every site that I/we have developed that has custom post types. (It’s not quite clear how this will work yet though).
2b) Making Gutenberg work the way it’s been suggested you should is a LOT of work!
The suggested way to adapt custom-field-heavy post types to Gutenberg that has been stated by an Automattic engineer is:
- Create Gutenberg blocks instead of meta boxes for custom fields/post meta data.
- Link the blocks to the post meta data so that data is properly structured inside WordPress.
- Provide a Gutenberg “template” layout that contains all the elements/data in the right places on the screen.
- FIX this layout so that the user can’t modify the layout/structure/fields – only the content.
I have described this as like upgrading a bicycle (a vehicle that’s cheap, that’s clean, that you can ride without training and licensing) to a motorbike, and then attaching pedals so that you can get all the benefits of the bike back.
This is a bit of a crazy workaround. And it’s a large amount of effort to get back functionality that you used to have for free.
(Note that yes, a motorbike has its own advantages over a bicycle – it’s faster and louder and many would consider it an upgrade! But you have to want a motorbike, and you have to get trained to use it and you have to license it and insure it and buy a helmet and so on… You don’t just give everyone a motorbike because you think it’s better – some people love their bicycles!)
I trust that custom fields will continue to work. But this alternative, Gutenberg-ready approach is a lot more effort and requires learning/training for a lot of developers.
I also can’t help thinking that what developers really wanted was a fields API. And I also find the WordPress data model pretty restrictive and would like something like post relationships in core rather than having to fudge it with post_meta or a custom table. Gutenberg “blocks” are great, but they aren’t structured data. They’re just a blob of text in the database. And connecting blocks to an already-lacking data structure as a workaround really doesn’t seem helpful.
Note/plug: if you liked that paragraph then you might want to learn about MVC frameworks like Laravel instead.
3 – We don’t know what will break and how to fix it
It’s not yet clear if and how all our meta boxes and ACF fields and stuff will work in a new Gutenberg world. They should all “just work” (the ACF guys in particular seem to be on it) but again, it’s not clear at this point if any work will be required. Right now we don’t know what, if anything, will break and how much effort it will be to fix it.
4 – What will clients do with it?
Do we really want to let all clients have an interface where they can create columns, layouts, tables, and whatever other “blocks” are present in the system? This is nearly the equivalent of installing a page builder for everyone? Is this a good idea?
Opinion amongst the people I work with is divided. And I do understand that some clients have been wanting this. But part of our job is implementing a design and layout that works, and I’m concerned that Gutenberg allows clients to step outside of our expertly-crafted page structures. Yes, you can lock the layouts. But that’s more effort again. So I don’t know what to think here.
Summary
Having Gutenberg will be great for new websites and new projects going forward, but I’ve yet to be convinced that enabling it for all sites when they update to WordPress 5.0 is a good idea. So my plan is not to do that – to disable it until sites and people are ready for it.
What are your plans? If you’re a client of mine, feel free to drop me a line to discuss Gutenberg, or even to try it out.