-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Avoid confusion around blockTypes/allowedBlockTypes/enabledBlockTypes setting #6069
Conversation
Having this argument optional implies that it's safe to not provide one, when in reality that will probably result in a bug.
Using the same name for this feature throughout the codebase will hopefully help developers search for it and better understand it.
cc. @brandonpayton |
return null; | ||
} | ||
|
||
const blockTypeIsDisabled = Array.isArray( enabledBlockTypes ) && ! includes( enabledBlockTypes, 'core/block' ); | ||
const blockTypeIsDisabled = Array.isArray( allowedBlockTypes ) && ! includes( allowedBlockTypes, 'core/block' ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unrelated to this PR, but I wanted to double check if we need to open another issue. Shouldn't this logic verify whether core/block
isn't allowed, but also referencedBlockType.name
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In my opinion, disabling core/block
should prevent you from inserting all shared blocks, but I could be persuaded otherwise. Let's discuss in #5893.
|
||
return { | ||
hasSupportedBlocks: true === blockTypes || ! isEmpty( blockTypes ), | ||
hasSupportedBlocks: true === allowedBlockTypes || ! isEmpty( allowedBlockTypes ), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since this line is updated. It can be simplified to:
hasSupportedBlocks: ! isEmpty( allowedBlockTypes )
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very confusingly for us PHP folks, _.isEmpty()
doesn't work the same way as empty()
:
$ node
> var _ = require('lodash');
> _.isEmpty(true)
true
> _.isEmpty(false)
true
Sharing for a reference from https://wordpress.org/gutenberg/handbook/extensibility/extending-blocks/#hiding-blocks-from-the-inserter:
I like the changes introduced in this PR 👍 |
export function getInserterItems( state, allowedBlockTypes ) { | ||
if ( allowedBlockTypes === undefined ) { | ||
allowedBlockTypes = true; | ||
deprecated( 'getInserterItems with no allowedBlockTypes argument', { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Both depreciation messages should be also added to https://github.com/WordPress/gutenberg/blob/master/docs/deprecated.md for better visibility.
Quick cleanup that does two things.
First, it makes the
enabledBlockTypes
argument ingetInserterItems
andgetFrecentInserterItems
non-optional. I regret making this optional since it implies that not providing this argument is a sensible thing to do, when in reality it would cause subtle bugs, e.g. a user could insert a block that has been disabled via theallowed_block_types
filter.Since selectors are exposed publicly now, I added a deprecation warning so as to avoid breaking backwards compatibility. Let me know if you think that's overkill.
Secondly, I noticed that we refer to this array of allowed block types throughout the codebase as either
blockTypes
,allowedBlockTypes
orenabledBlockTypes
. I've renamed these variables so that we are always referring to this array asallowedBlockTypes
, which matches the name of the filter.How I tested this
lib/load.php
: