Problem/Motivation

Resuming a draft with an uploaded file now forces a re-upload — It looks like Webform's newer file-upload check in 6.3.1/6.2.12 only accepts a file if it's still marked "temporary," but any file attached to a saved draft gets marked permanent (so Drupal doesn't delete it as a stale temp file). So the next time you resume that draft, its own file fails the check.

Also, saving a draft with an uploaded file throws a PHP error Uncaught PHP Exception LogicException: "Form errors cannot be set after form validation has finished."

The check that's rejecting it, as far as I can tell:

$is_invalid = (!$file || !$file->isTemporary() || !$file->access('download'));

Steps to reproduce

  1. Use a webform with a managed_file element and drafts enabled, regardless of role.
  2. Upload a file, save as a draft.
  3. Resume the draft.
  4. Save again (or complete it) without re-uploading the file.
  5. You'll get "The uploaded file is invalid" — the file is cleared and has to be re-uploaded.

Proposed resolution

I put together a patch (attached) that also allows the file through when it's already attached to the submission being edited, using file.usage to check that instead of just isTemporary(). It seems to fix the issue on the sites I tested it on, and a file that belongs to someone else's submission still gets rejected. I don't write a lot of backend PHP day-to-day, so if there's a cleaner way to do this, I'm happy to be corrected.

Remaining tasks

Review and check from maintainers if this is the right solution.

User interface changes

None

API changes

None

Data model changes

None

CommentFileSizeAuthor
#15 SCR-20260930-nmdq.png183.16 KBarno_vgh
#15 SCR-20260930-nlcs.png269.21 KBarno_vgh

Issue fork webform-3625496

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

erindarri created an issue. See original summary.

erindarri opened merge request !947

erindarri opened merge request !948

mingsong’s picture

mingsong
Location 🇦🇺
commented

I came across this issue as well.
Core version: 11.4.5

The result of this issue is the 500 error (WSOD).

mingsong’s picture

mingsong
Location 🇦🇺
commented

More details of how to reproduce it with a clean Drupal installation.

Setup (once, as admin)

  1. Create a webform, for example "Test form", and add a File element.
  2. Open Settings → Submissions → Draft settings. Set "Allow your users to save and finish the webform later" to Authenticated users, then save.

Case 1: the crash (white screen)

  1. Log in as any user who can submit the form.
  2. Open the form and upload a file.
  3. Click Save Draft.

Result: a white screen with a 500 error.

Case 2: the rejection (continues from case 1)

  1. Open the form again. The saved draft loads with the file attached.
  2. Click Submit.

Result: the error "The uploaded file is invalid." appears and the file is removed from the field.

Error in the logs:

Log entry: Uncaught PHP Exception LogicException: "Form errors cannot be set after form validation has finished."

Note: the draft is saved despite the white screen. It appears under the form's Results with the file attached.

arno_vgh’s picture

arno_vgh
Primary language Dutch
Location Antwerp
commented

I encountered the same issue as described in case 1 of comment #5: saving a webform submission with uploaded file(s) as a draft resulted in an error.
MR #947 fixed the issue for me. Thanks!

liam morland’s picture

liam morland
Primary language English
Location Ontario, CA 🇨🇦
commented
Version: 6.3.1 » 6.3.x-dev
bkosborne’s picture

bkosborne
Primary language English
Location New Jersey, USA
commented
Priority: Normal » Major

Also running into this. Raising to major as I suspect this is impacting a lot of people that may not even know it yet.

bkosborne’s picture

bkosborne
Primary language English
Location New Jersey, USA
commented
Status: Active » Needs review

That MR is a good start. There are two issues though that I commented on. I resolved them and pushed another update along with tests. Full disclosure: GPT-6 SOL wrote this code, though I did review it and test it myself to ensure I understood it.

bkosborne’s picture

bkosborne
Primary language English
Location New Jersey, USA
commented

Also I didn't update the MR for 6.2.x yet. I can do that if we're good with the 6.3.x MR

bkosborne’s picture

bkosborne
Primary language English
Location New Jersey, USA
commented
Issue summary: View changes
bkosborne’s picture

bkosborne
Primary language English
Location New Jersey, USA
commented

The original steps to reproduce, I can't even get that far without a fatal error thrown as described in comment #5. Could be a difference in Drupal core versions or something.

bkosborne’s picture

bkosborne
Primary language English
Location New Jersey, USA
commented

Thanks for the review, I addressed the feedback by improving the comments.

partyka’s picture

partyka commented
Status: Needs review » Reviewed & tested by the community
arno_vgh’s picture

arno_vgh
Primary language Dutch
Location Antwerp
commented
StatusFileSize
new SCR-20260930-nlcs.png269.21 KB
new SCR-20260930-nmdq.png183.16 KB

I've re-tested this with the latest changes from MR #947, and it works as expected for a file element that only allows a single file.

I also tested the same scenario with a file element that allows multiple files.
When uploading more files than the configured limit, a warning is shown indicating which files were skipped due to the limit. However, the files that were accepted and successfully uploaded are not saved to the draft submission. After resuming the draft, those files are no longer available.

Screenshot file limit warning

Steps to reproduce

  1. Create a file element with a cardinality limit, for example 2.
  2. Upload more files than the configured limit.
  3. Save the submission as a draft.
  4. Resume the draft submission.
  5. Notice that the files which were accepted and not skipped are no longer available.

Let me know if this should be tracked in a separate issue

bkosborne’s picture

bkosborne
Primary language English
Location New Jersey, USA
commented
Status: Reviewed & tested by the community » Needs work
bkosborne’s picture

bkosborne
Primary language English
Location New Jersey, USA
commented

Ah yeah. Verified. That's an interesting test case - I wouldn't have thought to test that scenario!