Nested-nested entries go missing after root owner entry being saved; need help debugging 😓

[mmikkel]

A client is struggling with an issue where entries in a nested Matrix field intermittently disappear as they're editing content.

The setup:

This is a single-site build, with a section called "Trips". Trip entries have a Matrix field "Programs", which uses the Cards view mode and has a single entry type "Program". Nested program entries have a Matrix field called "Program Content Blocks". This field uses the inline-editable blocks view mode.

As per the client, what happens is that sometimes after they edit and save a "Trip" entry, some of the previously saved/published nested entries in the "Program Content Blocks" field in some of the nested "Program" entries, will disappear.

Details are scarce at this point and I'm unable to reproduce, so it's unclear if this is a workflow issue or an actual bug (and if so, what the prerequisite actions/circumstances are to trigger that bug) – so I'm holding off on creating an issue until I feel more confident one way or the other.

But: In investigating a "Trip" entry where this had occurred, I realised the following by comparing revisions and looking at the affected (nested) entries in the database, and I'm looking for some guidance in trying to figure out what actually happened:

• The Trip entry had a nested "Program" entry that had previously been saved and published. This Program entry had X nested entries in its "Program Content Blocks" field.
• At some point, when the client edited and saved the "Trip" entry, the nested Program entry was assigned a new ID, and the "old" nested Program entry was soft-deleted in the elements database table. The timestamp for the "Trip" entry's dateCreated revision and the timestamp for the dateDeleted column for the "old" Program entry are the same, so this definitely happened within the same request. It's my understanding that the canonical ID for nested entries should not change when editing and saving content in a normal way, including applying drafts or similar, so it's unclear to me why the "Program" nested entry somehow became essentially a different entry, when the Trip entry was saved?
• The "new" Program nested entry only has a subset of the existing nested entries in the "Program Content Blocks" field. Almost like a new "Program" nested entry was somehow created and replaced the old one, but for some reason not all of the entries in the "Program Content Blocks" field was duplicated over to the new entry.
• The "missing" nested entries are still in the database, but they now have the "old", soft-deleted "Program" nested entry as their owner instead of the "new", live "Program" entry.

One additional fact:

• The client claims they were the only one working on the entry when this occurred, and there is no evidence to support otherwise (i.e. all the recent revisions for the Trip entry were authored by the same user)

If we believe the client that they did not copy/paste/delete/do anything weird to the original "Program", but simply double-clicked it to edit it in its slideout, and then saved the root owner "Trip" entry, then I'm left with the following questions:

- In what circumstances, if any, will an existing nested entry be assigned a new ID in the elements table as a result of "normal" content editing in the CP; and the old ID being soft-deleted (i.e. it ends up with a timestamp in the dateDeleted column in the elements table)
- If that is a legitimate thing that could happen, what could be the reason for why Craft apparently fails to duplicate all of the existing nested entries in a Matrix field for that nested entry, in that scenario?

Aside from those questions: for further debugging, I'd appreciate any advice or guidance in terms of what I should look for, where I should look, specific questions to ask the client, etc. to try and figure this one out and ideally, reproduce. The client is essentially saying "I saved the trip and some of the content blocks in one of the programs disappeared" 🤷, but as I'm unable to reproduce or even imagine how that could theoretically happen, I'm kinda stumped.

[brandonkelly]

In what circumstances, if any, will an existing nested entry be assigned a new ID in the elements table as a result of "normal" content editing in the CP; and the old ID being soft-deleted (i.e. it ends up with a timestamp in the dateDeleted column in the elements table)

That will happen when applying a draft (whether normal or provisional). Any nested Matrix entries that were initially created for the draft will be duplicated for the canonical owner entry.

I’m not sure what would prevent the doubly-nested entries from being duplicated along with them, though…

[mmikkel]

That will happen when applying a draft (whether normal or provisional). Any nested Matrix entries that were initially created for the draft will be duplicated for the canonical owner entry.

@brandonkelly Circling back to this...

