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

Blocks: Filterable allowed inserter block types #3577

Merged
merged 2 commits into from Nov 21, 2017

Conversation

Projects
None yet
3 participants
@aduth
Member

aduth commented Nov 20, 2017

This pull request seeks to enable filtering of block types offered through the Inserter component. It does so both in the client and in the server.

On the server, a plugin author can filter allowed_block_types to return either true (all block types supported), false (no block types supported), or an array of block type names to allow. This may enable custom post types to limit the types of blocks allowed.

In the client, since the block types are passed through as a setting in EditorProvider, creating a new provider context with settings specifying block types is sufficient to limit permitted block types. This will become relevant for block nesting to allow a block to define allowed children types.

Implementation notes:

The behavior here required that an editor component gain access to editor context. The existing withEditorSettings higher-order component would have worked, but was implemented expecting to be used only in the context of the blocks module. With the changes here, I have moved withEditorSettings to a more generic withContext higher-order component in the components module, allowing a component to opt-in to receiving context of any name.

Testing instructions:

Ensure unit tests pass:

npm test

Verify that you can filter block types, e.g. adding filters to one of Gutenberg's PHP files:

Disable all block types (no inserter is shown):

add_filter( 'allowed_block_types', '__return_false' );

Restrict block types:

add_filter( 'allowed_block_types', function() {
	return [ 'core/paragraph' ];
} );
@codecov

This comment has been minimized.

Show comment
Hide comment
@codecov

codecov bot Nov 20, 2017

Codecov Report

Merging #3577 into master will increase coverage by 0.05%.
The diff coverage is 65.71%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #3577      +/-   ##
==========================================
+ Coverage   35.29%   35.34%   +0.05%     
==========================================
  Files         267      267              
  Lines        6744     6762      +18     
  Branches     1221     1226       +5     
==========================================
+ Hits         2380     2390      +10     
- Misses       3687     3694       +7     
- Partials      677      678       +1
Impacted Files Coverage Δ
blocks/library/image/block.js 1.85% <ø> (ø) ⬆️
blocks/color-palette/index.js 0% <ø> (ø) ⬆️
blocks/block-alignment-toolbar/index.js 33.33% <ø> (ø) ⬆️
editor/components/inserter/index.js 0% <0%> (ø) ⬆️
components/higher-order/with-context/index.js 57.14% <66.66%> (ø)
editor/components/inserter/menu.js 85.54% <84%> (-1.79%) ⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 7cc7b8c...e6642bc. Read the comment docs.

codecov bot commented Nov 20, 2017

Codecov Report

Merging #3577 into master will increase coverage by 0.05%.
The diff coverage is 65.71%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #3577      +/-   ##
==========================================
+ Coverage   35.29%   35.34%   +0.05%     
==========================================
  Files         267      267              
  Lines        6744     6762      +18     
  Branches     1221     1226       +5     
==========================================
+ Hits         2380     2390      +10     
- Misses       3687     3694       +7     
- Partials      677      678       +1
Impacted Files Coverage Δ
blocks/library/image/block.js 1.85% <ø> (ø) ⬆️
blocks/color-palette/index.js 0% <ø> (ø) ⬆️
blocks/block-alignment-toolbar/index.js 33.33% <ø> (ø) ⬆️
editor/components/inserter/index.js 0% <0%> (ø) ⬆️
components/higher-order/with-context/index.js 57.14% <66.66%> (ø)
editor/components/inserter/menu.js 85.54% <84%> (-1.79%) ⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 7cc7b8c...e6642bc. Read the comment docs.

@aduth

This comment has been minimized.

Show comment
Hide comment
@aduth

aduth Nov 20, 2017

Member

After reading the proposed documentation in #3567, it seems we have a few other options for limiting the types of blocks supported:

  • Avoiding enqueuing their scripts in the first place (how to handle server-side registered?)
  • Unregistering them after the editor has loaded

cc @youknowriad

Member

aduth commented Nov 20, 2017

After reading the proposed documentation in #3567, it seems we have a few other options for limiting the types of blocks supported:

  • Avoiding enqueuing their scripts in the first place (how to handle server-side registered?)
  • Unregistering them after the editor has loaded

cc @youknowriad

@youknowriad

This comment has been minimized.

Show comment
Hide comment
@youknowriad

youknowriad Nov 21, 2017

Contributor

it seems we have a few other options for limiting the types of blocks supported:

Yes, we do but I do see the value of setting the block types in the "context", I was originally thinking we should add them to editor settings and just use withEditorSettings.

I'm not sure I understand why you can't use this in the editor module since it depends on the blocks module.

--

So if I understand properly, this only affects the Inserter and still use the globally registered blocks (and for example pasting, converting can still make use of these block types). I think it's a good first step but I'd love if we can avoid to use the globally registered blocks at all, and just provide the available blocks in the context. I tried this in one of my previous PRs, it could work but it's a way bigger change. I think this could also be valuable for nesting as well where we'd want to limit the available blocks.

Contributor

youknowriad commented Nov 21, 2017

it seems we have a few other options for limiting the types of blocks supported:

Yes, we do but I do see the value of setting the block types in the "context", I was originally thinking we should add them to editor settings and just use withEditorSettings.

I'm not sure I understand why you can't use this in the editor module since it depends on the blocks module.

--

So if I understand properly, this only affects the Inserter and still use the globally registered blocks (and for example pasting, converting can still make use of these block types). I think it's a good first step but I'd love if we can avoid to use the globally registered blocks at all, and just provide the available blocks in the context. I tried this in one of my previous PRs, it could work but it's a way bigger change. I think this could also be valuable for nesting as well where we'd want to limit the available blocks.

@mtias mtias added the Extensibility label Nov 21, 2017

@aduth

This comment has been minimized.

Show comment
Hide comment
@aduth

aduth Nov 21, 2017

Member

I'm not sure I understand why you can't use this in the editor module since it depends on the blocks module.

Not so much that it couldn't be done. Something about the editor consuming components from blocks didn't feel as clean as referencing the registration.

Member

aduth commented Nov 21, 2017

I'm not sure I understand why you can't use this in the editor module since it depends on the blocks module.

Not so much that it couldn't be done. Something about the editor consuming components from blocks didn't feel as clean as referencing the registration.

@aduth aduth merged commit 7067bae into master Nov 21, 2017

3 checks passed

codecov/project 35.34% (+0.05%) compared to 7cc7b8c
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
continuous-integration/travis-ci/push The Travis CI build passed
Details

@aduth aduth deleted the update/block-settings-allowed-types branch Nov 21, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment