Duplicated ACF blocks includes always the same block id

[CreativeDive]

Hey Elliot,

with the upcoming WordPress release, the awesome pattern feature is coming. So we can add our own block pattern with ready to use included blocks.

This is an example how we can add this:

register_block_pattern(
	'wphave/footers-pattern-02',
	array(
		'title'   => __( 'Footer', 'wphave') . ' ' . __( 'Example', 'wphave') . ' 2',
		'content' => "<!-- wp:acf/section {\"id\":\"block_5eccdfd5dfb2d\",\"name\":\"acf/section\",\"data\":{\"color_or_gradient\":\"bgcolor\",\"_color_or_gradient\":\"field_5c82ba9ff79f9\",\"background_color\":\"#727272\",\"_background_color\":\"field_5a075cd7f03e6\",\"image_or_video\":\"none\",\"_image_or_video\":\"field_57f565b0f7907\",\"bg_layer\":\"none\",\"_bg_layer\":\"field_5c82c38d81e9d\",\"remove_overlay\":\"0\",\"_remove_overlay\":\"field_59b63ce9dd1c5\",\"overlay_color\":\"\",\"_overlay_color\":\"field_5b93a4e73a57f\",\"overlay_transparency\":\"35\",\"_overlay_transparency\":\"field_5b93a819abdcc\",\"remove_overlay_gradient\":\"0\",\"_remove_overlay_gradient\":\"field_5d00cfdd5ba78\",\"background_clone\":\"\",\"_background_clone\":\"field_5d4a760f86882\"},\"align\":\"full\",\"mode\":\"preview\"} -->\n<!-- wp:acf/site-logo {\"id\":\"block_5eccdff2dfb2e\",\"name\":\"acf/site-logo\",\"data\":{\"site_logo_select\":\"white\",\"_site_logo_select\":\"field_5e9eddee6103b\",\"item_alignment\":\"left\",\"_item_alignment\":\"field_5d66234f9775c\",\"site_logo_align_style\":\"\",\"_site_logo_align_style\":\"field_5e9eddce2d7d8\",\"site_logo_width\":\"166\",\"_site_logo_width\":\"field_5e9f41da433d5\"},\"mode\":\"preview\"} /-->\n\n<!-- wp:columns {\"textColor\":\"white\"} -->\n<div class=\"wp-block-columns has-white-color has-text-color\"><!-- wp:column -->\n<div class=\"wp-block-column\"><!-- wp:paragraph {\"fontSize\":\"normal\",\"style\":{\"color\":{\"text\":\"#2e2f30\"}}} -->\n<p class=\"has-text-color has-normal-font-size\" style=\"color:#2e2f30\"><strong>NEED HELP?</strong></p>\n<!-- /wp:paragraph -->\n\n<!-- wp:list -->\n<ul><li>Terms of Condition</li><li>Privacy Policy</li><li>About Us</li><li>Server &amp; Support</li></ul>\n<!-- /wp:list --></div>\n<!-- /wp:column -->\n\n<!-- wp:column -->\n<div class=\"wp-block-column\"><!-- wp:paragraph {\"fontSize\":\"normal\",\"style\":{\"color\":{\"text\":\"#2e2f30\"}}} -->\n<p class=\"has-text-color has-normal-font-size\" style=\"color:#2e2f30\"><strong>START A CONVERSION</strong></p>\n<!-- /wp:paragraph -->\n\n<!-- wp:paragraph {\"textColor\":\"white\"} -->\n<p class=\"has-white-color has-text-color\"><strong>mail@wordpress.com<br>1-877 273-3049</strong></p>\n<!-- /wp:paragraph --></div>\n<!-- /wp:column -->\n\n<!-- wp:column -->\n<div class=\"wp-block-column\"><!-- wp:paragraph {\"fontSize\":\"normal\",\"style\":{\"color\":{\"text\":\"#2e2f30\"}}} -->\n<p class=\"has-text-color has-normal-font-size\" style=\"color:#2e2f30\"><strong>VISIT US</strong></p>\n<!-- /wp:paragraph -->\n\n<!-- wp:paragraph {\"textColor\":\"white\"} -->\n<p class=\"has-white-color has-text-color\">PO Box 16122 Collins Street <br>West Victoria 8007 Australia</p>\n<!-- /wp:paragraph --></div>\n<!-- /wp:column -->\n\n<!-- wp:column -->\n<div class=\"wp-block-column\"><!-- wp:paragraph {\"fontSize\":\"normal\",\"style\":{\"color\":{\"text\":\"#2e2f30\"}}} -->\n<p class=\"has-text-color has-normal-font-size\" style=\"color:#2e2f30\"><strong>FOLLOW US</strong></p>\n<!-- /wp:paragraph -->\n\n<!-- wp:acf/social-profiles {\"id\":\"block_5ecce13ddfb2f\",\"name\":\"acf/social-profiles\",\"data\":{\"item_alignment\":\"left\",\"_item_alignment\":\"field_5d66234f9775c\",\"social_profiles_align_style\":\"\",\"_social_profiles_align_style\":\"field_5ec78d2c4efb2\"},\"mode\":\"preview\"} /-->\n\n<!-- wp:paragraph -->\n<p></p>\n<!-- /wp:paragraph --></div>\n<!-- /wp:column --></div>\n<!-- /wp:columns -->\n<!-- /wp:acf/section -->",
	)
);

