[5.x]: Duplicating content in the matrix field

[umkasanki]

What happened?

Description

After changing the propagation method param for a matrix field and then deploying it to a server in one of our projects, we got duplicate blocks of this matrix on each of the subsites.

The client removed duplicates for the current version of the subsites, but if you try to apply any old revision, the duplicates appear again.

Normal state:

Content in the revision:

Entry after trying to apply broken revision

Steps to reproduce

1. Creating a matrix field with the propagation method parameter value set to all
2. Fill some content on multiple subsites
3. Change the propagation method to none
4. Apply project changes on the another environment

Expected behavior

Revisions should not contain duplicate content.
When applying an old revision from any site, duplicate content should NOT appear in the entry.

Actual behavior

The revisions contained duplicate content.
Applying an old revision from any site resulted in duplicate content appearing in the entry.

Craft CMS version

5.8.22

PHP version

8.3.27

Operating system and version

Linux 6.6.87.2

Database type and version

MySQL 8.0.40

Image driver and version

GD 8.3.27

Installed plugins and versions

Autologin 4.0.1
Azure Blob Storage 2.1.0
Blitz 5.12.6
Blocksmith 1.7.0
CKEditor 4.10.1
Cloudflare Image Transforms 2.2.0
Cloudflare Turnstile 2.0.1
CP Field Inspect 2.0.4
Craft Commerce 5.4.8
Dumper 5.0.1
Expanded Singles 3.0.3
Formulieren 5.12.4
Mailgun 3.1.0
Mollie for Craft Commerce 4.4.0
Navigation 3.0.13
Retour 5.0.12
Sentry Logger 5.0.2
SEOmatic 5.1.19
Sprig 3.7.1
Super Table 4.0.5
Typed link field 5.0.0
Vite 5.0.1

[linear]

CMS-1772

[brandonkelly]

1. Creating a matrix field with the propagation method parameter value set to all
2. Fill some content on multiple subsites
3. Change the propagation method to none

I can sortof reproduce this going the other way around: when changing a Matrix field’s propagation method from “Only save entries to the site they were created in” (none) to “Save entries to all sites the owner element is saved in” (all), I end up with duplicated nested entries once the queue job completes. Which is expected in that case, because when entries aren’t being propagated, each site is managing its own list of entries. There’s no inter-site relation between them. And then they each become multi-site entries, so they each will exist across all sites.

That said, I’m not able to reproduce with your steps. Is there any additional info you can provide?

[Romanavr]

1. Creating a matrix field with the propagation method parameter value set to all
2. Fill some content on multiple subsites
3. Change the propagation method to none

I can sortof reproduce this going the other way around: when changing a Matrix field’s propagation method from “Only save entries to the site they were created in” (none) to “Save entries to all sites the owner element is saved in” (all), I end up with duplicated nested entries once the queue job completes. Which is expected in that case, because when entries aren’t being propagated, each site is managing its own list of entries. There’s no inter-site relation between them. And then they each become multi-site entries, so they each will exist across all sites.

That said, I’m not able to reproduce with your steps. Is there any additional info you can provide?

Hi @brandonkelly,

Thanks for the reply.

We can send you a backup copy of the database by email so you can check it. But the database is quite large, as we have many websites. Do you think it's fine at your end?

In fact, there are several cases:

1. Oleg described the first one: when saving from "all" to "none", duplicates of nested entries are created in the matrix block. I mean when you change it for an existing field with the content.
   For example, we recently added new sites, all of which have a "Homepage" with body blocks. And for no reason, we got duplicate blocks from the primary site, even though the propagation method was set to "none" at that point.

2. This is another problem we encountered AFTER cleaned-up the duplicated content.
   We have many content managers, and as soon as we deleted the duplicate blocks (manually, and then several more times programmatically), we noticed that the duplicated blocks were returning each time. Since we know that the "Drafts" system does not work very well in a multi-site setup, content managers cannot use it for the homepage (restricted programmatically), as it will revert changes on all sites.
   And this is exactly what happened when they saved their previously unsaved changes.

So, if I started editing content on the site B when I had duplicate blocks on the site A and then, say, a day later, returned to my homepage entry and saved the home page of my site B, duplicated blocks would be back on the site A.
Usually, Craft will tell you "merged changes in your version" or something like that, but in our case, that didn't happen.

[brandonkelly]

But the database is quite large, as we have many websites. Do you think it's fine at your end?

If it’s too large to send over an email, can you please try reproducing with a fresh Craft installation, and if so, use that?

[Romanavr]

But the database is quite large, as we have many websites. Do you think it's fine at your end?

If it’s too large to send over an email, can you please try reproducing with a fresh Craft installation, and if so, use that?

I will try to reproduce and if it doesn't work, will try to send a DB backup anyway.

However, another question.
I haven't found any backend changes regarding this bug (See the Screenshot), so as I understand it's something frontend related (in the build version).
Do you think any chance that could be appleid to the matrix field, not only relational?

[Romanavr]

And one more question.

The "Notes" column mentions various "Concepts" (Drafts), although no one uses Drafts (I understand that technically any pending changes are drafts, but I mean Drafts as a separate feature).

I'm just curious, how is it possible that different revisions have different "Notes" although they all are coming from one homepage?

[brandonkelly]

Do you think any chance that could be appleid to the matrix field, not only relational?

That particular bug only applied to relational fields.

Matrix fields do intentionally ensure that the owner element is a draft before creating the new nested entry, because the nested entry needs to be assigned to an owner, which needs to be a draft of the owner element. Then the owner element’s draft is re-saved once the nested entry is created and assigned to it. So it’s expected you’d see two save-draft requests when adding a new nested entry within a Matrix field.

I'm just curious, how is it possible that different revisions have different "Notes" although they all are coming from one homepage?

Sorry, I’m not really following you there. Can you elaborate?