Inserter: Fix Block visibility manager #65700
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
youknowriad
added
[Type] Bug
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
|
Size Change: +831 B (+0.05%) Total Size: 1.77 MB
ℹ️ View Unchanged
|
t-hamano
reviewed
Sep 27, 2024
There was a problem hiding this comment.
For example, even if I hide all blocks in the Text category via "Manage block visibility", only the List item block will be displayed in The text category in the inserter. This happens with other categories as well. I think this is because the Block Manager filters out blocks that have parents.
This behavior seems a bit strange, but what do you think?
I agree, It seems if the blocks that have a "parent" block are not allowed, their children shouldn't be allowed either. |
|
It should be fixed now. |
|
It seems like e2e tests and unit tests are failing. Maybe it has to do with the logic in |
|
This should be ready now. |
huubl
pushed a commit
to huubl/gutenberg
that referenced
this pull request
Oct 2, 2024
Co-authored-by: youknowriad <youknowriad@git.wordpress.org> Co-authored-by: t-hamano <wildworks@git.wordpress.org>
huubl
added a commit
to huubl/gutenberg
that referenced
this pull request
Oct 2, 2024
This reverts commit d83720c.
draganescu
pushed a commit
that referenced
this pull request
Oct 2, 2024
Co-authored-by: youknowriad <youknowriad@git.wordpress.org> Co-authored-by: t-hamano <wildworks@git.wordpress.org>
2 tasks
oandregal
reviewed
Oct 18, 2024
|
|
||
| // If parent blocks are not visible, child blocks should be hidden too. | ||
| if ( !! blockType.parent?.length ) { | ||
| return blockType.parent.some( |
There was a problem hiding this comment.
At this point, how do we know blockType.parent is an array? Can't it be a string, for example, that also has a length property?
For context, I'm looking at an issue in the support forum that I believe to be related to this check: the report is recent, the users report issues when inserting blocks, and there's no other place in the codebase that uses parent.some.
There was a problem hiding this comment.
Looking at the block registration, it seems parent should be null or an array, but we don't enforce that.
Even the recently added logic to block registration doesn't check that parent is an array. This:
if (
1 === settings?.parent?.length &&
name === settings.parent[ 0 ]
) { /**/ }would still be fine for blocks that register parent as a string.
There was a problem hiding this comment.
One thing we can do to fix this is to make the if check above explicit for what we want to do: verify that it is an array and that it has elements.
The more general question is: how parent can become an array? Are block authors mis-registering this property? Can we now enforce it being an array?
There was a problem hiding this comment.
Even the recently added logic to block registration doesn't check that parent is an array.
Regarding this conditional statement, I suggested a change in this comment. However, I noticed that, unlike my comment, the order of each conditional was reversed when it was merged, which is certainly not what was intended.
There was a problem hiding this comment.
cc @gziolo for thoughts about enforcing the blockType.parent being an array at registration. Would that be feasible?
There was a problem hiding this comment.
We are discussing it in this thread: #66234 (comment). The short answer is if we know that block types were registered with the parent set to a string, the best way would be to respect that and provide a fallback handling.
This was referenced Oct 18, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Closes #65687
What?
In #65490 we changed a bit how the inserter works by avoiding any initial block type filtering and only upon insertion figuring out what things can or can't be allowed in a given position and also try to guess a more suitable position.
The problem is that in some situations (block visibility managed, allowed blocks settings), it doesn't really make sense to show the blocks at all. So this PR separate the
canInsertBlockselector into two:Note
For child blocks, I elected for now to keep them in the inserter. The reason is that there's value in that, for instance, if you're within a nested block within a column, it's handy to be able to click "column" block to insert a new column in the parent's columns block. We can revise/tweak that behavior if it's deemed too problematic.
Note that the PR applies the fix to the pattern inserter too.
Testing Instructions
1- Open the post inserter
2- Go to preferences > blocks and remove the "heading" block
3- Open the inserter and notice the block is not visible anymore and any block that uses the block is not either.