Hugo: Feature Request: Add variables for markdown syntax images

[onedrawingperday]

I have already described this feature request in the forum but decided it belongs here, in light of adding Goldmark:

• Add variables that reference/detect Markdown syntax images and their attributes e.g.:

{{ .img }} ===> ![some-alt](some-image.jpg)
{{ .img.Permalink }} ===> The .Permalink of the image
{{ .img.alt }} ===> The alt attribute
{{ .img.src }} ===> The src attributte.

---

Background.

I maintain Hugo websites that are image heavy.

The current way of handling images in Markdown content files with Hugo has some drawbacks:

• Shortcodes. These create a lock-in. There is a need to educate non-technical users to a specific syntax. Content files typically do not offer image previews in markdown editors. There is a need to use either a code editor (like VS Code), a proprietary CMS platform, or an Open Source CMS that is only available through a proprietary website. Most tools listed on the frontend section of Hugo Docs are out-of-date or unusable.

• Page Bundles. A specific file structure is required. Again there is a need to educate non technical content editors. Entering the alt attribute of an image needs to be done in the front-matter, this approach is not ideal e.g. for 15 images. It is difficult to place Page Bundle images where needed within a content file i.e. in between paragraphs.

---

The above proposal would allow for full control of markdown syntax images through Hugo templates and even make them available to Image Processing (with the relevant settings in the config).

Also this approach would eliminate the need to rely on proprietary software or a code editor for content editing in Hugo, since it will be possible to have image previews from within simple Markdown Editors. There will no longer be a need to educate non technical content editors.

The questions that remain are whether the above is feasible and whether it would hurt performance.

[bep]

{{ .img }} ===> ![some-alt](some-image.jpg)
{{ .img.Permalink }} ===> The .Permalink of the image
{{ img.alt }} ===> The alt attribute
{{ img.src }} ===> The src attributte.

I don't understand this suggestion. What would you put in the markdown file?

[onedrawingperday]

What would you put in the markdown file?

Simply: ![Sun](sun-child.jpg)

And then in the template single.html I would do:

{{ with .Content }}
{{ with .img }}
<figure>
  <img src="{{ .img.Permalink }}" alt="{{ .img.alt }}" class="some class">
  <figcaption>{{ .img.alt }}</figcaption>
</figure>
{{ end }}
{{ end }}

[bep]

OK, then I understand. What you suggest isn't possible, but I do agree that we should provide a hook/a way to template this.

I think I have droddled on this before, but I imagine we could create a new namespace below layouts, e.g. layouts/_markup and create some naming standard for these e.g. _layouts/markup/img-link.html.

[onedrawingperday]

What you suggest isn't possible, but I do agree that we should provide a hook/a way to template this.

I am already doing the above in the template of a project of mine. It's complicated but it gets the job done i.e. markdown syntax images in content are detected and then outputted with the HTML that I need, without using shortcodes. (I can share if you want to see it)

So I was kind of hoping that maybe it would be possible to have Hugo detect markdown syntax images internally and provide template variables for them and their attributes. But since it's not possible then OK...

I think I have droddled on this before, but I imagine we could create a new namespace below layouts, e.g. layouts/_markup and create some naming standard for these e.g. _layouts/markup/img-link.html.

The above seems mighty interesting. Whenever you have the time I would like to see what your above proposals look like.

[bep]

OK, then maybe I have misunderstood you.

{{ with .Content }}
{{ with .img }}
<figure>
  <img src="{{ .img.Permalink }}" alt="{{ .img.alt }}" class="some class">
  <figcaption>{{ .img.alt }}</figcaption>
</figure>
{{ end }}
{{ end }}

If the idea in the above is to just capture and list all the images in a Markdown file, then the above (or a variant) would be possible. But I fail to see the use case.

In the head, and what I drabbled about above, is something that allows me to do this to images/links in Markdown files:

• Primary to resolve URLs (i.e. add logic that looks first in .Resources, next in /assets etc.)
• Add resize, image processing etc.
• Add HTML wrapper etc.

But I do want the images to be rendered where they are placed in the document.

[onedrawingperday]

If the idea in the above is to just capture and list all the images in a Markdown file, then the above (or a variant) would be possible. But I fail to see the use case.

That is indeed the idea. The use case would be to allow for editing by non-technical people in plain Markdown using simple tools like for example Zettlr instead of proprietary CMSs or code editors

But I do want the images to be rendered where they are placed in the document.

I also want that. Currently this is possible only by using Hugo shortcodes.

My proposal would allow users to output images with complex markup without using shortcodes but plain Markdown syntax. It will also enable image previews while editing content files in any Markdown editor (this is not possible out-of-the-box with the Hugo shortcodes syntax).

In the head, and what I drabbled about above, is something that allows me to do this to images/links in Markdown files:

Primary to resolve URLs (i.e. add logic that looks first in .Resources, next in /assets etc.)
Add resize, image processing etc.
Add HTML wrapper etc.

In my aforementioned project I am also using image processing for the Markdown images in content files. I have setup the project so that the contentDir and the assetDir are the same and I am fetching the markdown syntax images with resources.Get. So what you describe (if I understood it right) is possible in Hugo as things are today.

[bep]

OK, then I get it.

[Brixy]

Hi!

If I get it, my suggestion (#6180) is related. I will close my issue.

Your proposal, @onedrawingperday, seems a lot more flexible. Thanks a lot for that.

[regisphilibert]

I think I have droddled on this before, but I imagine we could create a new namespace below layouts, e.g. layouts/_markup and create some naming standard for these e.g. _layouts/markup/img-link.html.

I think it's great idea. Not sure about the implication (how to retrieve parameters etc...) but that would help a lot. I'll gladly open an issue about it.

[onedrawingperday]

Closing in favor of: #6545