New createBlockEditFilter removed the core/editor/custom-class-name/with-inspector-control and causes issues with plugin

[coreyworrell]

Description

In older version of Gutenberg we could replace the "Additional CSS Class(es)" field with our own (with autocomplete for example) by simply using something like:

removeFilter(
    'editor.BlockEdit',
    'core/editor/custom-class-name/with-inspector-control',
)

addFilter(
    'editor.BlockEdit',
    'site/custom-class-name/withInspectorControls',
    withInspectorControls,
)

Now core does not add the core/editor/custom-class-name/with-inspector-control filter, so the removeFilter code above does not remove the custom class name field, so we end up with a duplicate field. This seems to be the commit that changes it: a9cbc06

This affects our Block Class Autocomplete plugin (source) and the more popular EditorsKit plugin (source).

Step-by-step reproduction instructions

1. Install either plugin referenced above
2. Edit page
3. Select a block
4. Open Advanced Inspector panel
5. See duplicate Custom CSS Class(es) field

Screenshots, screen recording, code snippet

Environment info

• WordPress 6.5.2 (bundled Gutenberg version)

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

[Mamaduka]

cc @ellatrix

[mkkeck]

How can we get a working alternative of the removed hook
core/editor/custom-class-name/with-inspector-control?
Or how can we replace / hook into any control of Inspektor Control?

[mkkeck]

A month later: Any info available (Mamaduka, ellatrix)?

[ellatrix]

Yes, all these controls moved to a single filter for performance reasons. Technically I guess we could add a dummy item to that filter, and check for removal. Would this still be useful to fix this late? Are you using the GB plugin, or only core WP?

Ideally we need a new block supports API where plugins can also deregister block support items.

[mkkeck]

Yes, all these controls moved to a single filter for performance reasons. Technically I guess we could add a dummy item to that filter, and check for removal. Would this still be useful to fix this late?

I think filters, actions or (I prefer to say) hooks would be really helpfull. And of course, it would be really nice, to inform plugin and theme developers, if such things changes BEFORE added to core.

Are you using the GB plugin, or only core WP?

Mainly the core WP.
The GB plugin only for testing and diffing

Ideally we need a new block supports API where plugins can also deregister block support items.

I think a new API would not solve existing issues. Better documentation and changing carefully the core, which means more testing against most used popular plugins and themes, may be better.
If there would be a new API, than it should be simpler, easier to understand and learn and well documented with many examples.

[coreyworrell]

Any update on this? It's been a couple months and we're still having to deal with the duplicated input issue.