[5.x]: `ElementsController::actionSaveDraft()` clones and validates the *stored* canonical before it applies the posted form values:

[leanderklees-amimp]

What happened?

Description

ElementsController::actionSaveDraft() clones and validates the stored canonical before it
applies the posted form values:

Step	Line (5.11.3)
createDraft() — clones and validates the canonical	2028
_applyParamsToElement() — applies what the author typed	2036
saveElement() — validates again, now with the author's input	2052

If the stored element no longer validates, the first validation fails every time, regardless of
what the author submits. Correcting the offending value in the editor does not help, because
the correction is only applied after the failure. The entry becomes uneditable through the
element editor.

actionSave() (1418) does not go through createDraft() and therefore still works — but an
author has no way of knowing that the Save button is the way out.

Steps to reproduce

1. Add a Plain Text field with no character limit to a section, and save an entry with a long
   value in it.
2. In Settings → Fields, set the field's character limit below that value.
3. Open the entry and shorten the value to something valid.
4. Wait for the autosave.

Expected behavior

The submitted, corrected value is validated, and the draft saves.

Actual behavior

The autosave keeps failing on the old, stored value. The only ways out are the Save button
(which bypasses draft creation) or changing the data outside the control panel.

Combined with the swallowed exception described in the companion issue, the author sees only
"A server error occurred" and has no indication which field is at fault or that Save would work.

Related

• 'Element [id] could not be duplicated because it "doens't" validate' while re-saving entries #4958 — reported in 2019, with the correct diagnosis from the reporter: "If we tried to
  shorten that value via the CP form and save the entry, the same error occurs — maybe because
  it is trying to save a copy of the entry in its original state?" Confirmed again in 2020
  ("I can't save that entry, even if the new value is shorter"), then closed by referral to the
  Feed Me repo. At the time this was the revision path in Craft 3; in Craft 5 the same shape
  lives in createDraft().

Craft CMS version

5.11.3

PHP version

8.4

Operating system and version

No response

Database type and version

No response

Image driver and version

No response

Installed plugins and versions

[linear-code]

CMS-2422

[brandonkelly]

I can’t reproduce that. createDraft() doesn’t validate the newly-created draft entry beyond essential checks that would make it impossible to save the element in any state.