WordPress’s still relatively new Gutneberg 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, 93digital 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.
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.
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.
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.
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.
The homepage: the least important page on your website?
We won Gold!
Do you have an exciting strategic project coming up that you would like to talk about?