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.
Is there an issue about this in the Netlify CMS issue tracker? I.e. why should Hugo have to adapt and not the other way around?
Having images and content bundled together has lots of benefits.
I never implied that Hugo would need to adapt. I suggested the solution, so all is good.
And yes we are in agreement on the page bundling. That being said, we have a diff use case and it can be handled with no changes from either Netlify or Hugo.
We were just curious why it managed the images in the same folder and you answered the reason. Thanks.
Sure, but would it not be good if Netlify CMS could support page bundles? Would it not be bettter to work with them to get the best possible CMS?
Yes. It will at some time, but for now with the issue, there is a solution for the existing HUGO/NetlifyCMS user to handle resource image resize in their current projects.
Also: Why not use the ability of Hugo to manage resized images in multiple locations without having them copy the image to each of those locations when they do not need bundling? The answer is they don’t have to, because the solution is to access the images in a common place for that requirement. Hugo works out of the box.
I am replying to myself here.
It works all right. But the interesting part is that Hugo thinks of the symbolic link as a section.
/media/ does have its own URL and its contents are rendered even when under
/static/ or even
Now that’s interesting.
There is a known hack to disable a section’s output and naturally I’ve tried it with this /media/ folder workaround.
I’m happy to report that with the above hack
/media/no longer renders as a section and at the same time its contents are available for
But this looks like a very promising technique since it opens up Image Processing beyond Page Bundles.
A note to the above: If you make it a “index.md” (a regular page bundle), you can also have sub folders for your images.
I did a proof shortcode example here also. These are simple examples and there are a lot of ways to expand on them, so if you have any improvements let me know.
@alexandros I am curious if you put a symbolic link from
content/media/, would you now have both deployed to your
publishdir ? Then would you suggest they have the same name?
No. That would be published as
But another interesting point is that your method really depends upon
.GetPage "section" "media"
If the rendering of sections is disabled with
disabledKinds in config the only thing that is left working is that
Anyway, good workaround @talves . I might use it at some point if I need it. Thanks!
With Hugo 0.33 it’s very simple to prevent the /media/ section from getting a URL.
Simply point to an existing URL in the front matter of
This workaround has a potential downside: Hugo uses all of your CPU cores for page rendering, so what page gets rendered first might be a lottery.
If it’s pointed to the home page or a static page directly under /content/ then that is the page that is rendered first and /media/ does not get its URL.
I tested this.