Gutenberg 8.0.0 legacy FSE compatibility: add block patterns to inserter

[andrewserong]

Reported by @p-jackson:

In testing Gutenberg v8.0.0 on legacy wpcom FSE sites, the main block inserter does not include a tab for block patterns. However, in v8.0.0, the block patterns were moved from a plugin in the sidebar, to a tab in the main block inserter. From a little digging, it looks like the FSE plugin rebuilds the block inserter to replace the default one so that it can set a rootClientId. It sounds like this was so that an inserted block would be inserted into the correct part of the page / template (e.g. inserting into the header or template part, versus inserting into the post content).

Here's the relevant component:

https://github.com/automattic/wp-calypso/blob/4537033c6794449ce0a10b69d72daf5fa658d553/apps/full-site-editing/full-site-editing-plugin/dotcom-fse/editor/block-inserter/post-content-block-appender.js#L24

Screenshot of FSE block inserter

Screenshot of what the inserter "should" look like

Note that the new block inserter is also a panel instead of a pop-over, and left aligned to the edge of the window.

Things to look into in addressing this:

• How much of this will be resolved automatically by updating the @wordpress/ packages in the FSE plugin?
• Is it possible for this to be a fairly simple change of adding in the component from Gutenberg?

[Addison-Stavlo]

It looks like this may be a result of @wordpress/block-editor dependency being behind a couple versions at the calypso root. Dotcom FSE is getting the old inserter from the outdated package?

[sirreal]

How much of this will be resolved automatically by updating the @wordpress/ packages in the FSE plugin?

The FSE plugin uses @wordpress/* packages as externals. There shouldn't be any issue with package versions in Calypso, the code isn't bundled. These dependencies come from globals in the browser, wp.blockEditor in the case of @wordpress/block-editor.

That means that with Gutenberg 8 installed, we're should be using Gutenberg 8's included block-editor package.

[sirreal]

This is expected behavior. templateLock prevents the inserter from being shown:

wp-calypso/apps/full-site-editing/full-site-editing-plugin/dotcom-fse/class-full-site-editing.php

Line 432 in 4537033

$editor_settings['templateLock'] = 'all';

Then we build and inject our own inerter/appender:

wp-calypso/apps/full-site-editing/full-site-editing-plugin/dotcom-fse/editor/block-inserter/post-content-block-appender.js

Lines 24 to 29 in 4537033

	<Inserter
	rootClientId={ rootClientId }
	disabled={ ! showInserter }
	position="bottom right"
	toggleProps={ inserterToggleProps }
	/>

I've been digging a bit and the best path forward here is unclear to me. Ideally, we could simply set a different rootClientId or set a custom block appender and we'd be able to remove the custom inserter entirely. The block editor layout appears to have changed in significantly. The newer inserter is rendered in a side panel, has tabs with block patterns (noted in this issue), it has a block preview.

It's unappealing to reimplement the entire block inserter for a feature that is deprecated.

[Addison-Stavlo]

It's unappealing to reimplement the entire block inserter for a feature that is deprecated.

100% agreed. Fixing current functionality that gets broken is one thing, but ensuring it inherits new functionality is another. I think we should move this to the prioritized backlog and not have it as a blocker for 8.0 release.

[sirreal]

The contents of the new inserter are exposed as experimental:

import { __experimentalLibrary as Library } from '@wordpress/block-editor';

Used here in the new layout: https://github.com/WordPress/gutenberg/blob/4830c2c2b95dc612b73efffbd3ed03cd93cd83fa/packages/edit-post/src/components/layout/index.js#L185-L192

Here's the component: https://github.com/WordPress/gutenberg/blob/4830c2c2b95dc612b73efffbd3ed03cd93cd83fa/packages/block-editor/src/components/inserter/library.js

[ockham]

The contents of the new inserter are exposed as experimental:

import { __experimentalLibrary as Library } from '@wordpress/block-editor';

Used here in the new layout: https://github.com/WordPress/gutenberg/blob/4830c2c2b95dc612b73efffbd3ed03cd93cd83fa/packages/edit-post/src/components/layout/index.js#L185-L192

Here's the component: https://github.com/WordPress/gutenberg/blob/4830c2c2b95dc612b73efffbd3ed03cd93cd83fa/packages/block-editor/src/components/inserter/library.js

I had a quick look into this. The visibility of the InserterLibrary (as it is now called) is determined by component state managed in the header component, and set by the the inserter toggle (the ➕ sign). So in order to replace with our own version (with a different rootClientId) in FSE, we'd now have to replace both, and connect their replacements somehow in order to be able to toggle visibilty.

[yansern]

Semi-related: The design of the inserter menu has changed slightly. See: WordPress/gutenberg#19279

[github-actions]

This issue is stale because it has been 180 days with no activity. You can keep the issue open by adding a comment. If you do, please provide additional context and explain why you’d like it to remain open. You can also close the issue yourself — if you do, please add a brief explanation and apply one of relevant issue close labels.