Is it possible to use Hugo 0.32’s new image processing feature for images in other folders?
For example, I have a site that is already structured in a format with all media in a separate /content/images folder, instead of beside each entry as a page bundle.
Image Processing is available for Page Bundles. You need to restructure your content.
I made a simple example repo of this Here and also answered your SO here
In summary, it is possible to access a sections image resources from another page or location in the content.
Add a content/images/_index.md file to be able to access the section (not sure if this is optional or not) then access the section for the resources inside your layout templates. You should also be able to access them from within a shortcode similar to in the docs.
{{ $page := . }}
{{ with .Site.GetPage "section" "images" }}
{{ with .Resources.GetByPrefix $page.Params.imagename }}
{{ $image200x := (.Resize "200x") }}
{{ $image400x := (.Resize "400x") }}
<img src="{{ $image200x.RelPermalink }}">
<img src="{{ $image400x.RelPermalink }}">
<br />
{{ end }}
{{ end }}
Interesting workaround. But you will get a /images/ URL published with this set up.
Yep, small price to pay. I would just redirect it anyway.
I do think there are some issues with the local hugo server, but need to test it out. Published site works like a charm, so no problem there.
Opinion: I would have liked this to be a static dir location rather than just requiring them to be in a pages resource location. I see no advantages to not having a resources static location for images, etc., but maybe it is a requirement of the way go is handling them.
Nice, that workaround works. I was also able to add, at the top of my baseof.html file,
{{ $.Scratch.Add "media" ((.Site.GetPage "section" "media").Resources) }}
so that I can get the resources from any template file:
{{ range ($.Scratch.Get "media").ByType "image" }}
Exactly, you could also make the media location a .Site.Params value in your congif.toml and change it easily for a template.
@alexandros Like @talves suggested above, is there any technical reason why media cannot be stored in a separate folder by default, or is this simply a decision?
I guess in this solution we are setting up a media folder location for the image resources to be accessed from within the templates. I am happy with this requirement at the moment. It solves all my needed use cases.
@tech4him I think it has something to do with the Resources context of the image file to be able to get the parameter values from a resource, but @bep or others will definitely know better.
Not sure if you know, but you can access the exact width and heigth of an image resource.
Yes, I’m fine with using it as you’ve explained. I’m just wondering if this was a technical consideration, or simply a new structure that the Hugo team sees as more useful in the long run.
I am not Hugo’s Dev. So I cannot answer this for you.
But as @talves said below I also think that there were context issues to consider as well as backwards compatibility for existing Hugo projects .
@tech4him and @talves Hugo 0.32+ also supports folder symbolic links.
I haven’t tested them yet, but I would think that you can use this to store your media library under /static/ and have its symbolic link under /content/
Let me test the symbolic links in this solution.
If you got this working with a symbolic link then please do share.
Not sure what Go has to do with it. What you want can be done in any programming language.
But Hugo isn’t an “image gallery software”.
Hugo is all about content management. The images are tightly connected to page bundles in many, many ways. This does not work without them.
Apparently he developed a workaround to use Image Processing outside Page Bundles by using a /content/media folder for images . I haven’t tested it yet. But it seems interesting.
Yes, that is cool. And there is an open issue about “pages that should not render”, which I guess also would improve this.
Aha. So that Github issue is related. Thanks. Good to know.
Yeah, This I understand. Just discussing the alternative use cases as in the example of Netlify’s CMS requirements to manage a media folder in one place.