Request a hook that can change the default value of the block manager.

[shimotmk]

Hi there.

What problem does this address?

I want to change the default value of the block manager.
I want to change the default value of the block manager instead of turning off block registration with unregisterBlockType, etc.
because we want to leave the ability to turn off blocks to the user.

It turns out that you can add a hide block by specifying it like this.

const hideBlockArray = [ 'core/heading','core/quote','core/table'];
wp.data.dispatch('core/edit-post').hideBlockTypes(hideBlockArray)

However, this will restore the turned off blocks when reloading assuming they are turned on.

block.manager.mov

What is your proposed solution?

defaultAllowedBlockTypes

gutenberg/packages/edit-post/src/components/block-manager/category.js

Line 23 in b6c79fe

const { defaultAllowedBlockTypes, hiddenBlockTypes } = useSelect(

Could you please add a filter hook here?
That would help the custom block developer by allowing him to change the default values.

Thank you.

[talldan]

@shimotmk Would you be able to share some more information on what your use case is for making a block hidden by default? Is this to hide core blocks or other blocks?

I think you can already filter allowedBlockTypes using the block editor settings filters:
https://developer.wordpress.org/block-editor/reference-guides/filters/editor-filters/#block_editor_settings_all

defaultAllowedBlockTypes is an internal value derived from allowedBlockTypes.

[shimotmk]

@talldan
Thanks for the reply!
Indeed, I was able to restrict the selection to only that block by running the following code.

function filter_block_editor_settings_when_post_provided( $editor_settings, $editor_context ) {
	if ( ! empty( $editor_context->post ) ) {
		$editor_settings['allowedBlockTypes'] = array( 'core/heading','core/quote', 'core/table');
	}
	return $editor_settings;
}
add_filter( 'block_editor_settings_all', 'filter_block_editor_settings_when_post_provided', 10, 2 );

But what I want to do is change the default value of the block manager.

The use case is that I want to use it to deprecate custom blocks as Gutenberg evolves.
I know there are ways to deprecate it, such as using the hooks mentioned above or setting inserter to false, but I want to use the block manager to turn it on in case some users want to use the block.

[talldan]

My understanding of defaultAllowedBlockTypes is that it achieves the same thing as allowedBlockTypes so that may not help.

But what I want to do is change the default value of the block manager.

I think this is a little tricky to achieve with how the block manager is implemented right now. Currently, there's a hiddenBlockTypes array that contains the names of any blocks that are hidden. e.g.

const hiddenBlockTypes = [ 'core/table' ];

If it were possible to provide a default, it might look something like

const defaultHiddenBlockTypes = [ 'core/table', 'core/quote' ];

But a user making one of those defaults visible means removing it from the hiddenBlockTypes array. core/quote is already not there though, so I don't see how it could work.

Let me know if you have any ideas.

[shimotmk]

@talldan
Thanks for the reply.

It is still difficult with the current code.
As I wrote in the first

const hideBlockArray = [ 'core/heading','core/quote','core/table'];
wp.data.dispatch('core/edit-post').hideBlockTypes(hideBlockArray)

to be executed only once when the block editor is displayed.

[talldan]

The underlying data for hidden blocks was recently rearranged a bit and moved to the core/preferences store (the hideBlockTypes action still works though).

That store does have an API for defaults:

wp.data.dispatch( 'core/preferences' ).setDefaults( 'core/edit-post', 'hiddenBlockTypes', [ 'core/heading','core/quote','core/table'] );

But this default is only applied when hiddenBlockTypes is undefined (when a user hasn't interacted with the block manager at all). As soon as a user toggles a single block in the block manager, none of those defaults would apply any more. The code for that is here:

gutenberg/packages/preferences/src/store/selectors.js

Lines 11 to 14 in f2124de

	export function get( state, scope, name ) {
	const value = state.preferences[ scope ]?.[ name ];
	return value !== undefined ? value : state.defaults[ scope ]?.[ name ];
	}

It wouldn't work the way you want it to, but it'd be nice if this existing API did work. I haven't been able to think of a way to do that.

BTW, no need to close the issue, it can stay open while we continue to think about options.

[shimotmk]

@talldan
Thanks for the reply.

I see...
You made some changes around here.
#31965

setDefaults is a very nice function!

The issue is open. Looking forward to seeing the functionality added!

[studionenontwerp]

Seems to me that
wp.data.dispatch( 'core/edit-post' ).hideBlockTypes( blacklistArr )
or the new version
wp.data.dispatch( 'core/preferences' ).set( 'core/edit-post' , 'hideBlockTypes' , blacklistArr )
are not working any more. The setDefaults is not working for me, maybe I call it to late. I think I am going to quit developing in gutenberg: once you figure something out, its changed again.

With the block manager show/hide blocks in the inserter now is a user setting. Why isnt this stored in the usermeta table in the database? And why should a user (my clients) be bothered with packs of useless embed-blocks all turned on (default visible)?

I know I can disable blocks the hard way by php filtering, but thats not the right way to hide blocks because you get errors when a block is used before setting this filter. I thing there should be a 'overall hide function' (like it was) to hide blocks from the inserter AND block manager.

[shimotmk]

We've started saving values in the wp_persisted_preferences of the wp_usermeta database, so we can now set default values from PHP. Therefore, I'm closing this.