You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current approach to allowing critical core blocks is via a hardcoded map. There is a way to access the allowedBlocks property in the innerBlocks using the following command:
This issue was brought up by a VIP customer on a recent call. They are hooking into the setDefaultBlockName function from @wordpress/blocks module. Perhaps this is another method to determine what core blocks are auto-inserted.
In this client's case, they are replacing the core paragraph block with a custom block, making our hard-coded map problematic.
The current approach to allowing critical core blocks is via a hardcoded map. There is a way to access the allowedBlocks property in the innerBlocks using the following command:
wp.data.select( 'core/block-editor' ).getAllowedBlocks('49abcad4-4be5-46d0-8db5-44760f15e0e7')
Using this in code causes a call stack exceeded. If this works, this would be a better solution long term.
The text was updated successfully, but these errors were encountered: