Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handle innerContent too when removing innerBlocks #46377

Merged
merged 1 commit into from
Dec 7, 2022

Conversation

draganescu
Copy link
Contributor

@draganescu draganescu commented Dec 7, 2022

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's innerBlocks to []. This triggers a fatal error in WP_Block because it has a conflict in the parsed block between the innerBlocks being [] and innerContent still retaining the old shape, e.g. for a social links block with a filtered social link

["innerContent"]=>
  array(3) {
    [0]=>string(35) "<ul class="wp-block-social-links">"
    [1]=>NULL
    [2]=>string(6) "</ul>"
  }

because 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

  1. Add a navigation block
  2. Add some navigation links
  3. Add a social links block
  4. Add a social link
  5. Save and publish
  6. Check the front end
  7. The social links block should not render but there should be no PHP error

Testing Instructions for Keyboard

N/A

Screenshots or screencast

N/A

@draganescu draganescu added [Type] Bug An existing feature does not function as intended [Block] Navigation Affects the Navigation Block labels Dec 7, 2022
@draganescu draganescu marked this pull request as ready for review December 7, 2022 18:25
@draganescu draganescu changed the title handle innerContent too when removing innerBlocks Handle innerContent too when removing innerBlocks Dec 7, 2022
Copy link
Contributor

@ajlende ajlende left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This fixes the page from erroring out completely, but we also need the allowed blocks from #46374

I'll open a PR shortly for reverting the recursive change. I think it's important for the quick fix to go in, and then we can continue discussion on the new PR.

@ajlende ajlende merged commit 181b383 into trunk Dec 7, 2022
@ajlende ajlende deleted the fix/fatal-error-rendering-navigation branch December 7, 2022 21:12
@github-actions github-actions bot added this to the Gutenberg 14.8 milestone Dec 7, 2022
ajlende pushed a commit that referenced this pull request Dec 7, 2022
@getdave
Copy link
Contributor

getdave commented Dec 8, 2022

I think it's important for the quick fix to go in, and then we can continue discussion on the new PR.

Thank you for being pragmattic in the approach to merging to fix the initial problem 🙇

scruffian pushed a commit that referenced this pull request Dec 8, 2022
* Revert "Handle innerContent too when removing innerBlocks (#46377)"

This reverts commit 181b383.

* Revert "Add social link singular to list of blocks to be allowed (#46374)"

This reverts commit 394590b.

* Revert "Recursively remove Navigation block’s from appearing inside Navigation block on front of site (#46279)"

This reverts commit afc8b42.

* Refactor ul code for readability

* Refactor li wrapper conditional

* Prevent rendering nav refs that have already been seen

* Fix PHP lint
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Block] Navigation Affects the Navigation Block [Type] Bug An existing feature does not function as intended
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Navigation: Social Icons block doesn't work in the navigation block
3 participants