[5.x]: Nested entry slideout is not synced with changes in other tabs; provisional draft gets overwritten

[mmikkel]

What happened?

Description

Possibly related: #18579

We've had several cases recently where clients report that their provisional draft changes for nested entries inexplicably disappear "when they save" – and I'm pretty sure I've figured out what is really happening.

It turns out that if a canonical/current nested entry is open in a slideout, and then edited via its dedicated edit page, the open slideout in that other tab is not updated with the provisional draft changes (i.e. it stays current/canonical).

Then, if the author happens to go back to the tab with the canonical nested entry in the open slideout and clicks "Save", Craft creates a new provisional draft under the hood before applying it, which overwrites the existing provisional draft.

CleanShot.2026-03-24.at.23.03.27.mp4

When this happens, the following warning will be logged to the web.log file:

2026-03-24 15:03:45 [web.WARNING] [craft\controllers\ElementsController::actionSaveDraft] Overwriting an existing provisional draft for element/user 186/1 {"memory":2016272}

TBH, I guess this is somewhere half-way between "you're holding it wrong" and a real bug :)
But, even though the steps leading up to this behaviour can appear a bit contrived, real authors are definitely running into this. I think part of the reason for it, is that the "Open in a new tab" link in the slideout is currently the only way for authors to navigate to the nested entries' dedicated edited pages, as well as the fact

If slideouts were updated/synced when their element is edited in a separate tab (similar to how it works for dedicated edit pages), that would eliminate this problem and would be the ideal solution IMO.

But, if that's not feasible, maybe Craft could at least throw up a warning/prompt before overwriting an existing provisional draft in cases like this, giving authors the choice of what to do (sort of similar to the filename conflict dialog for assets)?

Steps to reproduce

1. Have a Matrix field using the "Cards" view mode. Create an entry in that field; save the nested entry and its owner.
2. Double-click the nested entry to open its slideout. Don't make any content edits.
3. Click the "Open in a new tab" link to open the nested entry's dedicated edit page in a new tab.
4. Make some content changes to the nested entry in its dedicated edit page. Don't apply the provisional draft!
5. Go back to the tab with the open slideout, and click the "Save" button in the slideout.
6. Confirm that the existing provisional draft with the content changes made from the dedicated edit page in the other tab, has been overwritten (i.e. hard deleted).

Expected behavior

Open slideouts should keep track of their elements' draft status, similarly to dedicated edit pages. Alternatively, authors should be given some agency before Craft overwrites an existing provisional draft in cases like this (for example, the option to merge or discard the existing draft).

Actual behavior

Open slideouts are not keeping track of their elements' draft status, and Craft silently overwrites (i.e. hard deletes) existing provisional drafts.

Craft CMS version

5.9.17

PHP version

No response

Operating system and version

No response

Database type and version

No response

Image driver and version

No response

Installed plugins and versions

None

[linear]

CMS-1920

[superflausch]

We’re seeing the same or similar recurring issue when editing nested entries inside parent entries.

What happens

When opening the parent entry, the first edit made to the nested entry saves correctly.
However, every subsequent edit appears to get lost.

I can reproduce this consistently.

Additional observations

In some cases, when editing multiple Matrix blocks within the nested entry, only some changes were saved. I’m not sure yet whether this is the same root cause or a separate issue, but it may be related.

Notes

I also recorded a short clip that demonstrates the behavior.

This is quite urgent for us, as it affects content editing reliability. It looks like the issue may have been introduced in one of the more recent updates.

I’m happy to provide additional details or help test further.

Screen.Recording.2026-03-25.at.10.10.22.mov

[mmikkel]

@superflausch FWIW, I'm not able to reproduce that behavior (and my gut feeling is that this is a separate issue from the one reported here). Have you tried reproducing it on a clean Craft install?

[superflausch]

@mmikkel Sorry for hijacking your issue 🙂 My initial thought was that, based on when this started appearing and the related symptoms around nested entries and lost content, it might be connected.

I’ve also reached out to Craft support directly and will wait for their feedback before opening a separate issue.

No, I haven’t tested it on a clean install yet, but I’ll look into that next.

[mmikkel]

@superflausch Not a problem 😊 And I could be wrong, but if anything your problem sounds more similar to #18537 IMO. The fact that I'm unable to reproduce it with a very similar content model (based on your screen recording) also suggests that your issue could potentially be something specific to your install, either due to a plugin/module misbehaving, or a data integrity problem. Which is why it'd be interesting to see if you can reproduce it on a clean Craft install, with a minimal content model and without any plugins/modules.

[superflausch]

@mmikkel I did some additional testing, and the issue persists even with all plugins and custom modules disabled.

I also set up a fresh Craft CMS install, recreated a simplified version of the content model, and was able to reproduce the issue there as well. That makes it seem less likely that this is project-specific.

It may be related to the content model structure:

Pages (Section) → Page (Entry Type) → Sections (Matrix field) → Section (Entry Type) → Blocks (Matrix / Inline Block field) → Text (Entry Type) → Text (Text field)

I also noticed console errors such as:

Invalid element UUID: 8fda05ad-9e6c-4eab-b89f-e67d392c309e

I’m not seeing that error consistently on every save, but it does show up intermittently.

Screen.Recording.2026-03-25.at.14.15.15.mov

[mmikkel]

Ouch, I'm able to reproduce that, and only on Craft 5.9.17. So most likely a regression introduced with the fix for #18537.

I still think this is a separate issue from the one I reported here, though (and arguably a more serious one). I'll make a separate issue for it, if you don't mind.

[superflausch]

@mmikkel Yeah, sure — go ahead. I can create the issue myself as well if that’s easier.

Thanks again for the help.

[brandonkelly]

The OP issue here is resolved for Craft 5.10 (via #18625).