When duplicating a Navigation or Template Part block, it's not clear why changing one changes the other

[carolinan]

Description

It seems that when you duplicate a template part, it does not automatically receive a unique identifier?

In the site editor, when I duplicate a template part:

1. The title of the copy remains the same as the original
2. When I add blocks to the copy, the original template part is also updated. -Hence I can not edit the copy without also changing the original.

-I can not change the title of the copy without using "Update design." #29844
-After changing the title of the template part and updating, the template parts are separate.

Step-by-step reproduction instructions

Please list the steps needed to reproduce the bug. For example:

1. Activate a theme with support for full site editing.
2. Open the site editor. Create and duplicate a template part.
3. change the contents of either template part.
4. confirm that both template parts are updated when you edit one of them.

Expected behaviour

I expected the copied template part to be its own unique copy with a new, random slug/title

Actual behaviour

The template part is not "unique" until the title has been updated by the user and the changes saved.

Screenshots or screen recording (optional)

template-part.mp4

WordPress information

• WordPress version: 5.7
• Gutenberg version: current trunk at f1d9a0b
• Are all plugins except Gutenberg deactivated? yes
• Are you using a default theme (e.g. Twenty Twenty-One)? Empty theme

Device information

• Device: Desktop
• Operating system: Windows 10
• Browser: Chrome Version 89.0.4389.90

[nikola-wd]

I have a similar bug with the framework I wrote. Here's what happens.

If I have a block "A", that doesn't have repeater fields inside it. And if I then duplicate that block, and edit the new block (that's a copy of the main block), I don't have any bugs. Each updates for itself. But.

In the case of block "B", which has a repeater field inside it, this is what happens.

1. I create one instance of the block "B" -> everything works
2. I then duplicate that block. Once I start editing the copy of that block -> It also overwrites and updates the fields in the first block.
3. If I duplicate the block "B", and then hit Save. -> This also occurs.
4. Only in the case where I do these steps: 1. Duplicate the block, 2. Hit Save, 3. Refresh the page, 4. Edit the new block's fields -> Only then it works as expected and only updates its fields. Original block "B" preserves its state.

I hope I am making sense here.
I haven't delved too much into clientID, and withInstanceID, but, from all that I've been able to research, I might think that this, in some way, might be causing this bug.

Here's the video of the bug:
https://www.loom.com/share/849afc4cbb5444f5a3f350184e06dca1

[carolinan]

I am updating this issue because I am experiencing the same with the navigation block.
If I select a navigation block, duplicate it, and make changes to the new duplicate, the original block changes as well.
I get the same results when duplicating as when I use "Copy" from the toolbar menu.

[draganescu]

I tested this with the navigation block and can confirm. Ideally on duplication, an independent copy of blocks should be created.

[kafleg]

I have the same issue.

• Windows 11
• Laragon Localhost
• PHP 7.4.19
• TT2 theme
• RC 1 - 5.9
• No Gutenberg plugin was installed or activated.

When the template part named Header and Footer is added, it both has a Site title block. And when we change in one block, it will change in all other blocks too.

[nikola-wd]

Any news about whether this bug is on the roadmap for being fixed? It's a pretty major bug.

[annezazu]

Noting that this has come up as a piece of feedback with the FSE Outreach Program's latest All Things Media exploration as a point of confusion (twice):

If I insert 2 headers, applying changes to one affects both the header. Don’t know why it is happening.

[gwwar]

So what's happening here is that a navigation block may be represented by content in a wp_navigation post.

When we copy the block, we're copying the ref attribute, so edits on child blocks will be reflected in both instances.

<!-- wp:navigation {"ref":695} /-->

One way of solving this is adding an action like a deepCopy, where if we see a ref attribute, we can create a new block container and copy its children. Note that in this scenario block children are not available as part of innerBlocks, but can still be queried:

@annezazu was there a similar issue for Reusable Blocks? They're represented in a similar way, with the block looking like:

<!-- wp:block {"ref":634} /-->

[annezazu]

@annezazu was there a similar issue for Reusable Blocks? They're represented in a similar way, with the block looking like.

I don't see a similar issue open for reusable blocks but can replicate the problem.

[draganescu]

@annezazu isn't this a feature in the case of reusable blocks though?

[annezazu]

Honestly, I'm not sure :) In my mind, using "duplicate" should create a copy that is distinct from the original whereas "copy" should result in the same reusable block being made. In this case, there is no difference between duplicate and copy currently with reusable blocks based on my quick testing.

[gwwar]

So after playing around with this last week, I think this is a little tricker than I thought to solve this for the general case. (We can of course temporarily put in a fix for navigation/templates if this is particularly urgent.)

Some questions that I found while exploring this:

When the "truth" of a block is no longer fully serialized, what does it mean to copy or duplicate it?

Many of the API factory functions expect that the block is fully represented by block attributes and inner block contents. When we point at a post reference or slug, should these abstractions know about these properties? Should we standardize externalized references in blocks similar to using an href?

