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

Default paragraph block ignoring allowedBlocks parameter when searching for blocks #64411

Closed
2 tasks done
ssang opened this issue Aug 10, 2024 · 2 comments · Fixed by #64413
Closed
2 tasks done

Default paragraph block ignoring allowedBlocks parameter when searching for blocks #64411

ssang opened this issue Aug 10, 2024 · 2 comments · Fixed by #64413
Labels
[Status] In Progress Tracking issues with work in progress [Type] Bug An existing feature does not function as intended

Comments

@ssang
Copy link
Contributor

ssang commented Aug 10, 2024

Description

Not sure what changed to cause this but when a block allowed for the core/paragraph block and you use the / shortcut to type and insert other blocks, it used to only show the blocks that were available to the parent block. It doesn't allow for you to actually insert the block but you're able to view it in the list that is generated. From what I can tell, I get a list of blocks that don't explicitly define any allowable parents.

When you use the appender to open the block selector popup, you still see only the allowedBlocks

Step-by-step reproduction instructions

  1. Create a block that allows for a subset of blocks including the core/paragraph block as child blocks
  2. Insert the paragraph block
  3. Type / to start searching for other blocks
  4. A list of all blocks that don't match the subset set in allowedBlocks seems to show up

Screenshots, screen recording, code snippet

WordPress Version 6.5

image

WordPress Version 6.6.1

image

Environment info

I have a customized hybrid theme setup so it could be a compatibility issue on my part but I just don't see what could have changed to cause this and what I need to do to fix it. I've tried with the Gutenberg plugin as well to see if it's been fixed since but no luck.

Please confirm that you have searched existing issues in the repo.

  • Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

  • Yes
@ssang ssang added the [Type] Bug An existing feature does not function as intended label Aug 10, 2024
@ssang
Copy link
Contributor Author

ssang commented Aug 10, 2024

I've pinpointed it down to the Gutenberg version 18.5.0

Possibly related to this PR #62169

@ssang ssang changed the title Default block ignoring allowedBlocks parameter when searching for blocks since 6.6 Default paragraph block ignoring allowedBlocks parameter when searching for blocks since 6.6 Aug 10, 2024
@ssang ssang changed the title Default paragraph block ignoring allowedBlocks parameter when searching for blocks since 6.6 Default paragraph block ignoring allowedBlocks parameter when searching for blocks Aug 10, 2024
@github-actions github-actions bot added the [Status] In Progress Tracking issues with work in progress label Aug 10, 2024
@ssang ssang removed their assignment Aug 10, 2024
@talldan
Copy link
Contributor

talldan commented Aug 13, 2024

Thanks for reporting this, and especially for making a PR!

In terms of core blocks, I can also reproduce the issue in the navigation block (possibly others, I stopped at the first one I found):
Screenshot 2024-08-13 at 1 31 31 PM

A lot of these blocks are not allowed in navigation and trying to insert one of them results in nothing happening. I'll give your PR a test and review, it might also be a fix to ship in the upcoming WordPress 6.6.2 given the fix is so tiny and the bug is quite bad. (though I need to check that it's an issue in 6.6.1 first)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Status] In Progress Tracking issues with work in progress [Type] Bug An existing feature does not function as intended
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants