Handle innerContent too when removing innerBlocks #46377
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What?
Fixes #46371
Alternative to #46374
Why?
In #46374 we're adding one item but we're appeasing the system to not throw a fatal error, instead of making it behave as we expect. In this PR the behavior is as expected.
How?
In our filtering function
block_core_navigation_filter_out_invalid_blocks
if one of the innerBlocks is not in the allowed list we set the parent'sinnerBlocks
to[]
. This triggers a fatal error inWP_Block
because it has a conflict in the parsed block between theinnerBlocks
being[]
andinnerContent
still retaining the old shape, e.g. for a social links block with a filtered social linkbecause of this we get into a spiral that ends in the fatal error.
This PR sets
innerContent
to be a string by imploding the array above. If there are no inner blocks we only care about the empty parent block.Caveat
Manually unsetting
innerblocks
like we do in the navigation block (set to[]
) is "off label" use of how blocks expect to be dealt with. We either find a nice way to remove a block from the rendering process, or we will probably hit other problems if the navigation block becomes even more complex.The case we seem to prevent at render time should not exist if the block was created in the editor, in other words allowed blocks in the editor should not be repeated in the rendering function b/c no unallowed block should be there. Generally we treat content input manually e.g. via code view "as is". The exception here is that in #46279 a possibility for infinite loop was identified - most likely via manual editing.
Conclusion
My opinion is that we should revert #46279 and not merge neither this or #46374. We should maybe add a safeguard to avoid infinite nesting my adding a max nesting a la react, silently error and not render anything.
Testing Instructions
Testing Instructions for Keyboard
N/A
Screenshots or screencast
N/A