Anchor-only markdown links get prepended with index page path in 0.123.x

When I build Docsy and the Docsy User Guide using Hugo 0.123.0 or later (currently I’m using 0.123.6), markdown anchor-only links in index pages get prepended with the page path.

For example, consider the blog post source file:

containing anchor-only links like this:

- [Footer improvements](#footer)
- [Repository links and other page info](#page-meta)
- [Look and feel](#look-and-feel)

The diff between Hugo 0.122.0 and 0.123.6 for the HTML generated for that post is:

@@ -212,9 +212,9 @@ Footer improvements For a list of all footer improvements and fixes included in
 that has some breaking and notable changes worth calling out, namely those
 related to:</p>
-<li><a href="#footer">Footer improvements</a></li>
-<li><a href="#page-meta">Repository links and other page info</a></li>
-<li><a href="#look-and-feel">Look and feel</a></li>
+<li><a href="/blog/2024/0.9.0/#footer">Footer improvements</a></li>
+<li><a href="/blog/2024/0.9.0/#page-meta">Repository links and other page info</a></li>
+<li><a href="/blog/2024/0.9.0/#look-and-feel">Look and feel</a></li>
 <p>Thank you to all <a href="">contributors</a>!</p>
 <h2 id="footer">Footer improvements<a class="td-heading-self-link" href="#footer" aria-label="Heading self-link"></a></h2>

The repro I have now is this:

$ git clone -b chalin-im-hugo-0.123
$ cd docsy
$ npm install
$ npx hugo version # 0.123.6
$ npm run build
$ grep 'Footer improvements</a></li>' userguide/public/blog/2024/0.9.0/index.html
<li><a href="/blog/2024/0.9.0/#footer">Footer improvements</a></li>

My attempts at creating a smaller repro have so far been unfruitful, but I’ll try some more.

Anyone facing a similar issue?

One of the changes in v0.123.0 is the way we handle page resources on multilingual single-host sites:

The deduplication of page resources is a huge win, and requires markdown link and image render hooks to properly resolve link and image destinations. To address this, Hugo now includes an embedded link render hook and an embedded image render hook. You can override these as needed.

There were two implementation options for handling same-page fragment links:

  1. Just pass it through the render hook without modification
  2. Prepend the page’s relative URL

I decided to go with option 2 because it allows same-page fragment links to work when the page is rendered in another context. For example, the first sentence of a page includes a same-page fragment link, and is therefor part of the page’s automatic summary. When rendering the summary on a list page, the fragment link will properly resolve to the containing page.

If this really is a problem for you I would like to understand why.

As mentioned earlier, you can override the embedded link render hook as needed, or disable resource deduplication.

1 Like

Note that the embedded link and image render hooks are automatically enabled for multilingual single-host sites provided that resource deduplication has not been disabled in your site configuration.

For monolingual and multilingual multi-host sites, the embedded link and image render hooks are not automatically enabled, but you can enable them in your site configuration.

1 Like

@chalin When you have a moment I’d appreciate feedback on the information above. We’re trying to carefully track questions about the v0.123.x releases to make sure we’ve covered our bases. Thanks.

Hi @jmooring. Thanks for your prompt and detailed response. Apologies for the delay in getting back to you, power just came back after an 20 hr outage, and I’ve been catching up on notifications.

If this really is a problem for you I would like to understand why.

Not really a problem, more of a surprise. Now that I know that it’s by design, I’m willing to roll with it for a while. Thanks again!


Thanks for getting back to me, and be sure to let me/us know if this becomes a problem. It was an educated gamble, but a gamble nevertheless.

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