Should I Build Custom Blocks Using ACF?

Posted on:

The WordPress block editor, Gutenberg has completely changed how we approach building themes. Instead of breaking content into page templates, we're now breaking content down into smaller pieces - blocks. For the most part, but there is one major caveat to the new block-based approach - it can be quite a bit more time-consuming, especially if you're building any blocks manually.

I've talked about how to make a custom Gutenberg block before, but this time we're going to talk a little bit about another approach I sometimes use when building custom blocks. This approach is using a familiar plugin that was especially popular when building using the classic editor, and still remains popular now as it has adapted to the changes WordPress has gone through over the last few years - Advanced Custom Fields, also known as ACF.

How ACF Blocks Work

ACF blocks work almost exactly like working with ACF fields anywhere else, but there's one extra step - you must register the block using ACF directly with acf_register_block_type. This function allows you to pass an array of arguments to control how a block is rendered, and all of the other details specific the block itself, such as the name and description. Once that's done, it's just a matter of building the fields. ACF has a detailed tutorial on exactly how this works.

Once these steps are complete, you will see your custom block added to the block interface, along with all of the fields that your added to the block through ACF.

Benefits of Building Blocks With ACF

ACF has some clear advantages over building a block manually. Mostly because it's faster, and requires less knowledge to get started with blocks.

Building Blocks With ACF is Faster

Building a custom Gutenberg block with ACF is generally faster than building one without ACF. This is because ACF basically allows you to skip writing the JavaScript necessary to register, and build a block in the editor. Instead, you use ACF's interface to specify what attributes your block needs, and what fields are used to customize those attributes. This allows you to focus on the front-end display of the theme instead of how the block looks in the editor.

No JavaScript Knowledge Required

The jump from building WordPress themes to building WordPress blocks is large. Custom blocks rely on a completely different set of tools than what WordPress has historically relied on. If you haven't learned the JavaScript skills necessary to build custom Gutenberg blocks, ACF can be a stepping stone to tide you over until you learn the skills necessary to build blocks without ACF.

Maintaining With ACF Is Easier

The sites I've built with ACF are usually easier to maintain after the site is launched. This is because these sites have less code, so there tends to be fewer opportunities for bugs to crop up. And if there happens to be an issue with the block, it's probably fix-able using ACF's interface directly, which means you may not even need to bust out the code editor to fix the problem.

If the problem is related to your code, you won't have to deal with compiling JavaScript. Instead, it will be inside your PHP template, or your stylesheet. Either way, it is generally straightforward to fix.

Disadvantages of Using ACF

On the surface, Advanced Custom Fields seems like a no-brainier. If it allows you to build and maintain websites with less effort, why bother building custom blocks at all? There's a few reasons - some are clear, and some are a little more unclear. Let's get into each one.

The Interface Feels Disjointed

As of this writing, ACF blocks technically work, but when you actually use one while writing blog content, it becomes clear just how disruptive they are to the natural writing process. Ideally, with any native Gutenberg block, the content will flow naturally and the editor itself will stay out of your way as much as possible. ACF blocks do not do that. Even a simple content block will force you to stop, click on a few things, type, and then click back into the editor.

This is because all ACF blocks are sandboxed inside of ACF-specific legacy fields that have been customized to work inside the block editor. So what you get is this weird mix of the ACF interface intermingling with the block editor, and it's just not that great to work with.

I've found that this isn't that big of a deal on blocks that are intended to be used on pages for layouts and such, but if you're creating a custom block to be used frequently inside of post content, you're going to make editing in Gutenberg a bit slower, and more-awkward.

Re-Using ACF Blocks Is Annoying

If you ever have a small problem with an ACF field on a single site, it's quite nice to simply hop on the site, edit the field in ACF, and go about your merry way. But, what happens if you're using this plugin on two different sites? Now you have to either manually go through and change that field on both sites, or export the field data and use it directly in your theme. Either way, it feels awkward, and there isn't a good way to automate the process.

Instead, if you're serving WordPress clients, your best bet is to take the time to either build out your own set of custom blocks, or pick a set of pre-made Gutenberg blocks, and get really comfortable with customizing those blocks. This makes it possible for you to re-use code on other sites, and once the blocks are build will allow you to build sites faster than building custom blocks in ACF every time you start a new site. This requires a bit of extra forethought, and a little investment up-front, but long-term it will give you a better editing experience without adding a ton of time.

Conclusion

ACF is a great plugin in the right context. I like to use ACF blocks when I have a complex custom block that I will only use on a single site. This saves me time developing an interface for a block that's probably only going to be used a few times ever, and helps to keep DesignFrame's projects on-track. However, I always make custom blocks on anything that is going to be distributed, and that includes if the block is going to be used on multiple privately-managed websites.

Like underpin, I like to standardize how I build everything and keep things as consistent as possible from site-to-site. If you're using ACF to build custom blocks for every site you work on, you're doing the opposite of that, and you're just creating more work for yourself to maintain in the future. Use ACF thoughtfully, and you'll find that you have an awesome tool at your disposal. Over-use it, and you'll find that you've been using a crutch that creates sub-par editing experiences, and technical debt - even if it doesn't use as much code.