Advanced Custom Fields: The Hero WordPress Needs Right Now, but Not the One It Deserves

#

I’ve been a fan of Advanced Custom Fields for a long time now, using it on pretty much every site I’ve built or worked on for the last 5 years.

If you’re unfamiliar, Advanced Custom Fields (ACF) is a WordPress plugin that gives you much greater control of your WordPress content, utilizing custom post meta to enrich the content with structured data. It allows you to build and configure different types of data fields that will appear in meta boxes when your content editors update posts, pages, or custom post types (and much more).

This week I started to use the plugin for something we’re doing with deliciousbrains.com and, after seeing a recent ACF blog post, I took a step back and started to realize just how important ACF has been and still is for WordPress and WordPress developers – even with and especially because of the upcoming arrival of Gutenberg. Let me explain.

How Advanced Custom Fields Works

It took me a while to get my head around what it actually does, so I’ll just show you a quick example. I’ve used it on a dog rescue charity site, where the volunteers add new dogs which need to be rehomed, as a custom post type. However, apart from adding the dog name and description to the dog post title and content, they also want to store the dog’s breed, gender, a link to a video, and some photos of the dog. I’ve created an ACF field group for this data from the ACF admin menu ‘Custom Fields’ > ‘Field Groups’ > ‘Add New’:

ACF field group

You can add fields of all different types. Here I’ve used selects, text boxes, a simple true/false checkbox, and a gallery field which is an ACF Pro-only field type – I’ll come onto the Pro version a bit later. Here’s a look at how you configure a select box with all the options you want your users to select from:

ACF select field type

I’ve then specified that this field group should only appear on the edit screens for the custom post type of ‘Dog’. There’s all sorts of logic here which you can use such as post type, template, category and user role:

ACF configure field location

The real power and light bulb moment of ACF is when you come to add the data. When I edit a Dog post you can see the edit screen looks a little different, filled with a custom meta box with the configured fields :

ACF edit screen

This makes adding all the extra data super easy for content editors and allows developers to specify exactly where they want that data rendered in the theme, using the ACF function get_field:

<div class="columns small-12 medium-9">
    <a href="<?php get_permalink(); ?>">
        <h2 class="icon paw"><?php get_the_title(); ?>
            <span class="dog-data">
                <?php printf( ‘%s %s, get_field( 'gender' ), get_field( 'breed' ) ); ?>
            </span>
        </h2>
    </a>
</div> 

Without ACF, I would’ve had to either use the default WordPress custom meta boxes, code my own richer meta boxes from scratch, or shoehorn breed and gender into custom taxonomies, and perhaps use the native WordPress gallery embedded inside the post content. Shudders.

Advanced Custom Fields Elevates WordPress

Advanced Custom Fields is exactly what WordPress has been missing when it comes to having more control over content.

With over a million active installs since it was released in 2011, ACF has elevated WordPress to a more powerful content management system, undoubtedly contributing to the growth of WordPress itself. It has been widely adopted by developers and agencies who have leveraged it to give clients control of content without the need to use shortcodes, page builders, or even post_content at all. Developers have complete control over where data appears on the front end of the site, avoiding the inevitable client edits that breaks the whole look of the page.

In fact, ACF is so popular among our own customers, we had to add integration with WP Offload Media to make sure images and image cropping in ACF worked with images that had been offloaded to Amazon S3 or DigitalOcean Spaces.

The ACF free plugin is packed with fields and features but the Pro version is essential to get access to some supercharged fields like the repeater, flexible layout, and gallery.

For example, we are using the repeater field to allow users to select certain testimonials to be displayed in a slider on our product pages. The testimonial is a custom post type, so the repeater field contains a nested post object field:

ACF repeater field configuration

It then appears when editing the page so we can control which testimonials will be displayed:

ACF repeater field in edit screen

ACF has always been an extremely developer-friendly plugin. Not just because of its shockingly affordable pricing for the Pro version, but with actions and filters peppered around the codebase it is extremely easy to extend.

ACF also prioritizes improvements that are important to its users. One of the few issues with the plugin I have found in the past was the storage of field configuration in the database, specifically custom post types for field groups and fields. It meant that if you changed the field definition on a development site, you couldn’t push your database using a plugin like WP Migrate DB Pro back to live, as the posts table had likely changed and you would be losing the new data.

This is the age old database merging issue (don’t get me started), which I used to work around by making ACF changes on the live site first then pulling the database to my local site to continue with development. Not ideal at all, but luckily ACF introduced the Local JSON feature, which meant field config can be saved to JSON files which then can be synced with the database.

This is a truly awesome feature which solves the database merging issue for ACF data, and means you can keep the JSON files under version control and make the configuration part of your normal file deployment process. While working with ACF on our site, I added some tweaks to integrate it even more with our git and multi-environment setup:

  • Define the JSON directory to our app/data directory outside of the theme (which might change)
  • Only display the ACF Custom Fields menu item on development environments
  • Automatically sync JSON files with out of date database configuration on admin_init