Is it ever expected that after saving changes to a nested entry via slideout, and then saving the owner, the nested entry will lose its original ID, and have its "Date Created" timestamp updated to the current time (i.e. the "current" nested entry now has the ID and "Date Created" attributes from the draft that was created).

Because what seems to happen here – intermittently – is that after saving edited nested entries and their owners, the nested entries will sometimes lose their original ID and "Date Created" timestamps. It looks like the nested entry drafts somehow become the new canonical nested entries, instead of Craft merging content changes into the canonical as (I think) is the expected behavior?

An example:

• Somebody edits a nested entry ID 123. Craft creates a provisional draft for it, ID 456. The author clicks "Save" in the slideout.
• The author then saves the provisional draft that was created for the owner entry. After saving that (i.e. we're looking at the current owner revision) the nested entry still appears with the ID 456, a fresh "Date Created" timestamp, and no revision history 😵‍💫

Frustratingly, I'm not even able to reproduce this behaviour. Whenever I edit and save nested entries, I always end up with those nested entries retaining their original IDs, "Date Created" timestamps and revision history, as I would expect (and no content missing, ever). But, from looking at content edited by the client, the described behaviour seems to happen a lot. And, it seems to overlap with doubly-nested entries going missing.

Really wondering if they are doing something odd when editing content that would explain what I'm seeing, or if we're dealing with some kind of data integrity issue or bug. But yeah, can you think of any circumstances where the described behaviour could feasibly occur?

[brandonkelly]

Yeah I still don’t see how that would happen, except for newly-created nested entries. When you’re seeing evidence of this happening, are you sure it’s for nested entries that existed prior to their Date Created timestamp?

[mmikkel]

Yeah, that's the thing. These are (were) definitely pre-existing nested entries. From how it looks in the database, the original nested entry has somehow been (soft)deleted, and replaced with a new one. I just can't fathom how that could happen 🫠 I'm also not sure if this behaviour is the reason for those missing doubly-nested entries, I just haven't seen that happen except in cases where the original nested entry becomes deleted, so that's where I'm digging.

Anyway, thanks again for the response – I'll follow up again if I can uncover more info or resolve it somehow.

[mmikkel]

@brandonkelly Some additional info:

From looking at the logs, we do have quite a few errors like these:

[web.ERROR] [yii\web\HttpException:400] Invalid element UUID: 243e6b3e-6497-43e5-a629-1226df09d505 {"trace":["#0 /path/redacted/vendor/craftcms/cms/src/controllers/ElementsController.php(2317): craft\\controllers\\ElementsController->_element()","#1 [internal function]: craft\\controllers\\ElementsController->actionUpdateFieldLayout()"

These could be unrelated – but based on the timestamp and other request variables, those errors definitely seem to correlate with occurrences of existing nested entries essentially being "replaced" with brand new elements.

I'm unfamiliar with the ElementsController::actionUpdateFieldLayout() action, but I am seeing it fire a lot when edit forms and slideouts are opened. I'm not able to reproduce it causing those errors though, but based on the logs that is happening a lot for the client somehow.

Curiously, I've checked a few other projects and that elements/update-field-action AJAX call never seems to fire on pageload anywhere else.

What is the purpose of the actionUpdateFieldLayout() action, and what are the missingElements it returns? Here's an example payload from an AJAX request that fires when a slideout is opened – again, not seeing anything like this for other sites w/ comparable setups. Does this all sound like expected behaviour? Is it feasible that those errors could be related to the weird behaviors we're seeing?

{
    "tabs": null,
    "missingElements": [
        {
            "uid": "a7b6f106-838e-444c-bb8d-0d5f896b03ec",
            "id": "tab01-content",
            "elements": [
                {
                    "uid": "3046c6a2-ba84-4942-bbea-683ae379b848",
                    "html": true
                },
                {
                    "uid": "6c7cbabb-1704-4b94-85f9-88e8f4c1123b",
                    "html": true
                },
                {
                    "uid": "d68971c1-3c4f-4d67-a8ed-68ea3c1630eb",
                    "html": true
                },
                {
                    "uid": "4d434584-db68-40b6-9f50-8d83c7b4d2cc",
                    "html": true
                },
                {
                    "uid": "2e7aefb6-d362-4d81-8fee-5c598f7fad92",
                    "html": true
                },
                {
                    "uid": "d45bcd34-49bc-4300-8ee0-c2d6ebd37c9c",
                    "html": true
                },
                {
                    "uid": "94d0cf50-d7dd-4e01-a620-a27153e50096",
                    "html": true
                },
                {
                    "uid": "8c62ed99-63e4-4fa9-8b27-30d228fdccb3",
                    "html": true
                }
            ]
        }
    ],
    "headHtml": "",
    "bodyHtml": "",
    "initialDeltaValues": [],
    "modelName": "element",
    "element": {
        "sectionId": null,
        "collapsed": false,
        "postDate": "2026-01-22T13:22:00+00:00",
        "expiryDate": null,
        "oldStatus": "live",
        "placeInStructure": false,
        "eagerLoadInfo": null,
        "id": 3960473,
        "tempId": null,
        "draftId": null,
        "revisionId": null,
        "isProvisionalDraft": false,
        "uid": "d4afbc35-b42a-4b53-8a7f-592fb39678e8",
        "siteSettingsId": 3960473,
        "fieldLayoutId": null,
        "enabled": true,
        "archived": false,
        "siteId": 1,
        "title": "[redacted]",
        "slug": "[redacted]",
        "uri": null,
        "dateCreated": "2026-01-23T13:58:09+00:00",
        "dateUpdated": "2026-01-23T13:58:09+00:00",
        "dateLastMerged": null,
        "dateDeleted": null,
        "deletedWithOwner": null,
        "trashed": false,
        "forceSave": false,
        "fieldId": 823,
        "sortOrder": 1,
        "canonicalId": 3960473,
        "cpEditUrl": "[redacted]",
        "isDraft": false,
        "isRevision": false,
        "isUnpublishedDraft": false,
        "ref": null,
        "status": "live",
        "structureId": null,
        "url": null,
        "primaryOwnerId": 3960472,
        "ownerId": 3960472,
        "authorId": null,
        "authorIds": [],
        "typeId": 64
    },
    "message": "Field layout updated.",
    "notificationSettings": {
        "details": "<div id=\"chip-2046382247\"...</div>"
    }
}

[brandonkelly]

elements/update-field-layout is used by Matrix fields set the “inline-editable blocks” view mode, to aid in updating their nested field layouts based on visibility/editability conditions, in a way that isn’t directly correlated with saving a draft (like most conditional fields are handled).

missingElements is the way that action (and elements/save-draft) tell JS which fields should be shown/removed/updated, based on those conditions.

[zalito12]

Hi! I'm having a similar issue with a custom element type. It can be probably an error in my side, but I have been struggling to find the root cause and I'm about to surrender.

I have a teams element related to address with a nested element manager. I follow some similar examples from the code base (cms user, commerce variants, stripe prices).

But anytime a draft team is created, the existing address disappear (after reload) from the list, and get deleted after save.

Here is the code (not all, just the related parts). Note that, if I don't provide a setAddresses I get an error trying to set a read-only property, I don't know how User element works well without any setter.

class Team extends Element
{
    /**
     * @var ElementCollection<Address> Addresses
     * @see getAddresses()
     */
    private ?ElementCollection $_addresses;

    /**
     * @see getAddressManager()
     */
    private NestedElementManager $_addressManager;


    public static function trackChanges(): bool
    {
        return true;
    }

    public static function hasStatuses(): bool
    {
        return true;
    }

    /**
     * @inheritdoc
     */
    public function extraFields(): array
    {
        $names = parent::extraFields();
        $names[] = 'addresses';
        return $names;
    }

    public function beforeDelete(): bool
    {
        if (!parent::beforeDelete()) {
            return false;
        }

        $this->getAddressManager()->deleteNestedElements($this, $this->hardDelete);

        return true;
    }

    public function afterRestore(): void
    {
        $this->getAddressManager()->restoreNestedElements($this);
        parent::afterRestore();
    }

    public function afterPropagate(bool $isNew): void
    {
        $this->getAddressManager()->maintainNestedElements($this, $isNew);

        parent::afterPropagate($isNew);
    }

    public function afterSave(bool $isNew): void
    {
        if ($this->propagating) {
            parent::afterSave($isNew);
            return;
        }

        if (!$isNew) {
            $record = TeamRecord::findOne($this->id);

            if (!$record) {
                throw new \Exception('Invalid record ID: ' . $this->id);
            }
        } else {
            $record = new TeamRecord();
            $record->id = $this->id;
        }

        // Same as element
        $record->dateUpdated = $this->dateUpdated;
        $record->dateCreated = $this->dateCreated;

        $record->maxUsers = $this->maxUsers;
        $record->domain = $this->domain;

        $record->save(false);

        parent::afterSave($isNew);
    }


    public function getFieldLayout(): ?FieldLayout
    {
        return Craft::$app->getFields()->getLayoutByType(self::class);
    }

    public function getAddresses(): ElementCollection
    {
        if (!isset($this->_addresses)) {
            if (!$this->id) {
                /** @var ElementCollection<Address> */
                return ElementCollection::make();
            }

            $this->_addresses = $this->createAddressQuery()
                ->andWhere(['fieldId' => null])
                ->collect();
        }

        return $this->_addresses;
    }

    public function getAddressManager(): NestedElementManager
    {
        if (!isset($this->_addressManager)) {
            $this->_addressManager = new NestedElementManager(
                Address::class,
                fn () => $this->createAddressQuery(),
                [
                    'attribute' => 'addresses',
                    'propagationMethod' => PropagationMethod::None,
                ],
            );
        }

        return $this->_addressManager;
    }

    private function createAddressQuery(): AddressQuery
    {
        return Address::find()
            ->owner($this)
            ->orderBy(['id' => SORT_ASC]);
    }

    public function setAddresses(ElementCollection|AddressQuery|array $addresses): void
    {
        if ($addresses instanceof AddressQuery) {
            // just unset our existing records
            $this->_addresses = null;
            return;
        }

        // Make sure each address has an owner set in case of mass assignment of team and addresses
        if (is_array($addresses)) {
            foreach ($addresses as &$address) {
                if ($address instanceof Address) {
                    continue;
                }

                if (is_array($address) && !isset($address['owner'])) {
                    $address = ['owner' => $this] + $address;
                }
            }
        }

        $this->_addresses = $addresses instanceof ElementCollection ? $addresses : ElementCollection::make($addresses);
    }

    public static function registerFields()
    {
        Event::on(
            FieldLayout::class,
            FieldLayout::EVENT_DEFINE_NATIVE_FIELDS,
            function (DefineFieldLayoutFieldsEvent $event) {
                /** @var FieldLayout $fieldLayout */
                $fieldLayout = $event->sender;

                // We only want to provide these options to our product field layouts:
                if ($fieldLayout->type !== Team::class) {
                    return;
                }

                // Add a title field
                $event->fields[] = TitleField::class;

                $event->fields[] = BillingAddressField::class;
            }
        );
    }
}

class BillingAddressField extends BaseNativeField
{
    public bool $mandatory = true;

    public string $attribute = 'addresses';

    public bool $required = false;

    protected function inputHtml(?ElementInterface $element = null, bool $static = false): ?string
    {
        if (!$element instanceof SubsTeam) {
            throw new InvalidArgumentException(sprintf('%s can only be used in subs teams field layouts.', __CLASS__));
        }

        Craft::$app->getView()->registerDeltaName($this->attribute());

        return $element->getAddressManager()->getCardsHtml($element, [
            'canCreate' => true,
            'showInGrid' => true,
            'sortable' => true,
            'pageSize' => 10,
        ]);
    }
}

[brandonkelly]

@zalito12 Probably unrelated to this particular issue (which may actually be resolved now – see #18461).

Can you send your full plugin/module files into support@craftcms.com, and give us steps to reproduce? We can try to look into it from there.

[bliswebagency]

Hello! We've been trying to investigate this problem as well.

Unusually it happened after we updated to 5.9.14 on the 3rd of March. It also happened early in Jan but the issue seemed to have been resolved after we updated to 5.9.10 until now.

Our situation is very similar to @mmikkel's. Our client was the only user in the CMS at the time and the same "Invalid Element UUID" error message is logged around the time the entries were deleted. If it helps we've included the trace below.

A brief description of our setup is that we have two main sections, a Pages and a Components. Both channels share the same content builder matrix field. The matrix builder may contain relations to one or more components.

When the error occurs while editing a Page the nested Component's content builder contents go missing. The nesting occurs at multiple levels to allow for things like 'containers' so it is a bit more complex in practice but this is the gist of our setup.

Unfortunately it is also a bit hard for us to reproduce but we can provide with further details if needed.

web-2026-03-04.log:2026-03-04 11:28:34 [web.ERROR] [yii\web\HttpException:400] Invalid element UUID: e3246b94-dbc9-4c7a-a770-d22fd20152b7 {"trace":[
"#0 /srv/gccraft-user/craft-path/craft/vendor/craftcms/cms/src/controllers/ElementsController.php(2350): craft\\controllers\\ElementsController->_element()",
"#1 [internal function]: craft\\controllers\\ElementsController->actionUpdateFieldLayout()",
"#2 /srv/craft-users/craft-user/craft-path/craft/vendor/yiisoft/yii2/base/InlineAction.php(66): call_user_func_array(Array, Array)",
"#3 /srv/craft-users/craft-user/craft-path/craft/vendor/yiisoft/yii2/base/Controller.php(197): yii\\base\\InlineAction->runWithParams(Array)",
"#4 /srv/craft-users/craft-user/craft-path/craft/vendor/yiisoft/yii2/base/Module.php(554): yii\\base\\Controller->runAction('update-field-la...', Array)", 
"#5 /srv/craft-users/craft-user/craft-path/craft/vendor/craftcms/cms/src/web/Application.php(370): yii\\base\\Module->runAction('elements/update...', Array)",
"#6 /srv/craft-users/craft-user/craft-path/craft/vendor/craftcms/cms/src/web/Application.php(665): craft\\web\\Application->runAction('elements/update...', Array)",
"#7 /srv/craft-users/craft-user/craft-path/craft/vendor/craftcms/cms/src/web/Application.php(332): craft\\web\\Application->_processActionRequest(Object(craft\\web\\Request))",
"#8 /srv/craft-users/craft-user/craft-path/craft/vendor/yiisoft/yii2/base/Application.php(391): craft\\web\\Application->handleRequest(Object(craft\\web\\Request))",
"#9 /srv/craft-users/craft-user/craft-path/craft/web/index.php(14): yii\\base\\Application->run()",
"#10 {main}"],"memory":6331048,"exception":"[object] (yii\\web\\BadRequestHttpException(code: 0): Invalid element UUID: e3246b94-dbc9-4c7a-a770-d22fd20152b7 at /srv/craft-users/craft-user/craft-path/craft/vendor/craftcms/cms/src/controllers/ElementsController.php:2644)"}

Just also adding our 'Component' section contains the Content Builder matrix inside a Content Block. We don't know if this may have something to with it. Screenshot attached for reference.

[mmikkel]

For posterity: I was never able to reliably reproduce the deeply-nested entries going missing, but I'm confident that #18461 was the underlying issue in our case, and we haven't had a single case of deeply-nested entries disappearing since updating to Craft 5.9.13 (which included a fix for that bug).