Storing ACF Block Fields as Post Meta

If you’ve worked with ACF blocks, you may have noticed that ACF blocks store their content a bit differently than regular custom fields. Where regular ACF fields store their data in the post meta table, ACF block fields have their content within the post_content field of the posts table.

What does this difference mean?

Meta queries are what end up being implicated by this difference, most notably your inability to do a meta query for a field set up as a block field. This could result in disjointed editing experiences where custom fields that needed to be stored so they could be used for querying were edited differently than other fields that were fine existing as block data and similar.

This is changing in ACF 6.3!

Or, I should say, you will have control over whether it changes. ACF 6.3 will have the ability to opt into storing block fields as post meta instead of the current way they get stored. You’ll be able to opt into this behavior by modifying your block.json file. It does seem like it is basically all or nothing behavior where all block fields within any block would be stored as post meta or none, but this still opens up potential new approaches for simplifying the editing experience for clients.

With this change combined with ACF block field validation working, exciting things are ahead for ACF! If you want to help the ACF team test the beta version of ACF 6.3, head over to your ACF account to grab the beta to preview these features and check out the blog post on the beta release for more.