Block Editor: Prevent inner block template from re-inserting when a block is moved via drag and drop

[dpmehta]

What?

Closes #70495

This PR fixes a bug where inner blocks that the user deliberately removed are unexpectedly re-inserted when the parent block (e.g. Details, Quote, Media & Text) is moved via drag and drop. After moving the block, inner blocks reappear as if the user never deleted them.

Why?

useInnerBlockTemplateSync relies on a useRef(null) to track whether the template has already been applied. Since useRef is tied to the React component instance, it resets to null every time the component is destroyed and recreated, which is exactly what happens during a drag-and-drop move.

On remount, two conditions happen to be true simultaneously:

• currentInnerBlocks.length === 0 , because the user already deleted the inner blocks
• hasTemplateChanged is true , because existingTemplateRef.current is null again after the remount

Both guards pass, replaceInnerBlocks is called, and the deleted blocks come back. This affects any block that uses useInnerBlocksProps with a template but without a templateLock , confirmed on Details, Quote, and Media & Text blocks.

How?

We followed the existing pattern already used by useNestedSettingsUpdate + blockListSettings in the block-editor store: state that must survive React component remounts should live in the Redux store keyed by clientId, not in a useRef.

• Added a syncedTemplateClientIds reducer (a Set<string>) to the block-editor store. It tracks which block clientIds have had their template applied at least once. The key design decision is that the reducer intentionally ignores MOVE_BLOCKS_TO_POSITION , so the flag survives a drag-and-drop but cleans up on REMOVE_BLOCKS, REPLACE_BLOCKS, and RESET_BLOCKS.
• Added a private action markTemplateSyncApplied( clientId ) dispatched after the first successful template application.
• Added a private selector wasTemplateSyncApplied( state, clientId ) to read from the Set.
• Updated useInnerBlockTemplateSync to read the store flag and skip re-applying the template when the block is unlocked and the flag is already set, preventing the unexpected re-insertion on remount.

The fix is scoped only to unlocked templates (templateLock is not 'all' or 'contentOnly'), so locked template behaviour is completely unchanged.

Testing Instructions

1. Create a post and add a Group block.
2. Inside the Group, add a Details block (or Quote / Media & Text).
3. Inside the Details block, confirm the default Paragraph inner block is present.
4. Delete the Paragraph inner block.
5. Drag the Details block outside the Group block.
6. Confirm the Paragraph block does not reappear after the move.
7. Also verify that inserting a fresh Details block still correctly populates the default Paragraph on first insert.

Screenshots or screencast

Before Fix :

Screen.Capture.on.2025-06-20.at.17-21-00.2.mov

After Fix :

after-fix.mov

Use of AI Tools

Claude was used to investigate the issue, figure out existing pattern, implement the fix, and documentation. The changes were reviewed and validated.

[github-actions]

Warning: Type of PR label mismatch

To merge this PR, it requires exactly 1 label indicating the type of PR. Other labels are optional and not being checked here.

• Required label: Any label starting with [Type].
• Labels found: [Package] Block editor.

Read more about Type labels in Gutenberg. Don't worry if you don't have the required permissions to add labels; the PR reviewer should be able to help with the task.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: dpmehta <mehtadev@git.wordpress.org>
Co-authored-by: mecskyverse <aakashverma1@git.wordpress.org>
Co-authored-by: gigitux <gigitux@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.