WordPress / gutenberg

The Block Editor project for WordPress and beyond. Plugin is available from the official repository.
https://wordpress.org/gutenberg/
Other
10.57k stars 4.22k forks source link

Block Editor: Provide a way to customize panels in Inspector Controls #33891

Open kanlukasz opened 3 years ago

kanlukasz commented 3 years ago

What problem does this address?

(I am not sure if this is due to incomplete documentation or it is simply impossible to do. Therefore, I assume it as ticket here)

I don't know how to remove unwanted panels inside InspectorControls from core blocks. Unfortunately, there is no such example in the documentation, so I'm not sure how to do it I know about editor.BlockEdit filter but from what i see it's helping only if i want to make new wrapped component

What is your proposed solution?

If it is possible to remove unwanted panels inside InspectorControls from core blocks, it would be great to see such an example in the documentation or any example method here

caseymilne commented 3 years ago

Interesting idea. This would presumably have to be handled by a JS filter because the Inspector Controls are build from React components (without any PHP involvement). So we can't use PHP filters, but we could potentially use a JS filter on the list of Inspector Controls. From what little I know of the core build process however at this moment no such filtering exists and the build process would be a direct conversion from React defined components to the final output. This may change in the future because I believe it's also the reason we don't have an easy way to reorder the panels or inject new panels before defaults.

Worth mentioning that I do believe there is an HOC (Higher Order Component) approach that let's you tap into the entire editor build and through that it may be possible to filter out the panels. Some tutorials exist on using that approach for similar changes to the inspector.

kanlukasz commented 3 years ago

This would presumably have to be handled by a JS filter

Yes, of course, which is why I mentioned editor.BlockEdit but i'm not sure how to do it

Worth mentioning that I do believe there is an HOC (Higher Order Component) approach that let's you tap into the entire editor build and through that it may be possible to filter out the panels. Some tutorials exist on using that approach for similar changes to the inspector.

Share these tutorials with us, please.


Many users are looking for a solution to this (including me):

Note: theme.json made it possible to remove some panels, but not all, e.g. panels cannot be removed from an image block, etc.


Potential related issues I've found:

alpopp commented 3 years ago

This is so needed. It would also be nice to conditionally remove panels. For example, only certain block styles could get certain panels.

tellthemachines commented 2 years ago

Hi there! It is possible to remove block controls via theme.json, as shown in this comment. Sadly it's not possible to make the removal conditional on block styles (OP from the linked issue was also after that functionality).

ekesto commented 1 year ago

Not the prettiest quickfix idea, but at least we could hide unwanted panels from core blocks?

What if there was a data-attribute in the sidebar containing the information what block is being edited, for example: <div class="block-editor-block-inspector" data-block-type="core/button">

So we could then visually hide specific components using CSS:

[data-block-type="core/button"] > .color-block-support-panel {
    display: none;
}
lucspe commented 1 year ago

Hi,

I have found this as I was looking for a solution as well.

@ekesto suggestion makes sense.

Allowing to target control panels via CSS individually either via a class assigned or a data- attribute would also be useful to customize the style to control panels (for example to highlight some that we want the website editors to pay attention to).

gziolo commented 1 year ago

This is one of the items that we plan to tackle as part of the Block Library project from Phase 3: Collaboration roadmap. In particular, this functionality was covered by @mtias in the following section:

It also means introducing more robust permission handling across the various capabilities (block registration, locking, etc) so administrators can define what blocks are available for different user roles (or even what capabilities of individual blocks are to be exposed). The fact that theme.json files are inherently composable should allow for more granular handlings of capabilities in a systematic way. For example, consider a fictional author.theme.json that sets, disables, and controls what tools and settings are available for authors over the root config file.

There is also a complementary issue https://github.com/WordPress/gutenberg/issues/47641 for Block Toolbar.