Skip to content
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.

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

[Feature] Drop Image MD5 values from image names #53

Open
akshay-ranganath opened this issue Aug 30, 2023 · 1 comment
Open

[Feature] Drop Image MD5 values from image names #53

akshay-ranganath opened this issue Aug 30, 2023 · 1 comment
Assignees
Labels
question Further information is requested

Comments

@akshay-ranganath
Copy link

akshay-ranganath commented Aug 30, 2023

Feature Request

When an image is created through static rendering, it includes the actual image prepended to a MD5 of image. For example, an image bird-8172597_1280.jpg is uploaded to Cloudinary as bird-8172597_1280-725f0013dd4d83931bd8e4036f727dac.jpg. Consider dropping the value after the last - so that the image name is retained.

Is your feature request related to a problem? Please describe.

Describe the solution you'd like

Describe alternatives you've considered

Additional context

@akshay-ranganath akshay-ranganath changed the title [Feature] Drop UUID / GUID values from image names [Feature] Drop Image MD5 values from image names Aug 30, 2023
@colbyfayock
Copy link
Collaborator

@akshay-ranganath it's been a little bit since I wrote that, but I think the original intent of this was to help preventing duplicate uploads but also allow an image to be uploaded again if the file changed. couple scenarios for instance:

  1. /images/image-1.jpg is created, uploaded, and never changeed, so the ID is retained, and using overwrite:true, the file doesn't get re-uploaded as the public ID already eixsts
  2. /images/image-2.jpg is created, uploaded, 1 week later changes, so the ID changes and the file is reuploaded so that the project delivers the new version of the image

any thoughts on that?

i was also considering the idea of seeing if we could utilize a caching mechanism, which could theoretically replace this, which would store the hash references for the files to avoid even having to do a lookup network request in the first place. i haven't explored this much yet as I'd also have to find a reliable way to do that between builds, but could be a way to avoid the custom public ID if that's frowned upon

@colbyfayock colbyfayock added the question Further information is requested label Oct 4, 2023
@colbyfayock colbyfayock self-assigned this Oct 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants