Thanks to visit codestin.com
Credit goes to github.com

Skip to content

resizeOptions ignore withoutEnlargement/fit for original file on *update* #12280

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
dreamy32 opened this issue Apr 30, 2025 · 7 comments · May be fixed by #12291
Open

resizeOptions ignore withoutEnlargement/fit for original file on *update* #12280

dreamy32 opened this issue Apr 30, 2025 · 7 comments · May be fixed by #12291
Assignees
@PatrikKozak

Comments

@dreamy32
Copy link

dreamy32 commented Apr 30, 2025 •
edited
Loading

Describe the Bug

This appears to be an issue related to PR #10078 which fixed applying resizeOptions to the original file on upload.

While the fix correctly applied resizeOptions to original files during initial upload (create), when updating/replacing an existing image, the constraints withoutEnlargement: true and fit: 'inside' are ignored, though other resizeOptions like width are still applied.

This leads to smaller images being inappropriately enlarged when they shouldn't be. For example, an image file with dimensions such as 512x512px results in it being saved as 6000px wide if resizeOptions.width: 6000 is set, despite having withoutEnlargement: true. (DURING UPDATE)

The current workaround is to remove the top-level resizeOptions, but this prevents us from downsizing large images, which was the intended purpose of PR #10078. We need both behaviors: downsizing large images while preventing small images from being enlarged.

The issue occurs with this configuration when updating an image:

// collections/Media.ts
// ...
  upload: {
    staticDir: 'media',
    imageSizes: [ /* ... */ ],
    resizeOptions: {
      width: 6000, 
      height: undefined,
      fit: "inside", // Ignored on update for original
      withoutEnlargement: true, // Ignored on update for original
    },
    mimeTypes: ['image/*'],
  },

Link to the code that reproduces this issue

See above snippet. (or see this gist for full Media collection: Media.ts

Reproduction Steps

  1. Configure a Media collection with the upload settings above.
  2. Upload an initial image (below the defined resized width e.g. 512x512).
  3. Edit the uploaded media document in the admin interface, and apply.
  4. Save the changes.
  5. Inspect the newly uploaded original file.
  6. Expected behavior: The new original file should retain its dimensions (512x512px) due to withoutEnlargement and fit.
  7. Actual behavior: The new original file is enlarged to resizeOptions.width (6000px wide).

Which area(s) are affected? (Select all that apply)

Not sure

Environment Info

Payload: 3.18.0
Node.js: 22.13.0
Next.js: 15.1.7
@dreamy32 dreamy32 added status: needs-triage Possible bug which hasn't been reproduced yet validate-reproduction Auto-added tag on create to tell bot to check recreation URL, removed after check. labels Apr 30, 2025
@github-actions GitHub Actions
Copy link
Contributor

Please add a reproduction in order for us to be able to investigate.

Depending on the quality of reproduction steps, this issue may be closed if no reproduction is provided.

Why was this issue marked with the invalid-reproduction label?

To be able to investigate, we need access to a reproduction to identify what triggered the issue. We prefer a link to a public GitHub repository created with create-payload-app@latest -t blank or a forked/branched version of this repository with tests added (more info in the reproduction-guide).

To make sure the issue is resolved as quickly as possible, please make sure that the reproduction is as minimal as possible. This means that you should remove unnecessary code, files, and dependencies that do not contribute to the issue. Ensure your reproduction does not depend on secrets, 3rd party registries, private dependencies, or any other data that cannot be made public. Avoid a reproduction including a whole monorepo (unless relevant to the issue). The easier it is to reproduce the issue, the quicker we can help.

Please test your reproduction against the latest version of Payload to make sure your issue has not already been fixed.

I added a link, why was it still marked?

Ensure the link is pointing to a codebase that is accessible (e.g. not a private repository). "example.com", "n/a", "will add later", etc. are not acceptable links -- we need to see a public codebase. See the above section for accepted links.

Useful Resources

@github-actions github-actions bot removed the validate-reproduction Auto-added tag on create to tell bot to check recreation URL, removed after check. label Apr 30, 2025
@PatrikKozak PatrikKozak self-assigned this Apr 30, 2025
@github-actions github-actions bot removed the status: needs-triage Possible bug which hasn't been reproduced yet label Apr 30, 2025
@dreamy32
Copy link
Author

@PatrikKozak I brought modifications to the post, my example was misleading. I asked Github Copilot to do the ticket for me, I had to finish my shift earlier. If you need further details, I am at your disposition.

@dreamy32
Copy link
Author

dreamy32 commented May 1, 2025

Look the following video for the full reproduction of the issue:

2000.image.converted.to.6000.on.update.mp4

@PatrikKozak
Copy link
Contributor

Hey @dreamy32! Thanks for all the details and video reproduction - this is very helpful and I'll be working on a fix for this today

@dreamy32
Copy link
Author

dreamy32 commented May 1, 2025

Thanks Patrik for your fast and full commitment to this issue. Our team at Auto-Canada is very grateful!

@PatrikKozak PatrikKozak linked a pull request May 1, 2025 that will close this issue
Open
@PatrikKozak
Copy link
Contributor

@dreamy32 I've opened a PR for this here but going to be doing some additional testing here to avoid any "gotchas"

@dreamy32
Copy link
Author

dreamy32 commented May 5, 2025

I answered on the PR: New issue arised following PR

@dreamy32 I've opened a PR for this here but going to be doing some additional testing here to avoid any "gotchas"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@PatrikKozak PatrikKozak

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

fix: prevent resizing of original file with withoutEnlargement on update payloadcms/payload
2 participants
@PatrikKozak @dreamy32