Conflict with ACF; last block added never renders

[smerriman]

• I've read and understood the contribution guidelines.
• I've searched for any related issues and avoided creating a duplicate issue.

Please give us a description of what happened.

Previously I posted a major bug report where ACF default values were lost when Yoast SEO was active.

I haven't tested that recently, though now the situation appears to have gotten completely worse - the last ACF block you add to a page now appears to get entirely lost.

How can we reproduce this behavior?

1. Clean WP 5.6 install with Twenty Twenty theme, ACF PRO and Yoast SEO plugins
2. Add the following to functions.php:

add_action('acf/init',function() {
	acf_register_block_type(array(
		'name'=>'testblock',
		'title'=>'Test block',
		'description'=>'Test block',
		'category'=>'common',
		'mode'=>'preview',
		'render_callback'=>function() {
			echo '<p>Hi, I am a block</p>';
		}
	));
});

3. Create a new page, insert test block.
4. Immediately switch to code editor. You should see:

<!-- wp:acf/testblock /-->

with all of the important details that ACF adds like block ID missing.

5. Publish the page, and you won't see any output on the front end.
6. Return to the editor, and add a second test block.
7. Back to the code editor; the first block has the right parameters, and the second is broken. Publish, and you'll see the block appearing only once.

None of this happens when Yoast SEO is not installed.

Technical info

Used versions

• WordPress version: 5.6
• Yoast SEO version: 15.7
• Relevant plugins in case of a bug: ACF PRO 5.94 (likely occurs with free version too, untested)
• Tested with theme: TwentyTwenty

[smerriman]

(Sorry, accidentally @mentioned the wrong thread about ACF, which I've edited to fix).

[Djennez]

I can confirm this is happening, though like with the other issue; I can't easily find what causes this.

Since it's functionality of ACF that is breaking here, I'd recommend posting these bugs to their issue trackers as well, as they might have an easier time determining what breaks here. And if it's something unconventional that the Yoast plugin does, we'd very much like to know so that we can look into it. However, it might as well be something that ACF needs to fix on their end.

[smerriman]

Have done some more debugging and it's definitely an issue on Yoast SEO's side.

When ACF registers a block with registerBlockType, it uses a save function which adds the appropriate attributes to the code that should be in the editor. I added a console.log to this save function.

I also added a console.log line to the core WP function serializeBlock.

With Yoast SEO deactivated, this save function does not run immediately when I insert the block. Nothing outputs in the console until I interact with the page a bit further (eg clicking on a second block, switching to the code editor, or hitting publish).

With Yoast SEO activated, it runs the instant I add the test block, and serializeBlock has empty attributes at that point (since the block has not called its save function).

Something in Yoast SEO is resulting in block serialization occurring too early, and will affect not just ACF but any custom block with a custom save function.

[elliotcondon]

@smerriman - Great work debugging the issue so far 👍.

@Djennez - Is it possible that YoastSEO is applying custom logic either via a JS filter or React Component that could cause a block to save at a different / early time?

[Djennez]

@elliotcondon as far as I was able to determine we don't. I also don't see any earlier save request in the requests to the server. I see the fetch block request happening, but acf_ajax_fetch_block()always returns the same response (with Yoast on or off) so I stopped looking there.

[smerriman]

As mentioned above, this isn't caused by requests to the server.

Replace wp-includes/js/dist/blocks.min.js with the unminified version, and then add a logging statement to the serializeBlock function like I did above. You'll see exactly the same results as described - with Yoast deactivated, the logging call doesn't happen when the block is inserted (the editor is apparently set to some 'dirty' state, so serialization only happens later). With Yoast activated, it runs instantly, the editor gets the wrong content, and apparently isn't set to a dirty state so it doesn't update until you 'dirty' it in some other way (eg inserting a different block).

[smerriman]

@elliotcondon I think I may know what's going on here - while Yoast SEO is doing something that changes the timing of serialization, the "bug" may indeed be on ACF's side.

I see that you are adding the block ID (which everything is based on) via the editor.BlockListBlock filter and the ACF function withDefaultAttributes. In another thread you referred to having to do the same thing for setting the default 'alignment' state, and got the following reply:

WordPress/gutenberg#7342 (comment)

An issue you may encounter in this implementation is that you're mutating the attributes object directly, rather than going through the store's actions (e.g. wp.data.dispatch( 'core/editor' ).updateBlockAttributes). This could result in some subtle unexpected behaviors as the editor won't necessarily be immediately aware of the change in attribute value and the impact this should have on various behaviors (e.g. is saveable, is dirty, undo history, etc).

So without Yoast SEO, this 'subtle unexpected behavior' never gets noticed, since it happens to trigger the update to the block ID as a side effect shortly afterwards. But whatever Yoast SEO is doing means the block is first serialized without the block ID, and now the unexpected behavior is severe, because the 'is dirty' state isn't triggering, so the block ID never gets added unless you make another change elsewhere in the editor.

[elliotcondon]

@smerriman Interesting... this could indeed be a part of the puzzle. From here, I'll need to perform some debugging work to isolate the issue. Under normal circumstances, I could give you an ETA, but we are quite busy right now with some upcoming projects and other bug fixes. Please leave this with me and I'll hope to have some answers shortly.

[smerriman]

Thanks. This wasn't happening late last year, so I'm guessing the change on Yoast's side was relatively recent - but since most sites use it, you'll probably start getting the bug reports streaming in (given it affects every single ACF block). For now the only way I can build sites is to disable Yoast SEO while creating everything in the editor.

[changalanggg]

As an additional FYI, I'm having a similar issue with ACF, except in my case, all my ACF blocks do render both in the editor and on the page except ACF blocks that don't have any custom input fields, e.g., a code-only image separator. These non-input ACF blocks can be added to the editor, but don't appear on the page after saving.

However, once any input block is added after the non-input block - either above or below, it doesn't matter - the non-input block appears.