Does hugo auto-fallback to another language’s bundle images in Markdown?

support
1

Hi All-

I have an expectation question and I’m having trouble finding the answer in the docs.

I have a localized site with content like this:

/content
 /en
  /my-page/
   index.md
   my-image.png
 /de
  /my-page/
   index.md

and my content/en/my-page/index.md contains this markdown ![my-image](my-image.png) and my content/de/my-page/index.md also contains the same image: ![my-image](my-image.png).

Now what I was expecting was that hugo’s lookup order for bundled pages would first look in the localized page-bundle for de for my-image.png, not find it, then look in the global /static/images, also not find it, then look in the en page bundle, find the image and render the something like the following the resulting html: <img src="/big/long/link/to/english/myimage.png">

But that’s not what’s happening for me in hugo (0.139.4) on my site. I bisected back a few versions of hugo and it seems it’s been that way for awhile.

Before I dig in and debug more, I wanted to ask: is my expectation incorrect?

2

See Configure markup

If you have either markup.renderHooks.image.enableDefault=true or have a custom image render hook that’s looking for the image in the bundle resources, the answer to your question is yes.

3

Thanks for the reply!

I see now that I asked my question in a confusing way…I asked it two different ways (each the inverse of the other). Oops. I edited my post.

have a custom image render hook

Ok, I searched my site for render-image - which is how I think I would check if I were creating a custom render hook - and I turned up nothing.

markup.renderHooks.image.enableDefault=true

I tried this:

[markup]
  [markup.goldmark]
    [markup.goldmark.renderer]
      unsafe = true
    [markup.goldmark.renderHooks]
      [markup.goldmark.renderHooks.image]
        enableDefault = true

but it did not change the behavior.

Maybe I need to implement a custom image render hook…?

4

This would be easier to discuss with access to your project repository.

5

Agreed. The repo in question above is private, but I went to reproduce this issue for you with a public repo that shares the same theme and…I failed. That site behaves as expected. I guess I need to compare the settings of each site to see what is different.

6

Joe solved my problem in a PM.

In short: it all came down to using transform.Markdownify when I should have been using RenderString … the bug was a variation of:
markdownify resolves page resources to home instead of current page when render hooks are present · Issue #9692 · gohugoio/hugo · GitHub

7

But how would you have known to do that?
How would a theme author know not to use markdownify in a div shortcode?

On several occasions I have unsuccessfully advocated for the deprecation of the markdownify function in favor of the RenderString method. Yes, the ability convert a string of Markdown to HTML without having a page reference is handy, but you need to think carefully about what you’re doing. If you don’t, the rendered page may be incorrect without warning or error, and the problem can be difficult to track down.

My guidance is to always use the RenderString method.

1 Like
8

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.