See also the following links, where folks are exploring marking certain block attributes as having specific roles:

#38191
#38643
#34750

cc @dmsnell @stacimc @noisysocks @youknowriad @ntsekouras

User Experience/Intention

Depending on the block we might expect that we have a deep copy of its contents (edits don't shadow the original), that they do edit the original, or that folks should have a choice in the behavior. Describing this behavior succinctly will probably be difficult.

Block examples

For reference here's what these sorts of blocks look like, when they reference external sources:

Navigation Example

<!-- wp:navigation {"ref":912} /-->

Template Example

<!-- wp:template-part {"slug":"header-small-dark","theme":"twentytwentytwo","tagName":"header"} /-->

Reusable Block

<!-- wp:block {"ref":634} /-->

Compare this with another type of block like heading which is self-contained:

<!-- wp:heading {"level":3,"align":"wide"} -->
<h3 class="alignwide">Hello</h3>
<!-- /wp:heading -->

[noisysocks]

I believe that this is expected behaviour. Perhaps though we ought to make it clearer in the interface that these kinds of blocks are "pointers" to an external bit of content. The Navigation block attempts to do so via the Select menu dropdown.

[draganescu]

It is expected, but it feels unexpected. Reusable blocks are helped by their name. It's expected that if you have a reusable "thing" and you edit it, the edit will be visible across all the places where you "reused". But for the navigation block it's unclear, only from the "Select menu" toolbar item that editing it's copy changes the "original".

But I think @noisysocks has a point in that maybe the problem is the UI not changing how copy/duplicate works.

[dmsnell]

when asked to think through this I was unable to find a clear way to express the expectations. whether we assume the clones impact their source or the opposite I find that there are instant problems, problems probably not easily solvable by choosing for someone how the clone should relate.

we could give people the choice and avoid the questions about that by asking "You are duplicating this block/template; would you like for edits made to this copy to also change the block it came from? [Changes affect both blocks] [Changes only affect this copy]"

[noisysocks]

Worth noting too that reusable blocks have a few UI affordances which are intended to convey this:

• A blue outline around the block.
• A blue overlay when hovering over the block.
• When clicking the block, the name of the reusable block is shown. A second click is required to edit the content.

[dmsnell]

that's good, @noisysocks, but in the context of menus I would imagine there's a great need to not only convey when a block is a linked clone but also when to convey that it's independent. it seems like a very reasonable expectation that if you clone an entire menu and then change an item in one submenu, then the menu from which it came also gets the update. I'm imagining a site with a separate menu for each zone/group/category of the site, but all someone wants to do is move around or extend the base menu. suddenly realizing that they have to go around and make the same change to ten different menus because they disconnected when duplicating could be a big bummer.

something that's nice about giving choice I think. those blocks could remain linked duplicates until someone wants to make a change and then they could be informed about what they're about to do, vs. relying on someone to know how the system works before investing hours into their site and figuring out after all that time that they've messed things up and have to go through all the pages and check if they duplicated the same edits, or the other way, that they thought they were making separate edits but every page only shows the latest changes they made on some other unrelated page.

[carolinan]

The original behavior continues to be a problem, even if it was intended.

I have 8 templates. One of the differences is that each template has it's own sidebar with a menu, where only one menu item is the same for all templates. The menu design is the same, it has the same class names to add some CSS for styling.
But there is no way for me to copy a menu. Instead of duplicating and renaming or copying and renaming, I have to manually re-add everything.

[carolinan]

I think the copy and duplicate options should be removed.

[KennBenin]

How's this issue? Is there any fix? Cause I'm encountering this bug right now.

[MichalSeps]

2023 and this great "feature" is still there. Unbelievable...

[withtorri]

I'm still running into this issue today. My work-around as a non-coder is to save the block as a reusable section. Any duplication method I tried (saving/refreshing/renaming new feature to mismatch original) always resulted in making changes to the original. Posting for any other folks who find themselves here through a google search. ;)

[mm-rakin]

Any updates on this?

[carolinan]

No one has been able to present any ideas and suggestions for how to make it easier for users, so no.
It is not a bug. It is just quiet difficult for some users to know what the duplication does.

[draganescu]

The biggest issue for menus is that the currently sekected menu is practically invisible.

[OlaIola]

This is not only while you are trying to duplicate the Navigation, but when trying to add a new Navigation block. Possibly I am doing something wrong, and you should only have one Navigation per Header, but this is frustrating; I need a couple of them.

[carolinan]

The navigation block and the menu are two separate things.
The navigation block decides the position and the style.
The menu decides the content, the menu items.

A menu can be used in any number of navigation blocks. If you edit a menu, the menu content is updated everywhere where that menu is used.

If you add a new navigation block a menu may be assigned by default. If you want the content to be different you need to select
a different menu or create a new.

This is also how it worked with the classic menu, where you needed to select menu locations and assign your menu to the header footer, primary etc etc. The menu remains the menu, the navigation block is the menu location.