[5.x]: Applying a revision on a multi-site Single wipes Matrix/Assets fields on all other sites

[aedan-umd]

What happened?

Applying a revision on a multi-site Single wipes relational fields (Matrix, Assets) on all other sites

Description

In a multi-site install, applying a revision to a Single entry that contains site-propagated relational fields (Matrix, Assets) wipes those relational fields on every other site while leaving non-relational fields (plain text, dropdowns, lightswitches) intact. Only the site where the revision is applied retains its content.

We are able to reproduce it locally. The trigger is the "Apply revision" + Save, but is preceded by a sequence of concurrent edits across sites that puts the entry into a state where saves silently fail with only a toast ("This entry has had recent changes…") and an "User not authorized to create this element" error appears when adding new Matrix blocks.

The data loss is silent, there are no PHP exceptions, no MySQL errors, no failed jobs. Authors will see other sites' headers/navs are blank.

Steps to reproduce

Setup: a Single entry type used across multiple sites. The entry contains a Matrix field ("navigation") and an Assets field ("logo"), both propagated per-site (so each site has its own block/asset values).

1. On Site A, open the Single and delete all blocks in the Matrix field. Do not save.
2. In another tab, open the same Single on Site B and edit Matrix content (e.g. delete items in a dropdown block).
3. Return to Site A's tab and try to add a new Matrix block.
   • The block is not created; no error is shown beyond a toast: "This entry has had recent changes and the page should be reloaded."
   • Reload the page: adding a new block now works. Save.
4. Return to Site B and try to add another block (e.g. toggle on a CTA).
   • Two errors appear: "User not authorized to create this element." and "This entry has been updated. [Reload]"
   • Click Reload: all unsaved Site B changes are lost; the entry reverts to its last saved state.
   • Re-apply the Site B changes and the save succeeds.
5. On Site B, open the Revisions menu, select an older revision, click Apply, then Save.

Actual result

After step 5, every site other than Site B has all of its relational field values wiped on this Single:

• Matrix fields: empty.
• Assets fields: empty.
• Non-relational fields (plain text, dropdowns, lightswitches) on those other sites are unchanged.

Any editor with the entry already open on another site sees a "This entry has been updated [Reload]" prompt; reloading shows the now-empty fields.

Expected result

Applying a revision on one site should only update that site's content. Per-site propagated relational field values on other sites should not be affected.

Additional context

• Multi-site: 6 sites, all sharing this Single's entry type.
• The affected fields are propagated per site (not "Translation Method: Not translatable").
• No PHP, MySQL, or queue errors were logged during the production incident or the local reproduction. The only signal of data loss is the empty fields after reload.
• As a workaround we are evaluating converting this Single into a Channel (one entry per site) so the per-site data is fully isolated and not co-located in one entry's revision history.

Craft CMS version

5.9.18

PHP version

8.2

Operating system and version

DDEV on macOS and Linux

Database type and version

MySQL 8.0 and MariaDB

Image driver and version

No response

Installed plugins and versions

[linear-code]

CMS-2123

[brandonkelly]

Thanks for reporting that! I was able to reproduce the nested entry deletion issue, and just tagged Craft 5.10.3 with a fix.

If you’re still experiencing issues after updating to 5.10.3+, please send your Composer files and a database backup into support@craftcms.com and we can look into it from there.