How ACF Stores Data via Gutenberg vs. Traditional Fields & Why It Matters

What value are custom fields without the data inside them? Understanding how and where ACF data gets stored is crucial to accessing it. Based on choices you’re making in ACF, WordPress is storing that data in completely different locations in completely different ways in your site database. If you’re unaware of the implications of those differences, you could end up structuring your custom fields in a way that doesn’t make the data you want accessible in the way that you need.

Let’s break down those differences and their impacts so you can make the best decision for your custom field data in future projects.

How Traditional ACF Custom Fields Store WordPress Data

When a field group is created in ACF and assigned to a page, post, or other content type, the data you enter in that custom field is stored in the wp_postmeta table or its equivalent based on your WordPress database prefix. For example, let’s say you create a simple text field via ACF and call it My Custom Field and attach it to a post in the settings.

If you create a new post and populate the custom field with a value, such as “Test”, and save the post, you can hop immediately over into the database and find that created metadata record listed within the postmeta table.

Typical WordPress metadata has a meta_id (unique identifier for this database record), a post_id (the item the custom field is attached to), a key (the ACF field name), and value (the data put into the field.) This data can be leveraged to grab the field’s content.

If I were to take just a super basic loop involving a meta query:

$args = array(
  'meta_query' => array(
    array(
      'key' => 'my_custom_field',
      'value' => 'Test'
    )
  )
);

$wpFieldworkQuery = new WP_Query( $args );

Looping through this query would return any post with “Test” in the my_custom_field meta key created through the above method.

How Data Gets Stored From ACF Fields Attached to Gutenberg Blocks

Now, let’s look at ACF custom fields when attached to a Gutenberg block instead. If a block is registered and an ACF field is attached to it, you can create a post, add the block to it, and populate the ACF field within that block.

However, after saving the post, if you pop over to your database, you’ll notice that no new ACF data has been added to your postmeta table at all.

So where is ACF data stored from a Gutenberg block?

Locating ACF Gutenberg Data in Your WordPress Database

Data from ACF fields in Gutenberg blocks can be found in the wp_posts table instead. Within the wp_posts table, there will be a record for the post you added the Gutenberg block to, which can be identified by the post ID. By viewing this record, you’ll see the ACF data within the post_content field of the record.

If you populate an ACF field within a Gutenberg block and save it, you’d see something like the following if you view the post in the wp_posts table and look at the post_content field within it:

<!-- wp:acf/sample-block {"name":"acf/sample-block","data":{"gutenberg_custom_field":"Test","_gutenberg_custom_field":"field_6365994ef7938"},"mode":"preview"} /-->

You can see the custom field value within this markup. The block was called Sample Block and the ACF field created had the name gutenberg_custom_field and a value of “Test.”

Wondering what the fields are for ACF with an identical field name preceded by an underscore? This is a reference ACF itself uses to determine things like the kind of ACF field it is. You’ll see this with both Gutenberg ACF fields and normal post meta ACF fields.

The Impact of These Differences

Okay, so the two field locations store their data differently? Big deal, you might think. However, this difference has enormous implications on how you can interact with that data.

Meta Queries Are Impacted

Most notably, meta queries do not work the same way with both custom field locations. Any ACF field you attach to a Gutenberg block will not be compatible with a standard meta query returning items with a particular key/value combo. If you are wanting to pull in content types on your WordPress site based on an ACF custom field or do more advanced logic based on an ACF field’s value, you may want to attach the field to the content type directly as traditional post meta vs. attaching the field to a block you’re using within the page.

How Data Can Be Accessed from Different Pages Also Changes

Accessing ACF fields from a specific item from anywhere on your site can be done easily with traditional ACF fields, something like this:

<?php the_field('field_name',$postIDofItem); ?>

However, do that with a Gutenberg block custom field and you won’t see the same.

Now, does that mean there’s no way to get ACF data from a Gutenberg block outside of the page it’s on? Not necessarily. You just have to use a completely different approach than what you may be used to having worked with ACF fields in the past.

Plan How You’re Using Your Custom Field Data

As you can see, it’s important to understand how the data you’re inputting into WordPress is getting stored because it impacts how you can access said data. By planning how you’re using your custom fields in advance of any build, you can ensure you’re setting them up in a way where they’re able to be pulled in however you need.