Altering / Restricting core blocks for consistent design

[katerlouis]

Hopefully this topic isn't discussed elsewhere already. I doubt it though.. but I couldn't find a designated thread for this; please forgive me!

As great as Gutenbergs flexibility and freedom for editors is, to me as a designer/developer it is just as important to restrict the editing experience, to achieve consistent design throughout the page.

For instance:
In my design, the the editor should only be able to choose between 2 paragraph classes/styles in the inspector. No background- or text-color, no additional classes.

Workaround

Just tell the customer to always use the custom paragraph block!

_ When hitting spacebar remains producing another core-paragraph, editors definitely won't consistently change to the desired custom block.

Possible solution 1: Overwriting the core block

A custom block with these requirements + unregister the core paragraph

_ Is it even possible to unregister the core paragraph?
_ Or maybe "instant transform to my custom block"?
_ would it be a good idea since the paragraph is probably more involved under the hood as I think now?
_ a paragraph block is easily custom made, but how about changing the gallery? Sounds like unnecessary hassle to rewrite all blocks just for some minor changes.

Possible solution 2: Altering the core block

My mindset here is similar to how hooks/filters work.
You guys implement something like changeBlockType(), which the dev can use to set supports: {} and attributes: {} as see fit.

_ Since each block has quite some stuff going on in terms of edit() and save() I assume this is out of the question.

Possible solution 2b: You guys give a bunch of options

Similar, but different– changeBlockSettings() is a function, that gets an options-object, which the core-block reacts to on registering.

_ just like with filters, what if different plugins fight for altering the blocks? Maybe changes can only be made on a theme level?

When restriction won't be possible, I fear Gutenberg will do more harm than good to my websites. You can make detailed design-guides for editors all you want; in reality: if there are options, these options will be used.

Very interesting topic,
I am thrilled to learn how you guys suggest to proceed here.

[chrisvanpatten]

Hi @katerlouis -

There have been a few issues about this topic. You might want to look at #6023, #5360, #3330, #6228, #5785, and the block extension documentation: https://wordpress.org/gutenberg/handbook/extensibility/extending-blocks/

Those issues and links will give you some context on what's possible now and what might be possible in the future.

[katerlouis]

Shame on me– I already read the extensibility intro, but haven't gotten, and obviously totally forgotten about, the extending-blocks section in the handbook. Sorry for that!

Great reading in these issues; but it's just too much. :(

Since the wp.blocks.addFilter work so simliar to filters, I could easily add { supports: { customClassName: false } }

Let's see how far I can go :)

My biggest issue is finding reliable resources for all this new JS stuff.
Especially being new React, ES6 and wordpress JS world– hard to figure out what is coming from what;
The handbook is a great improvement over any other wordpress docs I've come across; but I hope there will be way more in the future.

Anyhow, thank you very much!

[mtias]

You can also just disable the custom colors and color palette. All these design options will be exposed to add_theme_support configuration.