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

Fix: Block manager doesn't respect allowed_block_types hook #16586

Conversation

@jorgefilipecosta
Copy link
Member

commented Jul 15, 2019

Description

Fix: #15598

Currently, the block manager shows blocks that are not allowed by the allowed_block_types filter.
This PR fixes this problem by removing hiding these blocks from the block manager. The user should not notice the existence of blocks not allowed by the allowed_block_types so not showing them in the block manager seems the best approach.

How has this been tested?

I tested these changes without applying any filter, and things worked exactly as before.
I added the following code to functions.php of the currently enabled theme:

function whitelistBlocks( $allowed ) {
	$allowed = [
		'core/image',
		'core/gallery',
		'core/list',
		'core/button',
		'core/columns',
		'core/column',
		'core-embed/youtube',
		'core-embed/vimeo',
		'core/separator',
		'core/text-columns',
		'core/heading',
		'core/subhead',
		'core/block',
		'core/shortcode',
	];
	return $allowed;
}

add_filter( 'allowed_block_types', 'whitelistBlocks' );

I verified only blocks that are returned by whitelistBlocks are part of the block manager; all other blocks don't appear at all.

Copy link
Member

left a comment

How feasible would it be to include end-to-end tests here?

return blockTypes.filter( ( { name } ) => {
return includes( allowedBlockTypes || [], name );
} );
} );

This comment has been minimized.

Copy link
@aduth

aduth Jul 15, 2019

Member

I would think we need some dependencies (a second argument) here, at least blockTypes and probably allowedBlockTypes (or settings)?

This comment has been minimized.

Copy link
@jorgefilipecosta

jorgefilipecosta Jul 26, 2019

Author Member

Updated 👍

/**
* WordPress dependencies
*/
import { createContext } from '@wordpress/element';

This comment has been minimized.

Copy link
@aduth

aduth Jul 15, 2019

Member

I guess this is more for convenience in making the settings available to the modal component? I thought whether we had this tracked in state, but I guess that's only in the editor and block-editor modules. We could do the same in this module as well, but it might be a bit overkill for the one setting we're interested in (I also feel it's already become difficult to manage in the two modules it is present).

This comment has been minimized.

Copy link
@jorgefilipecosta

jorgefilipecosta Jul 26, 2019

Author Member

Yes, I used context as a convenience. Adding it to the edit-post store seemed overkill, and it seemed it would just bring more confusion, I guess we can reconsider later if we have other reasons to add it. While if we add now, I think we can not easily remove them because of o back-compatibility.

@jorgefilipecosta jorgefilipecosta changed the title FIx: Block manager doesn't respect allowed_block_types hook Fix: Block manager doesn't respect allowed_block_types hook Jul 16, 2019
@jorgefilipecosta jorgefilipecosta force-pushed the fix/block-manager-doesnt-respect-allowed_block_types-hook branch from b1e3450 to d41a022 Jul 22, 2019
@jorgefilipecosta jorgefilipecosta force-pushed the fix/block-manager-doesnt-respect-allowed_block_types-hook branch from d41a022 to d06885d Jul 26, 2019
@jorgefilipecosta

This comment has been minimized.

Copy link
Member Author

commented Jul 26, 2019

Hi @aduth, your feedback was addressed and an end 2 end test was added.

@aduth
aduth approved these changes Jul 29, 2019
@@ -23,18 +25,32 @@ function BlockManagerCategory( {
toggleVisible,
toggleAllVisible,
} ) {
if ( ! blockTypes.length ) {
const settings = useContext( EditPostSettings );
const { allowedBlockTypes } = settings;

This comment has been minimized.

Copy link
@youknowriad

youknowriad Aug 1, 2019

Contributor

These are all available in the editor store why not just use that store instead of adding a new context provider?

This comment has been minimized.

Copy link
@jorgefilipecosta

jorgefilipecosta Aug 5, 2019

Author Member

Hi @youknowriad, when a user disables a block in the block manager the block is removed from the editor store allowed blocks. Using just the editor store, it is not possible to differentiate between a block disabled by the user and a block restricted on the server using a plugin. In this case, we need to distinguish both cases.

This comment has been minimized.

Copy link
@youknowriad

youknowriad Aug 6, 2019

Contributor

It's minor but It feels like something that can be solved in the store somehow instead of adding a new context for sharing data while we already have a context for that (the store).

@jorgefilipecosta jorgefilipecosta merged commit e830071 into master Aug 5, 2019
1 of 3 checks passed
1 of 3 checks passed
Filter merged Filter merged
Details
.github/main.workflow .github/main.workflow
Details
Travis CI - Pull Request Build Passed
Details
@jorgefilipecosta jorgefilipecosta deleted the fix/block-manager-doesnt-respect-allowed_block_types-hook branch Aug 5, 2019
@youknowriad youknowriad added this to the Gutenberg 6.3 milestone Aug 9, 2019
dd32 pushed a commit to dd32/gutenberg that referenced this pull request Sep 27, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.