Even with Gutenberg on the horizon, I would argue that ACF is still very much needed for creating a better editing experience in WordPress.

What Gutenberg Means for Advanced Custom Fields

The new Gutenberg editor for WordPress is certainly a shift in a different direction for editing content than ACF offers. Content is crafted using blocks inside the post content instead of storing as post meta, which gives flexibility to content and page design. Initially, Gutenberg didn’t support meta boxes and actually removed them from the edit-post screen, prompting a lot of outrage. Support has been added now for meta boxes and they appear below the block editor at the bottom of the screen with a minimal, less refined UI.

With custom blocks for custom data instead of custom fields, Gutenberg has the potential to have a huge impact on ACF’s future. Sites that already rely heavily on ACF to customize data might reconsider their approach to custom data, and new sites will be much less likely to install ACF after Gutenberg is merged into core.

It’s not the first time the future of ACF has been put in doubt due to proposed changes in WordPress core. Back in 2013 a new Core plugin team was put together for Post Meta which sounded at first like it would kill the various third-party custom fields plugins out there:

There have been a slew of libraries/frameworks/plugins (CMB, SCB, WPAlchemy, ACF, Pods), which have filled this role for the moment. We’ll look to these as spiritual prequels to a new core-worthy plugin.

At the time, I feared for the future of ACF and even wrote about how WordPress might make certain plugins redundant by introducing new competing features. Ultimately the Post Meta project didn’t go anywhere and is now moot due to Gutenberg, and ACF weathered the storm.

With a user base as large as the ACF plugin has, changes to the plugin can have a large effect and back in 2014 some major changes to ACF’s pricing model and differences between version 4 and 5 caused some confusion within the community. Unfortunately some in the community called ACF “irresponsible” for the changes, creating somewhat of a backlash against the plugin and it’s developer. It was disappointing to see such a popular and helpful plugin get such short shrift, especially as ACF is the product of a sole developer and not a large WordPress company. As a sometimes sole developer of plugins myself, I’d hoped the community would be more supportive and grateful for the effort and product that helps so many.

Since then ACF has continued to grow and evolve, and I was suprised to see it embrace Gutenberg with such conviction back in August, promising to improve on the integration between ACF fields and Gutenberg even further than the default Gutenberg treatment of meta boxes:

While this setup isn’t ideal, we will continue to work within the system to ensure that ACF is integrated into the Gutenberg UI to the fullest extent possible.

If it’s not clear from this article so far, I’m a big fan of ACF, but what they recently announced made me love them even more!

ACF Blocks for Gutenberg

After seeing how beneficial Gutenberg and its custom blocks could be, but noting how complicated the technical process of creating blocks is, ACF set out to deliver to WordPress something that, once again, WordPress should have done itself:

Manually creating custom blocks means digging through endless mounds of JavaScript. ACF Blocks, on the other hand, does all the hard work for you so you can sit back, relax and continue writing simple PHP and HTML

Dark Knight GIF John Blake looking in awe

This is the example block registration code taken from the article, it’s super simple:

add_action('acf/init', 'my_acf_init');
function my_acf_init() {
    // check function exists
    if( function_exists('acf_register_block') ) {
        // register a testimonial block
        acf_register_block(array(
            'name'              => 'testimonial',
            'title'             => __('Testimonial'),
            'description'       => __('A custom testimonial block.'),
            'render_callback'   => 'my_acf_bock_render_callback',
            'category'          => 'formatting',
            'icon'              => 'admin-comments',
            'keywords'          => array( 'testimonial', 'quote' ),
        ));
    }
}

Once you’ve registered a block you need configure the contents of the block like a normal ACF field group, and then render the block on the front-end. This is all covered in the article and looks both straightforward and powerful. As they stress, ACF Blocks shouldn’t replace meta boxes when they are needed, but “it levels the playing field and allows more developers to take advantage of Gutenberg’s key feature.”

The Future of ACF

Since it was released ACF has been a vital complementary plugin for WordPress. It extends it, enriches it, and makes it more usable. I don’t think I could build WordPress sites without it. Unfortunately, for such a powerful and helpful tool for WordPress, it hasn’t always had the easiest of rides.

The new ACF Blocks for Gutenberg is the icing on the ACF cake. It’s a great investment by ACF in the future of WordPress, because it will help lower the barrier of entry for developers to extend Gutenberg without having to start on the steep learning curve of React, yet another new JS framework introduced into WordPress. In the long run those who are pushing so hard for Gutenberg will see this as a win.

Are you a fan of Advanced Custom Fields? Have you tested out ACF Blocks yet? Are you planning on using Gutenberg and ACF together? Let us know in the comments below.