Reply To: Blocks vs Metaboxes

• prowebassist

• July 3, 2020 at 1:02 am

Hi,

Can someone please give some clear examples (or point me to an article) of why/when one would use ACF Gutenberg Blocks vs using regular ACF Fields (i.e. metaboxes)?

Besides an obvious visual appeal of ACF Gutenberg Blocks, I can’t help but focus on the fact that Blocks store data as HTML comments in the post_content, while regular ACF fields store all data as separate entries in wp_postmeta. And that’s a pretty huge 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 there is theoretically only 1 database query to get all of the content & custom field data. So that means that if you intend to have 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 postmeta 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 (a) I can’t easily query that data from another page/post and (b) individual custom fields are not de-coupled from post content. I’ve read the Q&A that said that I 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 field value, that would be pretty easy & “cheap” (resource-wise) to do with a custom WP_Query. What about doing it in Blocks? How expensive would it be? Would that be even 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 ones with my desired custom 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 is if data is hardcoded into post_content, does that mean that I can’t change a custom field output type (i.e. let’s say I want an ACF file field to now return attachment ID, instead of a URL). With regular fields, I can just use get_field('field_name', $post_id, true) and get the ID no matter what and manipulate it how I want. But if it’s saved in a Block as a URL, does it mean it’s hardcoded into the page 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 where I should be using Blocks vs Meta fields. Hope someone can enlighten me.

Cheers,
Alex