[v4 beta] Filename regression: uploads get an unconfigurable `-original` suffix, even without transformations or versioning

Open
  • Is something wrong?
#18,824 4 comments 0 reactions 1 assignee View on GitHub

Maintainers usually reply within 1 day

@nathanlentz is already working on this.

Since Oct 20, 2026.

  • #19210 by @nathanlentz — open

Assessment

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

Research direction

Start by reading the upload file-versioning implementation in pull request #18548 and trace how it chooses filenames when a collection has versions: false and no file transformers. Reproduce with the documents collection configuration and inspect the resulting filename and file URL. Done means the uploaded filename is preserved by default in this case, or a supported configuration option is provided while file tracking, rollback, and cleanup continue to work.

Written by the indexing model from the issue text.

Description

Bug created-by: Contributor

Below was generated by AI, but manually proof-read and vetted

Summary

Payload v4 appends -original to uploaded filenames even when:

  • No file transformers are configured.
  • Versioning is disabled for the collection.
  • The uploaded file is intended to be served directly to website users.

This changes a user-facing filename without an apparent need or a supported configuration option to preserve it.

A client uploading privacy-policy.pdf should not have that file renamed to privacy-policy-original.pdf by default.

Versions

Package Previous Current
payload 3.90.1 4.0.0-beta.1

Background

The upload file-versioning implementation (#18548) introduced retained originals and the -original filename suffix.

Keeping an original source is useful when Payload creates other representations or retains file history.

However, the suffix also becomes the normal filename when neither feature is in use. In that case, there is no processed version to distinguish from an “original”.

Reproduction

  1. Configure an upload collection with versioning disabled:

    {
  slug: 'documents',
  versions: false,
  upload: {
    mimeTypes: ['application/pdf'],
  },
  fields: [],
}

  2. Do not register any file transformers.

  3. Upload a file named privacy-policy.pdf.

  4. Inspect the resulting document’s filename and generated file URL.

Actual behaviour
Uploaded: privacy-policy.pdf
Result:   privacy-policy-original.pdf

The renamed file is the one normally linked from the website—not merely an internal backup or source copy.

Expected behaviour
Uploaded: privacy-policy.pdf
Result:   privacy-policy.pdf

Normal filename sanitisation and collision handling should still apply.

Why this matters

This is a visible change from v3, not just an internal storage detail.

For clients managing documents:

  • The published filename no longer matches the file they uploaded.
  • “Original” can suggest that another, processed or final version exists.
  • Internal file-management terminology appears in public links and filenames.

For example, a privacy policy, application form or annual report usually needs no transformation. Adding -original makes these filenames less clear without providing a benefit to the client or website user.

Configuration gap

Disabling versioning and leaving transformers unconfigured does not prevent the suffix.

We could not find a supported option to disable or customise it. Preserving an ordinary public filename should not require a post-upload rename or custom file-management code.

Expected behaviour / requested change

Preserve the uploaded filename by default when transformations and versioning are not in use.

Where Payload needs a separate retained source, its internal naming should not unnecessarily change the filename presented to website users.

If -original must remain the default, provide a supported option to disable or customise it while keeping file tracking, rollback and cleanup correct.

Dominant language
TypeScript
Stars
45.6k
Forks
4.4k
Avg merge
1d 15h
Merged PRs (30d)
280

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

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 payloadcms/payload

All issues in payloadcms/payload

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.