ACF 5.8, a Flood in a Gutenberg Desert
Managing the content body of a website using blocks is generally a good idea, but from the point of view of someone developing larger, very customized projects, where sometimes the administration interface is significantly more complex than the front-end, Gutenberg, for me, is a stunningly bad implementation of that good idea1
The discussion has been raging on for a while, and the point of this post isn’t to add to it; I have bigger fish to fry. If you’re interested, I encourage you to read Peter Knight’s comment on WP Tavern, which eloquently distillates my own thoughts on the whole debacle, much better than I ever could.
My concern is rather that I have a few very large projects on my hands, and the prospect of simply upgrading WordPress to 5.0, is definitely not the same afterthought it was when upgrading to any other version until now. Leaving the vague and floating timeline aside2, from the testing I have done, both by myself and with some clients, it will cause significant, and unexpected, turbulence on both the projects’ timeline, as well as budget, and defending those changes to a client makes me sound, to them, like Gutenberg was my idea3
To be clear: none of them think this is a bad idea, per se, conceptually, but every single one of them hates the implementation. Some because it’s confusing (agreed, those are easy to retrain, with patience), others (more technically inclined) because they’re horrified at how this will impact the development teams’ workflow (oh look, we need React developers now), some because it isn’t accessible (goodbye government work for me), and even a few because they can’t see the point of turning their installation into Squarespace or Wix, but with less functionality. To those concerns, I would add my own, of lesser concern to them: the politics of it all is horrid, and is fracturing a community on whose shoulders WordPress’ success was built.
people are in dissonance over WP decisions (ship Gutenberg at all costs) not following WP values (design for everyone, emphasize accessibility).
we assume decisions stand on values. and they just don’t in WP. values are used to decorate decisions after the fact, not shape them.
— Andrey Savchenko (@Rarst) October 12, 2018
I use the Advanced Custom Fields plugin extensively. It’s robust, well coded4, well documented, and well supported. What money I’ve spent on a Pro license, has paid itself several times over. To me the only downside, if you can call it that, is that it adopts the “Custom Fields” nomenclature in its name, clearly a developers idea of how to describe “Content Attributes”. ACF is, to me, what the implementation of those attributes should always have been in WordPress core, short of a normalized database design5.
Its developers have done a brilliant job of keeping pace with the development of Gutenberg, in a sensible, level-headed way, making sure that all those who depend heavily on the plugin6 aren’t left hanging after an upgrade to WordPress 5.0, which may have looked like a catastrophe to intricate installations.
Thus, today’s announcement of an ACF Gutenberg Block is, to me, both a relief and a joy. The gist of it is brilliant: you can use ACF’s interface to define and render blocks, without touching React or even PHP7. This means that I can suddenly reduce some of the friction of introducing Gutenberg in existing projects, and have custom blocks developed much, much faster, and with less impact on the developers teams’ organisation. It won’t save me from the puzzling editing interface, and won’t help me with installations where most content objects are in the thousands, and not really subject to “layout juggling”, nor will it help me with accessibility (at least I don’t think it will, I’m still exploring the ACF 5.8 beta.)
All in all, once again, this feels very much like part of how I’d implement blocks in core in a sensible way, but “sensible” doesn’t seem to be a very popular word in WordPress core these days. That said, I’m not a core developer, which appears to disqualify me from expressing an opinion at all.
In short, thank you Elliott, for all the hard work; it has not gone unnoticed.
- Please, please refrain from commenting on how it is so much better than the current editor: TinyMCE is no one’s favourite, but it does not logically follow that anything, simply because it’s different, is better. ↵
- “Maybe November, maybe December, or perhaps January”, is not a timelime complex projects can work with. ↵
- And I’m certainly not going to defend that Gutenberg is a good idea for managing 10.000 objects of a custom post type. (and that’s just one CPT, there are countless others.) Not now, not ever. ↵
- Hooks everywhere! ↵
- This is not a critique, not anymore. I understand that there are historical, legacy reasons for this even if, mysteriously, those reasons don’t seem to apply to the Gutenberg idea itself. ↵
- To the “don’t rely on a plugin, code your own” folk, I have this to say: “don’t rely on a caching/SEO/anti-spam plugin, code your own” or even “don’t rely on Gulp/Grunt and the two thousand npm packages, code your own” ↵
- You still can, and I probably will. I like to tweak 🙂 ↵