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

core/media-text adding custom block to allowed blocks #13955

Closed
DietteJanssen opened this issue Feb 19, 2019 · 9 comments
Closed

core/media-text adding custom block to allowed blocks #13955

DietteJanssen opened this issue Feb 19, 2019 · 9 comments
Labels
[Block] Media & Text Affects the Media & Text Block [Feature] Extensibility The ability to extend blocks or the editing experience [Priority] Low Used to indicate that the issue at hand isn't a top priority to address and can be handled later

Comments

@DietteJanssen
Copy link

DietteJanssen commented Feb 19, 2019

i have searched everywhere and i cannot find out how to achieve the following.

i want to add my custom block to the list of allowed blocks within the core/media-text block. i'm looking to extend the existing. In the handbook, i have tried the following (https://wordpress.org/gutenberg/handbook/designers-developers/developers/filters/block-filters/ > Using a whitelist ):

var allowedBlocks = [
    'core/paragraph',
    'core/image',
    'core/html',
    'core/freeform'
];

wp.blocks.getBlockTypes().forEach( function( blockType ) {
    if ( allowedBlocks.indexOf( blockType.name ) === -1 ) {
        wp.blocks.unregisterBlockType( blockType.name );
    }
} );

...editing getBlockTypes() to getBlockTypes('core/media-text'). however, i believe because the core block already has a whitelist applied this is whitelisting what has already been whitelisted, (not opening up all of the gutenberg blocks and then whitelisting those).

is there a way to extend this core block to include my custom block within their constant of allowed blocktypes: const ALLOWED_BLOCKS = [ 'core/button', 'core/paragraph', 'core/heading', 'core/list' ];?

added note: i'm interested in achieving this without unregistering the block and re-registering one to replace it (if possible).

@swissspidy swissspidy added [Block] Media & Text Affects the Media & Text Block [Type] Help Request Help with setup, implementation, or "How do I?" questions. labels Feb 19, 2019
@dmtrmrv
Copy link

dmtrmrv commented Apr 9, 2019

Also interested in this.

@mkronenfeld
Copy link

mkronenfeld commented May 15, 2019

Is there any solution for this issue yet? Maybe a higher-order component to extend the allowedBlocks prop of the InnerBlocks component?

Attention, pseudo code ahead

const withCustomAllowedBlocks = createHigherOrderComponent( InnerBlock => {
  return ( props ) => {
    if ( 'core/media-text' !== props.name ) {
      return self // or whatever
    }

    const customAllowedBlocks = [
      ...props.allowedBlocks,
      'core/paragraph',
      'core/image',
      'core/html',
      'core/freeform',
    ];

    return (
      <InnerBlock
        { ...props }
        allowedBlocks={ customAllowedBlocks }
      />
    );
  };
}, 'withCustomAllowedBlocks' );

wp.hooks.addFilter(
  'editor.InnerBlock',
  'my-plugin/with-custom-allowed-blocks',
  withCustomAllowedBlocks
);

@vortacan
Copy link

vortacan commented Jun 3, 2019

I have tried to alter the list of allowed (Inner) Blocks for two days now and haven’t been successful so far. There might be a simple alternative solution for your case though: If your custom block is only to be used as a child block of the core/media-text block you can explicitly set this core block as a parent in your custom block’s registerBlockType method like this:
parent: ['core/media-text'],
This makes the block available as an Inner Block in the inserter. But hides it from the inserter outside its parent block! If you need your custom block elsewhere consider creating a duplicate without the parent setting. It’s a bit of an overhead I know...
I’ll go for this solution in my project now as I need to work on...

@youknowriad youknowriad added [Feature] Extensibility The ability to extend blocks or the editing experience [Priority] Low Used to indicate that the issue at hand isn't a top priority to address and can be handled later and removed [Type] Help Request Help with setup, implementation, or "How do I?" questions. labels Jun 13, 2019
@youknowriad
Copy link
Contributor

So, this is not possible at the moment. That said, the group block might be getting support for background images (like the cover block) and the group block can support any inner block which would address this issue. #14744

I'm going to keep this open at least until we get that. We should probably circle back to the issue a bit later.

@spacedmonkey
Copy link
Member

Allowed inner blocks should be defined at the block level. This should make them filterable and easier to find.

A new field should be added to block definition - https://github.com/WordPress/gutenberg/blob/master/docs/rfc/block-registration.md

@spacedmonkey
Copy link
Member

Related: #16560

@oxyc
Copy link
Member

oxyc commented Aug 10, 2019

The Media and text block has no restrictions now so this can probably be closed.

@DietteJanssen
Copy link
Author

media blocks are still restricted to a limited selection of core blocks, so i'm not sure why this is closed.

@dcooney
Copy link

dcooney commented Feb 1, 2021

I'm also looking for a method to limit and/or extend the allowed blocks of innerBlocks for the Media Text block.
InnerBlocks are not exposed in the settings of the registerBlockType filter are there appears to be no way to hook into InnerBlocks without writing your own custom block.

Was this closed with a solution? I'm not seeing one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Block] Media & Text Affects the Media & Text Block [Feature] Extensibility The ability to extend blocks or the editing experience [Priority] Low Used to indicate that the issue at hand isn't a top priority to address and can be handled later
Projects
None yet
Development

No branches or pull requests

9 participants