ACF Gutenberg Blocks vs regular ACF Fields

• prowebassist

• July 8, 2020 at 6:30 am

Hi,

Does anyone have any clear examples (or maybe a link to an article) for why/when one would use ACF Gutenberg Blocks (i.e. later referred to as Blocks) vs using default/regular ACF Fields (i.e. later referred to as Metaboxes)?

Besides an obvious “visual builder”-alternative appeal of Blocks, I can’t help but focus on the fact that Blocks store data as HTML comments in the post_content, while Metaboxes store all data as separate entries in wp_postmeta. And that’s such a big difference. So I want to understand all of the nuances, advantages & disadvantages of each method.

Has anyone written a detailed article with a breakdown of each method, when/where it’s appropriate to use them and what limitations each method has?

I already can think of a few issues, but maybe I am missing some, so I want to reference other people’s opinions.

For example:

1) When it comes to Blocks, it seems that they would be much faster at data retrieval by default, because the data is stored as one big “blob” inside post_content. Which means that, theoretically, we only need 1 database query to get all of the content & ACF fields data. So that means that if you intend to have very complex pages with lots of ACF fields, you should use Blocks. So that’s a clear advantage over regular meta fields.

Or is it? Because yes, if you use regular ACF fields and a default ACF get_field() function, that would query wp_postmeta for each piece of data separately. Which is bad (possibly even very bad). But if you use `<a href=”https://developer.wordpress.org/reference/functions/get_post_custom/”>get_post_custom()</a&gt; you’ll get all of the post meta data at once and not suffer any performance punishment whatsoever (since that function also caches data, so it’s lightning fast for each consecutive request).

So seems like performance-wise both can achieve the same results. Or am I wrong?

<strong>2)</strong> Blocks seem to have a downside to storing all of the data inside post_content, because <strong>(a)</strong> I can’t easily query that data from another page/post and <strong>(b)</strong> individual custom fields are not de-coupled from post content itself. I’ve read in the Q&A that you can “load the post_content of a given post, and then parse the blocks using the parse_blocks() function” which seems reasonable, but how efficient is it? Also, if I wanted to pull a dozen pages somewhere, based on a matching meta value, that would be pretty easy & “cheap” (resource-wise) to do with Metaboxes and a custom WP_Query. But what about doing something like that using Blocks? How expensive would it be? Would that even be possible? Seems like I’d have to pull ALL posts, loop through each one, run parse_blocks() on EVERY post and only that way I’d find the posts with my desired ACF field value. Seems like that would be super expensive & CPU time consuming to do.

Or I am thinking about it completely wrong and my use-case for Blocks is completely inappropriate?

<strong></strong>3)</strong> Another issue I can see with Blocks is if data is hardcoded into post_content, does that mean that I can’t change a ACF field output type (i.e. if I want to change the output of an ACF file field to return attachment ID, instead of a URL)? With Metaboxes, I can just use get_field('field_name', $post_id, true) and get the ID no matter what the original output type is in ACF. But if it’s saved a Block as a URL, does it mean it’s hardcoded into the post_content and the only way to change it is for me to update the block template & then also manually update/re-save every page where it was used?

I think most of these issues stem from my lack of understanding of where I should be using Blocks vs Metaboxes. Hope someone can enlighten me.

Cheers,
Alex

• vipstephan

• July 9, 2020 at 7:36 am

I’ve been pondering the same about the use of Gutenberg for websites with bespoke layouts (i. e. where editors aren’t supposed to place whatever blocks they like in whichever order they like). My take is this: whether to use blocks or metaboxes depends on where you want the content to appear eventually. If you need reusable custom content within the main content where the editors can decide themselves how many blocks they want to insert, you’d use blocks; if you need custom content in areas outside of the main content and/or want to restrict the liberty of editors you’d use metaboxes.