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 idea¹

The Desert

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 aside², 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 idea³

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.

The Flood

I use the Advanced Custom Fields plugin extensively. It’s robust, well coded⁴, 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 design⁵.

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 plugin⁶ 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 PHP⁷. 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.

#ACF#Advanced Custom Fields#Gutenberg