Thanks for the improvements all over Hugo in the last time!
I am currently trying to include images automatically from either a page bundle or the assets directory. Because some images might be needed later on many pages and not only on a single one or the other way around.
For that I wrote this partial, that is called in my render-image hook:
{{ $r := "" }}
{{ with .Page.Resources.GetMatch .Destination }}
{{ $r = . }}
{{ else }}
{{ with resources.Get .Destination }}
{{ $r = . }}
{{ else }}
{{ warnf "There is no '%s' in the page resources." .Destination }}
{{ end }}
{{ end }}
{{ return $r }}
This is working for images in page bundles, but not for images in assets. I get always an error like
There is no '../../../../assets/image.jpeg' in the page resources
And I can’t get my head around this, because the image is obviously there. Otherwise the warning could not include it.
Thanks for your help! You’re right about the message, I’ll change that. I’m confused about the .Destination. The image name has been given in the Markdown, right. But there is no relative path included. I think I’m going to create an example repository for the problem as soon as possible.
When the two images are inside the page bundle everything is fine.
When you move one of them to the assets folder, the .Destination contains the URL to the image with a relative path. But resources.Get doesn’t get it. What am I missing?
Thanks for your hint to .BundleType. I didn’t know about it and will keep it in mind. For my current problem it doesn’t provide the solution, because I would like to include images from the asset dir in all kinds of pages.
git clone --recurse-submodules https://github.com/bowman2001/hugo-forum-topic-36340
cd hugo-forum-topic-36340/
mkdir assets
mv content/post/test/kitten.jpeg assets/
hugo server
When I visit http://localhost:1313/post/test/ both images are visible. What does your assets directory structure look like? Are you placing the image in the root of assets or in a subdirectory?
Yes, thanks. I am going to figure it out tomorrow. I still get WARN 2022/01/03 22:59:10 There is no '../../../assets/kitten.jpeg' in the local resources.
Do what I did (clone) and see if you get the same results. I suspect there is something different about the repo you posted and the project you are testing with.
Fresh start in the morning: I deleted the repo — which I pushed yesterday — with rm -rf. Then repeated your steps. And now it works as it was supposed to and I can move the images back and forth from assets to the bundle. The only difference to what I was doing then, which I’m aware of, is the flag --recurse-submodules. There are none in the repo, so I repeated again without the flag: still working. I don’t know, what went wrong yesterday. Kinda weird and funny.
For my actual project I’m working in Webstorm and moved an image there via drag&drop — same problem again. Then I repeated the step on a terminal — no problem at all. And this is what I was doing yesterday with the example repo. I don’t understand the problem, but the IDE seems to access the file system differently. Hugo had nothing to do with it.
Webstorm (IntelliJ) creates a file, then puts the content in, then removes the old file. It’s called something like “safe copy and move” and should be disable-able somewhere in the settings. I am pretty sure IntelliJ also works with file locks - at least from my experience with PhpStorm which is Webstorm with some PHP tools. Depending on the size of the project IntelliJ can be slowed down, which is why I switched to VSCode now.
This all in combination might irritate Hugo or be overlooked when it happens in a fast sequence. Depending on your underlying system you could write a script that on CTRL-C restarts itself again. In a Ubuntu bash shell the following command somewhere at the start of a script will be executed when somebody uses CTRL-C:
trap "{ echo 'Terminated with Ctrl+C'; }" SIGINT
(trap is part of bash and SIGINT is CTRL+C. do trap --help to learn about other signals that can be “trapped”)
Everything from echo to ; will be executed and could be (ab)used to load start the script again. I am using that to restart with CTRL+C - disadvantage, you have to terminate the shell to kill hugo and sometimes that is dirty and Hugo perseveres and needs to be killed with kill -9 hugo.