HUGO

Change file name for resized image resources

support
#1

Hi,

After using Image Processing I wondered if it would be possible to change the output/target path for the images that I resized.

Currently an MD5 hash seems to be generated with the applied filters, e.g. my <img/> srcset attribute looks like:

...
/img/thumb_hu0e8f6c739b7cc91cfbd7b7d696ff9f22_577022_720x0_resize_q90_lanczos.jpg 720w,
/img/thumb_hu0e8f6c739b7cc91cfbd7b7d696ff9f22_577022_1080x0_resize_q90_lanczos.jpg 1080w
...

I think this is the piece of code that generates the filenames. Is there perhaps a way to rename the file to a different or shorter string?

#2

No. We could possibly make them slightly shorter, but this would not work without the MD5 hash (which is fixed length).

1 Like
#3

Thank you for the reply @bep!

We could possibly make them slightly shorter … this would not work without the MD5 hash

Would the filters then be incorporated into the hash itself in order to guarantee uniqueness of a file?

#4

We encode name + content hash of the original + processing instructions into the filename. The keyword is … cache:

1 Like
#5

sorry to intrude into an old post. Is this still the case? I was trying to to create a favicon partial for apple and chrome icons and it would be nice to have a fixed name.

#6

It is not possible to customize the name of generated resources.

#7
#8

Never say never.

There is an open issue about creating a “rename function”, but I think people have succesfully used concat as a hacky workaround, e.g.:

{{ $img := $img.Resize "100x100" }}
{{ $img := slice $img | resources.Concat "favicon.png" }}

Above is totally untested.

1 Like
#9

@bep

Right. Now that you posted this I vaguely remember having seen the concat method somewhere before.

But since there is an open issue about providing the means to customize the filenames of generated resources, let me tell you that on Windows 10 I have already hit the filename character limit more than once, due to the way that Hugo generates the resources names.

Shorter filenames by default, for Hugo’s generated resources, would be preferable.

Why not use a shorter hash function like SHA-1 to generate them?

P.S. Also I am re-opening the topic for a limited amount of time in case others want to share their way of customizing the filenames.

#10
#11

This is an “soft” limit of modern Windows systems.
Help is here

Summary

Once you have Registry Editor opened, and your backup made, navigate to the location HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem and find the key LongPathsEnabled .

Double-click on LongPathsEnabled . In the Value data: field, make sure the number 1 is in there. Click OK to commit the change.

Exit Registry Editor and you should be able to work with crazy long file paths now.

#12

We use MD5 which shorter than SHA1 …?

#13

Yes, you are right MD5 is shorter than SHA1 (I stand corrected).

However still Hugo’s generated resources filenames can be too close to the Windows filename limit for comfort. Perhaps the filename calculation could happen otherwise.

I had to manually shorten original filenames so that Hugo’s generated resources do not cause problems on Windows more than once…

#14

I agree that we should fix it … I’m not using Windows regulary … Could you create a GitHub issue about it? And esp. cool if you could point to a repo where this breaks on Windows…

#15

Will do, sometime this weekend.

1 Like
#16

If change is coming, how about having the option of having a fixed custom name and a changing token like this:

http://www.domain.tld/assets/picture.jpeg?fingerprint=20210219124303

the token can be a timestamp or a hash of the timestamp or a hash of timestamp and a salt…

seems to work even on favicons as I was looking for a cash buster on this one.

The reason for a controlled asset name is that it makes content jobbing easier. The final name of the published asset is the used in the content-creation tasking.

#17

picture.jpeg?fingerprint=20210219124303 isn’t a valid filename (or at least not cross platforms). Hugo is a static site generator.

We have already a check to prevent “too long” filenames, but that is obviously not good enough.

The best we can do, I think, is something like this:

mypicture_0e8f6c739b7cc91cfbd7b7d696ff9f22.jpg

There may be ways to shorten that has, though, but I’m not sure that is needed.

#18

true, but the browser making the request doesn’t care about the file on disk. It is talking to an httpd server. The server knows about the filename and it doesn’t do cache throttling. As long as all the requests from the browser contain the query with the filename, then Bob’s your uncle.

EDIT#1: I assume it would be quite straightforward to add the logic in the .Permalink methods so it can keep state across a recompile of the static site and update references.

EDIT#2: In fact hugo doesn’t need to do much tracking. If you want to enforce cache-busting, all you have to do is add a query to any url. The browser is forced to make a request anyway. If browsers do it for favicons then I assume they do it for anything. Perhaps add a flag to the url that will instruct hugo to add a hash of the modified date timestamp to the query. hugo has to keep track of last file-modification dates for tracked files.

#19

@joeborg this isn’t about cache busting, it’s about identification. And remember that Hugo is a static site generator.

#20

as much as is practical, identification should be in the hands of the site administration. I don’t understand what is the distinction of hugo being a ‘static’ site generator. It doesn’t do a one off transformation of content. It also keeps a cache between updates to better track changes and increase efficiency. It is still dynamically generating webpages. Instead of doing it at the request of an end user or a cacheing proxy server, it is doing a sweep at the request of site admin.

The process is still very similar and is doing a lot of the same processing. Certainly more dynamic than old-school printing. You cannot get more static than sending a pdf to a printer and getting dead trees in return.

What is wrong with administrators wanting to track published assets by their filename and modified date or any other key that is meaningful to the publisher?

beware that I’m not really tied to this. That said I would like to have simple filenames. I think query part can be jury-rigged as shortcode or partial with some effort.

EDIT: it would be nice to have access to the created date and modified date in the file variables.