Bugfix/16640 drafts and propagation

[i-just]

Description

1. Don’t set the initial delta value for the Link field with an empty value, as that will cause the field to get marked as modified even if it wasn’t (e.g. if you change the value of a different field)
2. If you edit an entry nested in a matrix field and then propagate the parent element to another site, only the edited nested entry was propagated to the new site (in the blocks and cards view modes).

Steps to reproduce:
on a clean installation:

• set up at least 2 sites (siteA, siteB)
• create a Plain Text field (plainText)
• create a myEntryType entry type; it should have the default title field and the plainText
• create contentBuilder Matrix field, entry type: myEntryType; view mode: inline-editable blocks; propagation: all
• create a section (e.g. blog) with an entry type (e.g. article) containing the default title field and the contentBuilder field; enable that section for both sites; propagation method: let each entry choose
• create an entry in the blog section for siteA; add two myEntryType “blocks”, populate the title and plain text for both; fully save the entry;
• edit the entry again, edit plainText for one of the “blocks”, then, under “status”, enable it for siteB and fully save
• go to siteB and observe that only the edited “block” was propagated

Note: this was also happening if you turned off autosaving drafts

The issue was further exacerbated by an empty Link field as those were getting marked as modified even if they were not.

It’s also reproducible with a matrix field in cards view mode.

Related issues

#16640

[brandonkelly]

Nice job!

I was curious why this wasn’t a bug in Craft 4.

Turns out it was, just harder to reproduce: with the same setup, you have to modify a Matrix block’s nested field and add a new site before the draft gets autosaved. The easiest way to reproduce is using JavaScript. With the Status field expanded to show the site select input, and a Matrix block’s nested Plain Text field selected in the DOM inspector, you can run the following JS code:

$($0).val('edit');
$('[aria-labelledby="add-site-label"]').val('2').trigger('change');

And then the same buggy code path will occur, and only the modified Matrix block will get propagated to the new site.

So I cherry-picked the Matrix fix into 4.x (3c692b4).

Then I looked into why the Matrix field’s delta data was getting submitted on both autosave requests in Craft 5, but only the first autosave request in Craft 4 (when editing the entry at a normal human speed).

That turned out to be due to a0e98b3: when we’re passing this.$container.data('modified-delta-names') to Craft.findModifiedDeltaNames(), the array is passed by reference so Matrix sub-field’s delta name ends up getting appended to this.$container.data('modified-delta-names') and then gets tacked on to each subsequent save request. So the modified delta names get added onto each time you edit a new field, rather than each autosave only posting the fields that have changed since the last autosave, like it’s supposed to work.

That core bug sortof exists in Craft 4 as well, although it’s inconsequential there. So I fixed on 4.x as well (fbe700f).

That leaves just the Link field bug. I’m not sure why we were calling setInitialDeltaValue() for that field, and not seeing any negative side effects from removing it, so went ahead and merged that change too.