While testing this new feature, I've found a problematic issue with the included ACF block id "id\":\"block_5eccdfd5dfb2d\".

If I use a pattern which includes an ACF blocks, the block id is always the same --> Also if I use this pattern/block multiple times. So I get multiple ACF blocks with the same block id. This is very confusing. Because, if I change a setting by this ACF block --> The changed setting is also applied to all other ACF blocks, which are included by this pattern.

This happens, because the block id is the same for all ACF blocks, which are included by the pattern.

How we/you can solve this issue to generate automatically a new block id for each ACF block?

[CreativeDive]

In another case, if I duplicate the block with the gutenberg toolbar, the block id has been automatically changed.

[CreativeDive]

@elliotcondon a workaround is to remove the ACF block id from the pattern like the following example:

register_block_pattern(
	'wphave/footers-pattern-02',
	array(
		'title'   => __( 'Footer', 'wphave') . ' ' . __( 'Example', 'wphave') . ' 2',
		'content' => "<!-- wp:acf/section {\"id\":\"\",\"name\":\"acf/section\",\"data\": ...

If the block id is empty wp:acf/section {"id":"", ... inside the pattern, it works perfect. After adding this pattern with an empty block id to the editor, a new block id has been automatically generated. So my changed setting is unique also if I use this same pattern multiple times.

But is this the correct way to remove the block id from the pattern?

[elliotcondon]

Hi @CreativeDive

Thanks for the topic. Yes, you're instinct to remove the "id" attribute was correct.

Each block within the post_content should contain a unique "id" value, and any kind of template such as "patterns" or "examples" should not.

The "id" is used by ACF to setup and scope the "data" when using template functions such as get_field(). You can think of the "id" attribute as a Post ID. Each Post contains a unique ID and can be used to load / save content.

I'll add this to our to-do list - to perform testing with the upcoming Patterns library 👍

[nick6352683]

These are my finding - (Conclusion - this is NOT an issue for me...)

Tested with:

1. ACF 5.8.11, Gutenberg 8.2 (released just today).
2. ACF 5.9 Beta 1, Gutenberg 8.2

Adding 2 of the same patterns it is true that both patterns start with the same block Ids. HOWEVER, the moment I make any changes to any of the blocks (save the page and refresh by going on the front end and editing the page again), the block ID changes automatically, therefore I CAN NOT have a situation where I make changes to one pattern, and those changes reflect on the other (pattern).

I can verify the block ID changes by going from the visual view to code view in the editor, before and after I make any of the changes in the patterns.

Could it be that Gutenberg 8.2 fixed this issue if it existed to begin with? I don't know, and at this point we should not really care either, unless I'm missing something...

@CreativeDive and @elliotcondon can you please test and confirm my findings so we can safely move away from this issue?

Thanks,
Nick.

[CreativeDive]

@nick6352683 Currently I can't say more about it. I work with the latest release of WordPress, because ACF innerBlocks dosen't work with the latest Gutenberg release. So I can say more about it, if ACF 5.9 beta supports the innerBlocks in newer Gutenberg releases.

[elliotcondon]

Replying to #301 (comment) by @nick6352683

Thanks for jumping into this ticket, but I don't believe there is anything that requires investigation.

As mentioned, each block within the post_content should contain a unique "id" value, and any kind of template such as "patterns" or "examples" should not.

Please be aware this is not a bug, but something that should be better documented.

[elliotcondon]

Replying to #301 (comment) by @CreativeDive

I can confirm that issue #297 has been fixed, and will be included in the 5.9.0-beta2 release.

Additional, I've just sent you an invite to join the ACF PRO private GitHub repository. There, you will find a branch named "feature/release-5-9". Please pull down the latest code from this branch and let me know how you go 👍

[CreativeDive]

@elliotcondon Thanks for sending an invite to join the ACF PRO private GitHub repository. I've installed the "feature/release-5-9" branch, but everything breaks.

So I've installed the latest 5.9 beta from the ACF website and the issue is still there :-(

If I installed the ACF 5.8.11 everything works perfect. What's wrong here?

[CreativeDive]

@elliotcondon I can see you have modified this file: https://github.com/AdvancedCustomFields/acf-pro/commit/03b64bb9db3c7d72008bcc08581a1f8004f5b239

But it seems this dosen't work correct.

[elliotcondon]

Hi @CreativeDive. Can you try hard-refreshing your browser to clear cached assets? I suspect the acf.refresh() function is missing due to an older cached version of the file.

[CreativeDive]

@elliotcondon Yes, really. My bad this was a browser cache issue :-D Now I can confirm, innerBlocks working with the latest 8.2 Gutenberg release :-)

[gaambo]

I just found this issue on one of my clients sites: If you copy a block from another post the ID is not updated as well, so changing field values does not work (or it does work but they are not displayed/output on the frontend). I'm seeing a similar issue with GenerateBlocks, so I am not sure if it's a Gutenberg issue or a plugin issue, probably depending on how the id is generated.
Version Infos: ACF Pro 5.9.3, WordPress 5.5.3, no Gutenberg plugin

EDIT: This was while inserting a reusable block and converting it to a normal block.

[magicbyt3]

not sure if this is related however I noticed that fields inside my blocks are readonly when I add them among a gutenberg pattern and I am not sure what's causing this. Once I save the post and reload gutenberg all blocks inside the pattern continue to work as expected. I noticed they get aria-role="readonly" for select fields and disabled for input fields set. Any idea what could cause this?

[elliotcondon]

Thanks @p13rnd. This is a known issue we have identified here:

• https://github.com/AdvancedCustomFields/acf-pro/issues/930
• https://github.com/elliotcondon/acf/issues/794

[magicbyt3]

Hi Elliot,

okay I thought so after going wild with hook orders a bit 🗡️
Anything I can help to debug this please let me know.

Cheers,
p13

[pinksharpii]

I'm trying to add an ACF block to a Pattern and running into this same issue - even if I take out all the attributes (id, align, mode, etc) it still shows as read-only until the page is saved and refreshed.

[nicmare]

Is this fixed with 5.10 ?

[nick6352683]

No it's not fixed, just checked with 5.10.1 .

[MarcGuay]

Seems to be fixed in 5.10.2

[lgladdy]

We did fix this in 5.10.2 :) Thanks for the report!

[jweston491]

I ran into this issue today with 5.12.3. It happens when you copy a block from the code editor and paste it into another post. So I'm not sure if that is part of the scope of this issue, or technically a separate issue.

[AlkoKod]

I am not sure if this is fixed, because I encountered it just today with ACF 6.2.2. When I Duplicate the block within the page - the content and ID's remain same - content is fine, but ID's is wrong.

How to fix this?

[lgladdy]

Legacy Block IDs no longer exist inside ACF. When a block is first updated after updating to 6.0, its block ID will be removed and generated from a hash of the settings and field data.

If you duplicated a block before editing it, it may have the previous behaviour, but any edits to it will trigger the block ID change.

[AlkoKod]

You are right, when you duplicate it only, ID's remain same, when I change something, ID changes. So If I need same button multiple times, I should always change it's text, or use reusable block - thats hard for mine users, who are not really IT guys.

[lgladdy]

If a block's contents are exactly the same, ACF will see them as the same block ID yeh - but our internal block IDs are not meant to be unique, they're designed for our cache system, so if a block is functionally identical, we want the ID to be the same.

If you need a unique block ID for some reason, there are some possible workarounds we've included in the 6.0 release notes

[AlkoKod]

If a block's contents are exactly the same, ACF will see them as the same block ID yeh - but our internal block IDs are not meant to be unique, they're designed for our cache system, so if a block is functionally identical, we want the ID to be the same.

If you need a unique block ID for some reason, there are some possible workarounds we've included in the 6.0 release notes

Ok, thanks for explanation Liam, I really appreciate it.