Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

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

Open
  • Is something wrong?
#19,675 2 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
55/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
php
Domain
backend

Research direction

Start in ElementsController::actionSaveDraft(), comparing createDraft() at line 2028 with _applyParamsToElement() at line 2036 and saveElement() at line 2052; review actionSave() at line 1418 as the working comparison. Confirm the draft path validates the submitted corrected values, and verify that autosave succeeds when the stored value is invalid but the posted value is valid.

Written by the indexing model from the issue text.

Description

bug
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
  • #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
Dominant language
PHP
Stars
3.6k
Forks
705
Avg merge
15h 41m
Merged PRs (30d)
211

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from craftcms/cms

All issues in craftcms/cms

Similar issues

More PHP issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.