ACF Blocks: A happy Gutenberg medium?

WordPress’s still relatively new Gutenberg editor saw a big change to the way custom theme development was undertaken when it was first shipped with WordPress 5.0, back in December 2018. The editor’s new block-based approach gives WordPress users flexibility over the format of a page’s content while more closely replicating how a page will look on the front end, directly within the editor.

Pre-Gutenberg, ClarityDX used a module based approach for the development of page templates, utilising the custom fields functionality offered by the excellent Advanced Custom Fields Pro plugin to develop flexibility and agility for our clients.

The release of WordPress 5.0 offered us a new and exciting way of working with page data and it also seemed like a natural evolution to our already successful module-based development approach.

Why ACF Blocks?

While there are dozens of core blocks offered by WordPress out of the box, as theme developers we are required to create custom blocks in order to meet the designs and specifications of the sites we build. This posed the challenge of quickly needing to adopt custom block development into our builds which required the whole development team to learn how to build custom blocks.

I’ve always felt there is quite a big learning curve when it comes to effectively developing blocks for the Gutenberg – especially for less experienced WordPress developers who may only be getting to grips with the ins-and-outs of WordPress or still honing their JavaScript skills. Custom block development requires developers to have proficient knowledge in both PHP (a back end technology) and JavaScript (a front end technology) – specifically React JS, which is the JavaScript framework used to power the editor.

As an interim solution, we decided to utilise the new ACF blocks feature offered as part of the Advanced Custom Fields Pro plugin. This would allow us to instantly start developing Gutenberg blocks without needing the whole development team to quickly gain proficient knowledge in custom Gutenberg block development.

Benefits

Creating a new instance of an ACF block requires a simple function call in PHP. This code is used to set its attributes such as its name, description, category, icon, a post type, and the filepath of a template file which consists of the block’s HTML.

Creating fields and fetching field data within the template uses essentially the same methodology as working with native custom fields in ACF. Once a block has been initialised within the code, a Field Group – where fields can be added –  can be created within the WordPress admin area and assigned to the block. Fetching field data within the template used to render the block also uses the same functionality as the native custom fields. These similarities have helped to make the transition over to blocks-based development approach a smooth one.

We can also easily add the CSS and JavaScript used to style the block on the front end to the WordPress admin area. This just requires a small addition to be made to the function call used to initialise the block, that tell’s the block to use the specified CSS and JavaScript assets in the admin area.

Drawbacks

There is some missing functionality when compared to custom block development. While an ACF block is a more than satisfactory solution for most block types, there are some instances where we may need to create a custom block from scratch, such as when a custom block is required to contain nested blocks. The InnerBlock component allows any available block to be nested within another block. This would need to be built by a developer in the team who is more experienced in working with Gutenberg. 

ACF blocks only come packaged with the Pro version of the plugin which requires a paid subscription. This isn’t a huge drawback for us as the agency already has a Pro subscription, but, considering creating a custom block is completely free, this has to be labelled as a drawback as it creates a barrier for freelance or hobbyist developers who may want to try out the feature.

One other small drawback is the reliance the block functionality has on the plugin itself. If ACF Pro is deactivated or removed from a site then the blocks will no longer be available in the CMS and PHP errors may be thrown within the theme code.

One key difference

When using a core or custom built block within the editor the user can edit the text/image/style etc. of a block directly within the block. With an ACF block, all the data is controlled within custom fields in the side panel alongside the editor when a block is selected, so the block itself is non-interactable.

Both these data entry methods have their benefits. I feel ACF’s method here makes it more obvious to the WordPress user what data can be edited within the block, however the default method of entering data directly into the element within the block is probably a more intuitive approach.

Closing words

The ACF Blocks solution has been a big hit within the development team due to its ease of use, similarities to working with native custom fields and how closely we can replicate a custom developed block. It allowed us to make a quick transition over to Gutenberg last year and has generally been a huge success. So much so, we are still utilising it today, alongside custom WordPress Gutenberg block development.