Keep images & content together

If you don’t want to move the images into the bundle directory, you can even simply symlink it (this would work or not, depending on your OS… I have tested only on a GNU/Linux system) from inside the bundle directory.

I’ve been trying to build a section listing that can render the images from a set of pages, and coming up short since whenever I use .Content the image URLs are wrong (I get image.jpg instead of section/YY/MM/DD/image.jpg).

Any way to work around that?

Hi guys,
how to make this work with both Hugo and Github?
I have my documentation in markdown with images in the same folder. I would like to render it both with Hugo and Github…
I use Hugo V0.38 with bundles.
If I understood, I need to add some code in the markdown, such as:

{{ $logo := .Resources.GetByPrefix “logo” }}

But this won’t work with Github.

This has been deprecated. Use .GetMatch. See the Docs for more info.

Also please don’t cross post here and on Github. The Github repo issues serve as the bug tracker. This forum is for support.

@alexandros OK thanks and understood for the issue on Github.

But my question is, how do you keep compatibility with github when using code like GetMatch?
I was hoping to be able to reference my images with relative paths in markdown:

![alt text](myimage.jpg)

Page Bundles is not the same as plain Markdown syntax images.

There are 2 ways of going about it.

The shortcode way and the template way to call .Resources images.

The template way is not ideal for many images as it’s not very flexible.

The shortcode way is the most flexible and the one that is used more often and documented.

However both of these ways don’t work with markdown editors for image previews. And I suppose that this is what you mean by GitHub compatibility.

If you use plain markdown image syntax in your content Hugo will not find them if they’re not called with the above methods.

There are a couple of things you could do here but they might cost you in the long term if you have a large site.

  1. See my hack over here: Add a class to images

You can modify it to include a .Resources shortcode within the alt attribute of a markdown image.

Like this: ![{{% class %}}](1.jpg)

  1. And then perform a replaceRE to remove everything between the parentheses from .Content so that it’s not rendered when your Hugo site is generated.

It’s a bit of a sneaky and convoluted way of going about it but it would give you what you want. Markdown image previews and access to Hugo’s .Resources and image processing.

Now that was a long post…

Thanks a lot.
What I don’t understand is that the HTML code generated by Hugo seems to be compatible.
For example with these files:



![alt text](images/myimage.jpg)

This generates:

<img src="images/myimage.jpg" alt="alt text" />

The image is correctly served from

But the webpage doesn’t render the picture. Why?

It’s difficult to tell without looking at your site source.

@cdupont yes, it would help to see your source.

Note that:

 ![alt text](images/myimage.jpg)

… is different from:

 ![alt text](/images/myimage.jpg)

Here is the file in my website:

If you look at the first tag:


This image is present locally, but will not render. If I include it in /static/images, it renders.

Hello - yes, if you take a look at the html source of the web page, you can see how the path is being set. The web server will look for the image, according to how you set the path. If you put the image in /static/images then the image is available at:

When you specify a path in image markup in your markdown file, hugo is assuming it’s in static not bundling. If you want to access the image file bundled in the same folder as the markdown, you need to specify it with a shortcode. It can also be accessed via template codes from, say, your single.html.

Take a look here:

… and search for the shortcode layouts/shortcodes/imgproc.html. You could use that, to do this, or, just use simple markdown syntax and access them from within static.

This general info is relevant:

That’s not necessarily true… I have been accessing images bundled in the content dir using the regular, but slightly tweaked* figure shortcode instead of using the Markdown style image link that creates just an img tag (or resources image processing).

@cdupont If you prefer to have an img tag instead of figure, you can modify the figure shortcode to derive your own img shortcode… just ensure to leave the link-concatenation piece in there.

  • I haven’t tried, but an alternative might be to set canonifyURLs to true.

* The tweak is to just prefix the relative links in src field with the Page Permalink, so that if that image ends up in summary, the links are correct from the home page or any list page too.

I don’t find that to be the case. Standard markdown image links work fine for bundled images here …

Thanks for the corrections. I have some experiments to do then.

Do they? Last time I checked Hugo couldn’t find them.

Calling .Resources in the template without shortcodes generates the Bundle images but the markdown syntax images in a Bundle content file render as broken images in the source of the generated page.

Markdown syntax images are different from .Resources images as far as I know.

I would love for them to be the same but that is simply not the case.

As long as you canonicalize the figure link, it works…

Here’s an example from my site:

Look for the figure shortcode in the Markdown source.

I saw the figure shortcode in your markdown. It’s a shortcode not a plain markdown syntax image in the form of ![alt](some.jpg) and I thought that this is what @bluefuzz meant.

The plain Markdown image link would also work, if you create a shortcode to canonicalize the image link…

![foo]({{< canonicalize "images/bar.png" >}})

I would do that if I didn’t want to use the figure shortcode.

Haven’t tried but may be setting canonifyURLs to true also does the same, and then you might not need that shortcode.

I’ve already done that and posted about it above. My hack puts the shortcode within the angle brackets that are meant for the alt attribute of a markdown image.

I’ll try yours. I’m curious to see if the image gets rendered in an editor with Markdown preview with your version.