Advanced Custom Fields with Gutenberg – A Vision

First and foremost, this post is simply my vision for what ACF could be with Gutenberg. None of this is actually in production, development or anything of the sort, nor does the team at ACF have anything to do with this post. It would simply be REALLY COOL if this is how it turned out. Advanced Custom Blocks, anyone?

Gutenberg is a huge buzzword right now in the WordPress world. With its impending release developers, bloggers, plugin authors, theme creators and more are all trying to wrap their heads around the impact it will have on their business.

At first, I was against it as it will have an impact on my business which is running smoothly. I will have to learn a new coding language, change the way I build sites, change the way I train my clients and have a relatively large shift in what I am comfortable, and good, at doing. I have now started to embrace the change and see the true potential of Gutenberg; because, quite frankly, what other choice is there?

As I think about the potential of Gutenberg I also think about the potential of how it will integrate with my go-to plugin; Advanced Custom Fields (ACF). I use ACF on 100% of the sites I code. It has the flexibility to basically create any functionality needed for the sites I build and it is a staple in my development process. Not only does it expedite my development process, but it gives me a tool to provide the end user with a way to easily update their site without needing to know any code.

Does ACF Work with Gutenberg Now?

Yes, ACF works with Gutenberg.

One of my main concerns when Gutenberg started gaining traction were rumors that it would not support metaboxes, thus rendering ACF — and every website that uses ACF — useless. Luckily, those concerns were squashed as newer iterations of Gutenberg made it clear that metaboxes would be supported.

While you can no longer set a Field Group to the “High” position (ACF Field Groups would look weird above the Gutenberg editor anyhow), everything else seems to function as it did pre-Gutenberg as far as I can tell. ACF Field Groups show under the Gutenberg editor. They look slightly different visually, but function as intended. You can set the position of Field Groups to “Side” and they do show in the sidebar of the Gutenberg editor in the “Extended Settings” dropdown.

If ACF already works with Gutenberg, why change it?

While Advanced Custom Fields still functions as intended, it does not inherently function within the framework of Gutenberg. The Gutenberg editor will give users the ability to easily create more dynamic pages using the blocks system. While ACF still works, you won’t be able to inject ACF data between these blocks.

Gutenberg spits out all of it’s data together in the_content(). We can add ACF stuff all around that, but — aside from creating a shortcode and using the shortcode block — we cannot add ACF fields within Gutenberg blocks.

So, while ACF still proves to be very useful, it really doesn’t work hand-in-hand with Gutenberg — yet!

My Vision for ACF & Gutenberg – We’ll Call it Advanced Custom Blocks

In a perfect world ACF becomes a block generator. While you can still use ACF exactly how it currently works, ideally you could also use it to create blocks.

Gutenberg ACF Block

If you select a style of “Block” the field you add to this fieldset would show up in a Gutenberg Block so you could use them directly within the Gutenberg editor.

Is this possible with how Advanced Custom Fields has been coded? I have absolutely no idea, but it sure would be cool! Even if they forked ACF and created Advanced Custom Blocks I would be more than will to pay for it. Advanced Custom Fields is already undervalued at 100AUD for a developer license (and no annual fees), so paying them for this type of product would be a no brainer.

Some other things to consider

There are some other things to consider. Just adding the fields to a block won’t really do much in and of itself — aside from allowing you to add ACF fields within other Gutenberg blocks. Those fields would need to be attached to a template, including some CSS, to allow them to render properly within the editor. Without this, you would just end up with content that has no template or formatting.

Without a template or formatting you are defeating the purpose of Gutenberg. The goal is to have the Gutenberg editor visually mirror what the site will look like on the front end. So, you’ll need the template that the Gutenberg editor uses to match the template you create and use within your theme. The same goes for the CSS.

My initial thoughts for a template solution would be to a folder path, specified by ACF, where you would create your templates (maybe /acf/blocks/yourtemplate.php), where the file name must match the field group name. These templates would be used by WordPress to render the layout within the Gutenberg editor. Similar to how you can add CSS specifically to the Gutenberg editor so it mirrors the CSS on the front end of the website, these templates would need to be registered and used within Gutenberg to output an actual visual depiction of the block created by ACF.

To take a step further, a template tag could be created to output the ACF template you have created. So instead of creating the template specifically for Gutenberg usage and then duplicating that template to use within you theme, a template tag — or some other method — could be created to output that template within you theme.

This approach would allow developers to create one template that would be used within Gutenberg and within their theme to ensure they mirror each other.

Toggle between visual and data entry

The other issue I foresee is toggling between content entry and visual depiction of ACF elements. The nature of ACF is fields that you enter data in to which are then rendered on the front end. So, in order for this ACF Block Approach to work, there would need to be a way to toggle between data entry mode and visual depiction mode (or if the data could be done directly on the styled templates that would be even cooler…).

Again, I really don’t know the feasibility of this, but thinking of the possibilities is pretty exciting.

Will ACF end up with a Gutenberg integration?

So, the big question is whether or not ACF will have a direct integration within Gutenberg, or will it continue to function as it currently does. Note that either way, I’m still going to use Advanced Custom Fields on every site I build. While I obviously have no definite answer, I would say that ACF has a huge market opportunity. They have an amazing reputation, a massive group of dedicated users, and an opportunity to enter an untapped market of easy, custom block creation.

If the ACF team does decide to create something like Advanced Custom Blocks — and it is done well — I believe ACF would be hit with a huge influx of cash and could position themselves as THE go-to solution for creating blocks in WordPress.

Only time will tell…

Reader Interactions

Comments

  1. Interesting post, Matt. I have often coded bespoke themes using ACF (particular Flexible and Repeater fields) to build modular layouts. And, yes, it makes more sense in future to be using Gutenberg to provide these flexible layout “blocks”.

    I think being able to assign an ACF Field Group to a Gutenberg “Block” – or to create a Custom Block for the Field Group – could be really powerful. I envisage this could be similar to the way we can currently create and assign a Field Group to an “Options” page in WP.

    Currently, I’m experimenting saving custom field values in ACF and then registering new Gutenberg blocks with output to read these fields and output specific blocks of content… but this will quickly become clunky. Much better if ACF can start to interact with Gutenberg blocks in a meaningful way.

    Fingers crossed!
    m

    • Hey Marcus – pretty much my thought exactly. I hope to continue to use ACF as a big part of my development process, so if they integrate seamlessly with Gutenberg I would be thrilled! Thanks for the feedback.

Leave a Reply

Your email address will not be published. Required fields are marked *