Lack of configuration endangers editorial workflow

[donohoe]

• Part of Block API #41236.

What problem does this address?

As a small publisher in media, WP introduces extensive new features and functionality that we do not need. Very often it creates problems by adding featured within the Editor that we do not support on the frontend template.

Disabling such features is often not possible, or creates overhead on the WP UI that can break between releases.

Some examples:

An article template supports numerous blocks but we don't support most over 60 of them ('core/post-content','core/post-author', core/query-pagination', 'core/comments-title', 'core/home-link', 'core/calendar', 'core/column' etc.)

We have to manually unregister each block, and we need to manually add new blocks as they are added in each release. There is a disconnect between registering/unregistering blocks by PHP or JS.

Likewise, blocks themselves change. We support the Quote Block but in version 6.2 that block also support Images as the quote content. Our site design doesn't allow for it, nor do we need it. Separately I would argue that the Quote Block should never support it. There is no obvious way to disable the image aspect to Quotes.

These changes that we cannot control create confusion to our users, writers and editors, when they use features that break the page, or don't work at all to expectation.

I love WordPress. I had Quartz built on it, then I had The New Yorker migrate to it (since left due to custom corporate CMS), and I just had Rest of World built on it.

What is your proposed solution?

As a publisher/engineer, we need attention to configuration options. They appear to be missing entirely, or an after-thought, on core features that are vital to us.

[talldan]

A part of Gutenberg phase 3 will involve improving workflows (in addition to the collaborative features).

The finer points of phase 3 haven't quite been detailed yet, but are in the process of being planned, so it's great time to get this feedback. Hopefully there will be some features coming that will improve the experience for you.

[t-hamano]

We support the Quote Block but in version 6.2 that block also support Images as the quote content. Our site design doesn't allow for it, nor do we need it. Separately I would argue that the Quote Block should never support it. There is no obvious way to disable the image aspect to Quotes.

As for this, it is an unstable hook, but could be disabled as follows:

function customCanInsertBlockType( canInsert, blockType, rootClientId ) {
	// Returns the default value if the block is at the root level
	if ( ! rootClientId ) {
		return canInsert;
	}

	// Get the parent's block
	const parentBlock = wp.data.select( 'core/block-editor' ).getBlock( rootClientId );

	// Returns the default value if the parent's block isn't a quote block
	if ( parentBlock.name !== 'core/quote' ) {
		return canInsert;
	}

	// Prevent the insertion of an image block within a quote block
	if ( blockType.name === 'core/image' ) {
		return false;
	}

	return canInsert;
}

wp.hooks.addFilter(
	'blockEditor.__unstableCanInsertBlockType',
	'my-plugin/can-insert',
	customCanInsertBlockType
);

[andreaslindahl]

I agree. It's getting harder and harder to keep up with changes to core blocks, new core blocks, layout options etc and there is often a lack of documentation on how to disable or configure certain features.

It's basically great that blocks and layouts can be configured - margins, alignments, paddings etc - but usually I try to keep these features to a minimum, since editors have a way of being... "creative", which creates a lot of confusion and broken designs. So I usually disable as many core blocks as possible, instead creating custom blocks with fewer options to keep everything clean and easy to edit.

[mcsf]

Thanks for the feedback, @donohoe.

As a publisher/engineer, we need attention to configuration options. They appear to be missing entirely, or an after-thought, on core features that are vital to us.

Rest assured: this is a perennial goal for Gutenberg. Unfortunately, it's a bit of a moving target, because as blocks and editor become more capable, so does complexity need to be managed. In this sense, configuration serves both publishers and end users alike.

In the past, one of our more concerted efforts on this front was #20588. More recently we introduced content-only editing, which was another step towards better letting site owners lock down regions of the canvas for users to work with.

Lately, in the context of Phase 2 (site editing and customisation) we have been leaning on block patterns as a unit of content that is easier to use than the individual block. Patterns have the potential to become better sectioning elements and accommodate a lot of these goals we have around configuration of block options, styles, but also content semantics and restricted editing (#48458).

Of course, as @talldan notes, Phase 3 will add another layer to that, focused on more formal editing flows, capabilities, etc.

This is all to say: there are many shortcomings today, but our goals are definitely aligned, so please keep contributing. :)

[thatdevgirl]

As a developer in higher education, this issue affects us too. Our team maintains themes used by almost 400 websites. The point of our themes is to ensure all university websites have a uniform look to adhere to our university's pre-defined visual identity guidelines. Therefore, we need to customize / lock down many editor features, to ensure that we keep that uniform look.

1. We do not need most of the latest FSE - e.g. core/navigation, core/site-logo, core/post-*, etc. We have disabled those blocks.
2. We do not want comments anywhere on our site, so we have also disabled those blocks.
3. Some of the layout/design blocks, like Cover, have way too many features that we do not want our users to have access to. The easiest solution for us was to disable that block, to avoid our content editors from using the features that would go against our visual identity guidelines.
4. Some blocks have accessibility issues. The front-end markup is not always accessible and one of our primary goals is to ensure that all content and templates meet WCAG 2.1 A and AA standards. It is difficult to adjust the core blocks' markup in many cases.
   • An example is the core/table block. We disabled that core block in lieu of a more accessible custom block that we wrote. (Note: We wrote that custom block quite a while ago. The core Table block has gotten better accessibility-wise, but is not yet perfect. Between that and the fact that our custom block has been widely adopted by our websites, we do not anticipate going back to the core block.)

