Previewing patterns clones the content blocks they contain

Problem/Motivation

Previewing a pattern that contains a content block creates a copy of that content block.

The drupalgutenberg/duplicate-content-block-ids filter (editor.BlockEdit, js/filters/content-blocks.jsx) runs for every content block that is rendered, including the blocks of the previews of the inserter's Patterns tab. A preview's content block has a new client ID, so the filter calls /editor/content_block/clone_if_used, and GutenbergContentBlocksManager::cloneBlock() saves a copy of the block when it is already used: by another node, or by the edited one when the same block is already in the content (isDuplicate). The copy is never used, as the preview is discarded.

On a test site with 20 non-reusable content blocks and 40 patterns (2 content blocks each, in 4 categories), browsing the 4 categories once created 60 content blocks, and every visit creates more. Each one also costs a request, on top of the render requests of the preview.

The copies have an inactive usage record, so gutenberg_cron() deletes them, but only after 24 hours and 20 per run, so they pile up faster than cron removes them on sites where editors browse patterns.

Only non-reusable content blocks are copied (canBeCloned()), which are the ones the editor creates. For reusable ones, the request still runs and the preview clears the block's ID.

4.0.x has the same filter (packages/filters/src/content-blocks.jsx).

Steps to reproduce

1. Allow the Basic content block type for Basic page.
2. Create a Basic page, add a Basic content block, fill in its form in the sidebar, and save the page.
3. Edit the page again, select the content block, and create a pattern from it (Options → Create pattern).
4. Count the content blocks: drush sqlq "SELECT COUNT(*) FROM block_content"
5. Open the block inserter, Patterns tab, and select the pattern's category.
6. Count the content blocks again: there is one more. Selecting the category again adds another.

Proposed resolution

Skip the duplicate check in previews. A preview has its own block editor settings with the preview mode on, so the filter can read it from the block editor store, under both names the setting has had: __unstableIsPreviewMode (the WordPress 6.4 packages of 3.0.x) and isPreviewMode (since WordPress 6.8, used by 4.0.x).

The check still runs when a pattern is inserted, as its blocks are then created in the content.

Also remove the filter's console.log() calls.

Remaining tasks

• Fix the filter on 3.0.x and 4.0.x.
• Add a test: preview a pattern with a used content block and check that no content block is created.
• Follow-ups for the request load of the editor (to be opened):
  • Since 3.0.7, the hydration code in gutenberg.js calls resetBlocks() on every editor load, so every Drupal block and content block is fetched twice.
  • Rendered Drupal blocks, rendered content blocks and the view mode lists aren't cached, on the client or the server, so each preview and each block fetches them again.

User interface changes

None.

API changes

None.

Data model changes

None. Copies created so far are deleted by cron.