Modify image types and page resources processing

How to modify image/jpg / image/png and use this type as a page resource?

Dear Hugo devs/users… I spent some time trying to configure the following case:

  • Hugo allows to process images, scale them, create caching fingerprints,
  • They are placed in the same folder as the page bundle with the image being processed,
  • Images can be processed by type.

I would like to the get following:

  • Use custom media type and output format:
  • To set the initial path for all the processed images such as: /cache/images/

According to the documentation custom output formats can have the path specified. I tried the following, with no good results:

  • Changed the sufix for the image/jpg media type to check if the extension will change after processing, or will be picked up by the .ByType method,
  • Created a custom output format with theand assigned it the image/jpg media type with both either standard or custom extension.

Unfortunately, all the images in my sample site get processed and hashed only with standard media types and extensions, and get created in their respective folders.

I would like them to be published to a specified folder - to for example be hosted with a CDN on a subdomain.
Keeping them in the bundle folder definitely makes authoring content much easier.
I was thinking if using modules / includes would work - mounting the images cache directory as another static folder would work? With the cache set as -1 - so it does not expire, that could be a bit of a solution - but how to properly generate image src’s then?

Thank you in advance for any hints…

You are mixing up quite a lot here :slight_smile:

  • Custom output formats are NOT connected to the media type of page resources.
  • Image page resources are (per now) JPG images only
  • processed images end up in their page bundle folder.

You can probably work something out where you upload the whole static site to your CDN and then replace the URL to the images to the URL of the CDN in your “real” website. But not with template files in Hugo, more like npm scripts or some other build system you prefer.

Thank you for some clarification…
While I am not a Go developer by any means, I had a quick look at the source code… And once again read the documentation…
Here are some ideas I will file as feature/enhancement requests on Github:

  • Since Hugo generates a cache of processed resources, and it looks like the file and folder structure mirrors the output of the bundles,
  • We could use the image cache logic to let the users configure something like: imageOutputPath,
  • One of the allowed values could be for example: :staticDir or publishDir just like the resourceDir and so on is referenced in teh cache configuration,
  • We need to think about the case when someone wants to keep the existing behavior - maybe use a front-matter flag?

For example:
references: img1.jpg, img2.jpg, and img3.jpg

After image processing, images would be placed in:
resourcesDir/_gen/images/post/img1…jpg and so on with file name hashes

If our mendioned: imageOutputPath was set, the generated files would be saved there, with a possible: imageOutputPrefix, which would start the path of an img src attribute and followed on with the bundle/resource names.
The resource relative and permalinks would need to be updated, but creating such paths is already in place.
Even if the pages were translated, Hugo shares resources, unless we use its mechanisms to specify language-specific files, such as: img1.en.jpg / /

Just a rough idea… I’m not a Go developer, but I know some, and if I got some hints I could help with a contribution…

I am neither a Go developer. I wonder why you are so fixated on the “cache”. I know it’s there, but it’s something that is in use between left side and right side (left side being my templates and my content and right side being the rendered website). I don’t think it’s a cache in sense of browser cache or any WP cache plugin. It’s something Hugo re-uses to save some milliseconds and it’s definitely not part of the final website.

There is no cache in your public dir after you run hugo.

Let me add a bit of clarification:

I am about generating HTML pages with their path structure, but also being able to put all the images in a particular directory…

For example:

Pages: /en/about/home.html, /en/company/services.html

And images for either of those pages to:

/images/ - without duplicating them in the /en/ folders…

I tend to split files like that to be able to set precise caching rules on Cloudflare and use, for example, their edge cache…


You might want to look into build scripts like npm to do that. I would put the images into the static folder and then prepare so Hugo would never have to resize or work on the images themself, just adding an URL to the image. Everything in static will be copied to the live site.

I don’t think Hugo can copy over images from page leafs to the static directory, so this has to be done outside of the Hugo process.

On the other side: have a look at imagemin (npm package). You can select all images in a folder (public) and then copy them optimized over to an image directory. I don’t see however how you can create proper URLs then via Hugo templates.

CC @alexandros for this. I think I remember him having a solution for this (using headless bundles maybe?)

Thanks… I will also try with new Hugo’s include modules and some path generation in the shortcodes. As long as I put all the images through a shortcode, they will be or should be created in the cache directory…
I still need to test it, but Hugo includes should work like aliases on web servers…

@PawelUrbanski I suppose that you could always set /static/ as the resourcesDir so that processed images are available even without the resource .Permalink and outside the language context.

Also if you do not want the original images published then as @zwbetz mentioned you should use headless bundles.

If you want to eliminate the _gen part of the PATH I guess that you could experiment with the new Mounts feature and see if that works (I haven’t tested yet).

1 Like

Here is the update after trying mounts feature. At the time of writing it is very fresh, so maybe I do not get it properly, or @bep will improve it over time – for he is a fantastic developer…
I wanted to achieve the following:
Let: site/ - be the root folder for a Hugo’s site/project with all the standard folders such as: content, static, assets.
I would like to map:
Content --> assets/images
I created a “test” directory under: site/ with 2 text files and mapped as a static folder to check if the files will be copied to the public directory:
Source = “test”
Target =”static”

Unfortunately, there did not get copied. The docs say that for the root/project module the mounts can be an absolute or relative directory, or a directory placed in the themes folder…
The: “test” directory is relative under: site, but after mapping the files do not get copied.
Hugo does not generate anny error or warning, so there must be something correctly, but not functionally configured…

Any hints are very welcome, for which I thank you in advance…

You can store all your images in /assets and process them from there. I’ve been doing that for a site that uses Forestry as a CMS. within /assets you can have your own storage logic and is meant exactly for this type of thing where you have unprocessed/original files which will be on the site after being processed.

Yes, that is true, and it works as I give or take want it…The idea I got is the following:

  • Keep images in the bundle folders,
  • Mount “content” under assets/images,
  • Have a shortcode that concatenates the path:
  • Images/.Dir/<image.jpg>

It is definitely a hack or a workaround… I will look into Hugo’s sources, for maybe it would be possible to add a path prefix in the image processing section of a configuration file? Something as a feature for later… If page resources from the bundles could be treated as output formats we could just overwrite the defaults… Or I just guess…

For the simpler landing-page sites, I will definitely move images into the assets folder…