As stated in the issue description, more blocks are added to the editor, which means that we have to stay on top of these changes, evaluate which blocks are supported by our system, and disable the ones that we will not support. Having an easier way to disable the unsupported blocks or customize core blocks, as necessary, would be great.

[nathansmonk]

Agreed here too, WP updates have become a bit scarier. We (as an agency supporting the education sector) need to do a lot more reviewing before we release it. Worst case scenario, we have to make updates to existing sites before we let core update. There are a lot more update headaches post-gutenberg.

And most of the time they’re tiny bits like “buttons are not rounded in the backend, but they didn't used to be” which eat up a lot of our service desk time. But bigger updates to core blocks can be really scary. There was a gallery block update not so long back. We had to completely change footing to update our themes, putting internal milestones out by a week or so. Another example is the introduction of new blocks. If we haven't accounted for them, and let that update out without removing the blocks, we get instant support issues in terms of “I added this block but it doesn’t look right” etc.

We’re changing our workflow around it, but I’d love to see options for rollout. Like in apps where you can say that you are cool with beta releases, or a faster track, vs let me turn stuff on when I’m ready for it.

TLDR: I love seeing the new shiny things, I just wish I had better control over the rollout, so that I didn't have so much anxiety over updates.

[ndiego]

Having an easier way to disable the unsupported blocks or customize core blocks, as necessary, would be great.

There is a disconnect between registering/unregistering blocks by PHP or JS.

I completely agree that a very straightforward way to conditionally enable any block (and block variation) is needed, both globally and contextually.

Curious if you could expand on the comments above @thatdevgirl and @donohoe and also share how you are currently managing blocks. Perhaps through the allowed_block_types_all hook, or in JavaScript?

[mrwweb]

share how you are currently managing blocks

Speaking only for myself, I have a plugin I use for all client sites so I can easily roll-out updates that globally turn off settings/blocks/styles.

I've set the plugin up so I have a PHP filter to choose what blocks to hide (along with a few others to more easily hide entire groups of blocks). I then use wp_localize_script() to hand that off to JavaScript and remove each block from the inserter.

Early on, I got burned too many times by hiding a block that was in use which crashed the editor if fully preventing the block from getting registered as opposed to hiding it from the inserter. In theory a clever editor could add an unsupported block via custom code, but I haven't actually had that happen in practice.

My new issue with this approach when it comes to Block Themes is that a lot of the blocks I want in the Site Editor I still don't want in the Block Editor. So in my case, I hope to eventually make those filters context aware so I can hide blocks in more specific contexts.

[thatdevgirl]

We are also hiding blocks from the block inserter. Our code at work is all in private repos, but it is basically the code below. We add blocks to the HiddenBlocks array as new blocks that we don't want are released.

const { addFilter } = wp.hooks;

// Examples; our actual array of blocks to hide is much larager.
const HiddenBlocks = [ 'core/group', 'core/html' ];

// Determine whether the current block should be hidden.
function maybeHideMe( name ) {
  return ( HiddenBlocks.includes( name )  );
}

// Hide the current block, assuming it should be hidden.
const hide = ( settings, name ) => {
  if ( HiddenBlocks.includes( name ) ) {

    return lodash.assign( {}, settings, {
      supports: {
        inserter: false,
      },
    } );
  }

  // If we get here, the block should NOT be hidden; return original settings.
  return settings;
};

addFilter( 'blocks.registerBlockType', 'custom/hide-core-blocks', hide );

Like @mrwweb, we have also gotten burned by unregistering blocks, particularly if the unregistered block is a required child block of another parent block that we want to keep. Hiding blocks from the block inserter is a much safer method.

I would also like to echo @nathansmonk's comments about WP core updates being scarier than they were in the past. More often than not, we have to pay special attention to the more major core updates and fix (usually style) issues that conflict with our sites. Granted, our sites include a lot of custom code, but I feel that core updates in the past were a bit friendlier in terms of backwards compatibility.

[mcsf]

Our code at work is all in private repos, but it is basically the code below. We add blocks to the HiddenBlocks array as new blocks that we don't want are released.

@thatdevgirl: ignore me if this is just an artefact from editing the code to share it in this thread, but in the snippet you shared the original supports object is being entirely overwritten. It should either be return { ...settings, supports: { ...settings.supports, inserter: false } } (immutable) or simply settings.supports.inserter = false (mutable), since we are not in a context where the system reacts to reference changes.

We’re changing our workflow around it, but I’d love to see options for rollout. Like in apps where you can say that you are cool with beta releases, or a faster track, vs let me turn stuff on when I’m ready for it.

@nathansmonk: yeah, I understand the frustration there. I know this is not the answer you'd like to hear, but in most ways there already is a "fast track vs. stable release" distinction which is having the Gutenberg plugin enabled vs. just running the block editor as provided by Core. Running the plugin as a habit is the best way to get a sense of what is coming ahead. This doesn't preclude trying to come up with better roll-out type solutions for agencies with strict needs, of course.

[thatdevgirl]

@mcsf Thank you. The purpose of the illustration was to give people an idea about how we are managing blocks. It was pretty heavily distilled from our production code so I could better answer the request above of "share how you are currently managing blocks". My example is not code you should be using in production.

[annezazu]

Wanted to provide an update for you all and a chance to share more insights directly into the current phase 3 project area that touches on this topic: https://make.wordpress.org/core/2023/07/10/block-library/ I'm going to comment shortly with a link to this issue as well so keep the feedback coming!