gohugoio / hugo

The world’s fastest framework for building websites.
https://gohugo.io
Apache License 2.0
75.81k stars 7.54k forks source link

"Remove fingerprinting" setting for hugo-processed images #9947

Open serhack opened 2 years ago

serhack commented 2 years ago

Hugo provides an Images optimizer engine that can transform/resize/compress your images and this is very helpful, especially when you have to convert your images to .webp, .png, .jpg.

The problem I faced is that the images processed by Hugo are appended with a random fingerprint which is totally fine, but not for me. Imagine for example that some websites link my (optimized) image somewhere. When I rebuild the website again, the image processed changed the fingerprint, and thus the websites that previously linked my images return 404, origin not found. I know it's a specific case, but I was just wondering if we can add a new settings to disable fingerprinting for hugo processed images.

bep commented 2 years ago

Yea, maybe.

In the next Hugo you can use resources.Copy to rename your images.

serhack commented 2 years ago

Thanks, would you mind if I ask you an example of that method?

bep commented 2 years ago

Thanks, would you mind if I ask you an example of that method?

I will update the docs before the release, but something ala:

{{ $resized := $image.Resize "400x400" }}
{{ $resized = $resized | resources.Copy "thenewname.jpg" }}
<img src="{{ $resized.RelPermalink }}">

You probably want to base the name from the original somehow, but at least it would be constant and never change.

serhack commented 2 years ago

Thank you a lot!

khayyamsaleem commented 2 years ago

For this, would it be a setting in the config applied globally under the [imaging] option? or a flag in the existing resource transformation methods?

gcushen commented 1 year ago

It appears that Tina CMS, one of the main open source CMS, can't display images from a central media library in assets/ unless Hugo supports a new config option to globally turn off Hugo's default image renaming using the image pipeline.

A global option has been suggested in the comment above and would appear to resolve this issue to enable Hugo sites to be edited in Tina CMS without issues: https://github.com/gohugoio/hugo/issues/9947#issuecomment-1143826862

bep commented 1 year ago

Unless Hugo supports a new config option to globally turn off Hugo's default image renaming using the image pipeline.

@gcushen I don't think what you talk about is what this issue is about. This issue is about having stable image URLs even when the content changes. We still need to somehow rename the images to make them unique.

How should Hugo handle the example below if we didn't add some identifier to the thumb?

{{ $image := resources.Get "foo.jpg" }}
{{ $thumb := $image.Resize "200x" }}
<img src="{{ $image.RelPermalink }}">
<img src="{{ $thumb.RelPermalink }}">
gcushen commented 1 year ago

Thanks, you're right, the Tina CMS issue is related but slightly different.

I would probably solve both these related issues like this:

Issue 1: Serve raw assets to support Tina CMS

Problem Tina CMS appears to now be regarded as the best open source CMS to use with Hugo. Tina CMS relies on the SSG to serve the media library when running Tina CMS locally. The best practice is to use Hugo's image processing to output web-friendly images, but currently Hugo does not directly serve media from the assets folder, so the media library in Tina CMS cannot display the images when run locally.

Note: for the purpose of the CMS media library, we want to serve all media in the assets folder, not only assets for a page that is published, and to preserve the original filenames when serving them. This is where this problem differs slightly to the original post above.

Solution Add a global config option, say serveRaw(Media)Assets to serve media assets from the assets folder as they are (similar to how Hugo serves images from static/). Users can then add this option to their local Hugo config, but not necessarily their production config.

This would enable users to use Tina CMS locally with Hugo themes which use Hugo's image processing (i.e. a media folder in assets/media/ rather than static/.

Issue 2: Output deterministic asset names

Problem Similar to the original post above. For example, some third party services require an image URL to be provided which is constant and does not change every time Hugo builds and appends a fingerprint to the image name.

Of course, a workaround for this issue is to put the image in the static folder but then we loose the benefits of Hugo (web-friendly image processing).

Solution Add a global config option, say deterministicAssetServing to preserve consistent filenames for published media assets.

Given the example:

{{ $image := resources.Get "foo.jpg" }}
{{ $thumb := $image.Resize "200x" }}
<img src="{{ $image.RelPermalink }}">
<img src="{{ $thumb.RelPermalink }}">

We could have a deterministic naming system for assets which appends the operations to the filename. This is somewhat similar to how many of the popular image processing CDNs name files.

So the above example could output:

Notes

Both of the above solutions could co-exist. So we could implement both config options, and they would not conflict with each other.

For example, run solution for issue 2 first. Then run solution for issue 1, checking if an asset with the raw filename has already been served/output by solution 2, and if not, add it to the list of files to serve/output.

bep commented 1 year ago

OK, then I understand.

Issue 1: Serve raw assets to support Tina CMS

On a per-project level, this can be easily solved with mounts, e.g.:

[module]
[[module.mounts]]
source = "assets"
target = "assets"
[[module.mounts]]
source = "assets/media"
target = "static/media"

Issue 2 (this issue)

I agree that that's a good idea (as an option) and it should not be too hard. There's currently a performance gain when doing repeated builds (especially running the server) with having the content hash in the URL, because it's avoid lots of IO, but I see the point of having more stable URls. I have assigned myself to this issue, as I'm doing some foundational work in this area.