Hi,
I’m just testing the WP 6.8 update and noticed the following error:
acf-pro-blocks.min.js?lfr=Ni40LjAuMQ%3D%3D:1 Uncaught TypeError: Cannot read properties of undefined (reading 'attributes')
at E (acf-pro-blocks.min.js?lfr=Ni40LjAuMQ%3D%3D:1:25129)
at Array.map (<anonymous>)
at acf-pro-blocks.min.js?lfr=Ni40LjAuMQ%3D%3D:1:40591
at o (acf.min.js?lfr=Ni40LjAuMQ%3D%3D:1:1403)
at Object.doAction (acf.min.js?lfr=Ni40LjAuMQ%3D%3D:1:573)
at n.doAction (acf.min.js?lfr=Ni40LjAuMQ%3D%3D:1:14776)
at post-new.php?post_type=page:2472:5
This is coming from this bit of code:
const u = wp.blocks.registerBlockType(t.name, t);
return u.attributes.anchor && (u.attributes.anchor = {
type: "string"
}),
registerBlockType has a return type of
WPBlockType | undefined: The block, if it has been successfully registered; otherwise undefined
Seems like something changed in 6.8 making the block registration fail in JS.
None of my custom blocks are registered after the update. I’m using the latest ACF PRO version (6.4)
Yes, I’ve got the same error!
This happens on ACF blocks where the (core) anchor attribute is not even set?
Downgrading to WordPress 6.7.2 is the only way to fix it.
This is unrelated to the anchor attribute itself. The registerBlockType function/method fails and returns undefined. After that, accessing attributes throws an error because it’s undefined. Without a deep dive my guess is creating the block structure in JS is not correct anymore.
Here’s what’s working for me so far:
- Update
acf-composer to 3.4.3+ – Fixes the “no support for this block type” issue.
- Update ACF to 6.4.0.1+ – Fixes the “called too early” warning
(h/t to Michiel van Harten via Roots Discord)
Extra credit:
ACF blocks with a default alignment will no longer output alignment classes (.alignwide, .alignfull) if $supports['align'] is set to false.
Previously, this setup would apply the default alignment while hiding the alignment control in the editor UI.
Now, setting $supports['align'] to false fully disables alignment support, including outputting alignment classes.
To fix this, update affected blocks to specify at least one alignment option in $supports['align'].
AFAICT, the issue is that parent must now be an array or undefined. I was hit by this bug because I passed 'parent' => null to acf_register_block_type().
https://github.com/WordPress/gutenberg/blob/7506dbbe49367f0641d339473b4416f579bc9376/packages/blocks/src/store/process-block-type.js#L216
Thanks @contactstefanfisk-com! I was defaulting to null as well, conditionally adding the parent setting made my blocks show up again.
I would like to update acf-composer to 3.4.3+ to fix these no support for this block type issues, however I can’t since I then also need to upgrade Acorn v2 to v3 and that’s not an option for me right now since it’s an older theme.
Therefore I need to stay on acf-composer 2.1. Is there no other way to fix this? I don’t have $parent defined in any of my acf blocks?
I can’t upgrade to wordpress 6.8 because of this?
One of the blocks that doesn’t get registered anymore has the following attributes:
public $supports = [
'align' => false,
'align_text' => false,
'align_content' => false,
'anchor' => false,
'mode' => true,
'multiple' => true,
'jsx' => true
];
And fails on this line in plugins/advanced-custom-fields-pro/assets/build/js/pro/acf-pro-blocks.min.js?ver=6.4.0.1 with error Cannot read properties of undefined (reading 'attributes'):
return u.attributes.anchor && (u.attributes.anchor = {
type: "string"
}),
Same here,
On Acorn 2.1 but the upgrade path looks shaky
Appreciate any insight
LINE 274 of vendor/log1x/acf-composer/src/Block.php …
Changed ‘parent’ => $this->parent ?: null,
to
‘parent’ => $this->parent ?: [],
and everything works again.
Not ideal of course to go editing vendor files but I don’t know how to patch them “correctly”
Presume some script can be created in composer file to apply such a patch?
If anyone can advise, I’d appreciate it
Strangely – my Block class has public $parent = []; defined in it
– but this doesnt cut it
I would be under the assumption that this was considered “set” as therefore the the test $this->parent wouldn’t fail and return null.
… Alas, an empty array tests false so presumbly we need to pop something in there?
Was hoping i could just override the compose() method in my class but no such luck
There’s a new version of acf-composer 2.1.x that will address this issue while remaining on Acorn 2.
https://github.com/Log1x/acf-composer/releases/tag/v2.1.1
Thanks @joshf, I can confirm this fixed the issue for me!
Holy cow chaps. Highly grateful for this action.
I promise my next project will be a fresh build based off acorn 3 and the latest sage.
Does anyone know of a recommended upgrade path to apply to existing acorn/sage projects ?
Or rather a recommended good form for building
I spent a fair bit of time constructing my personal boilerplate to kickstart a project & whilst I’m happy to reconstruct it (& accept theres always a benifit to a fresh start) – it would be great to approach it with a mindset of long term maintainability & adopt any new features bought by latter versions of acorn/sage.
I suppose theres not much way of being certain how the future itterations will be structured though.
+1 Confirmed works.
Thanks again
Sorry to bother —
Whilst my existing blocks are now visible, Im not longer able to insert new blocks of existing types, with the error “Block X can;t be inserted”
@twansparant – can you confirm this the same for yourself?
Suspect similar updates may need to be applied to some js as console is reading
deprecated.js?ver=741e32edb0e7c2dd30da:115 wp.editPost.PluginBlockSettingsMenuItem is deprecated since version 6.6. Please use wp.editor.PluginBlockSettingsMenuItem instead.
deprecated @ deprecated.js?ver=741e32edb0e7c2dd30da:115Understand this warning
deprecated.js?ver=741e32edb0e7c2dd30da:115 wp.editPost.PluginDocumentSettingPanel is deprecated since version 6.6. Please use wp.editor.PluginDocumentSettingPanel instead.
Hi @cosystudios,
Yes indeed, I can confirm I’m having the same Block X can't be inserted error now…
Haden’t noticed that yet.
Thanks man – good to know its not localised to my setup/config.
Currently somewhat lost as to what the issue is here though.
I’ve tried created a fresh “wp acorn acf/Block TestBlock” to be certain the issue isn’t just existing blocks and can confirm a new test block was also erroneous
@cosystudios @twansparant Have either of you had any luck resolving the “Block ‘block-name’ can’t be inserted” issue?
The 2.1.1 acf-composer hotfix resolved the block rendering problem, but I’m still seeing several issues:
- Unable to add new blocks
- Copy/paste doesn’t work
- Mini search doesn’t return blocks by name
Appreciate any insights—thanks in advance!
@bisonbrah No I’m afraid not…
I don’t see any console errors in the admin and I don’t see any PHP error logs.
Just the toast message:
Block "Block Name" can't be inserted.
It happens on blocks where I have $parent defined as:
public $parent = [];
but also on blocks where I haven’t defined $parent at all?
See topic: https://github.com/Log1x/acf-composer/issues/340
@bisonbrah & @cosystudios
The latest version 2.1.2 fixes the Block ‘block-name’ can’t be inserted issue!
https://github.com/Log1x/acf-composer/releases/tag/v2.1.2
FYI I think WP Engine released a fix for this in the latest version (6.4.2).
From the release notes:
Fix – Blocks registered via acf_register_block_type() with a parent value of null no longer fail to register
