hugo: Relative links to non-page files do not include path prefix
When using the relative files feature (setting the blackfriday sourceRelativeLinksEval option to true), the generated links do not have the path prefix from baseURL included. This means the links break if the site root is not the webserver root.
As an example, say that there are three files in content:
content/pages/page2.md
content/files/image1.png
and page1.md contains the text
[link to page 2](page2.md)
and the config has baseurl = "http://mysite.com/myroot/".
Then the link to page2.md will be "/myroot/pages/page2/", while the image src will be “/files/image1.png” instead of the correct "/myroot/files/image1.png".
I figure the SourceRelativeLinkFile function needs to learn about prefixes, but I don’t know enough about the Hugo data structures to teach it…
This is with Hugo 0.16.
About this issue
- Original URL
- State: closed
- Created 8 years ago
- Comments: 25 (17 by maintainers)
Commits related to this issue
- We need canonifyURLs for image links to work. At least until https://github.com/spf13/hugo/issues/2227 is fixed. — committed to tohojo/bufferbloat-net by tohojo 8 years ago
- hugolib: Include path prefix to generated links Fixes #2227 — committed to ks888/hugo by ks888 8 years ago
@SvenDowideit This is not about using relative or absolute URLs in the markdown - this is about the links being generated in the HTML.
In the example above, it makes no difference whether I change
to- it is still going to result in a link being generated to/files/image1.pnginstead of the correct/myroot/files/image1.png. Whether the generated link is relative or absolute (according to the realtiveURLs setting), it is still going to be wrong. And the behaviour is different for HTML pages generated from markdown and for non-HTML assets.So I would request that this issue be reopened and/or @ks888 's pull request above (which fixes the problem) be merged.
Think of the process as being in two steps:
Step 1: Resolve the actual paths of the assets in the generated file tree. I.e. resolve
content/posts/testpost.mdtoposts/testpost.htmlandcontent/files/testimage.pngtofiles/testimage.png. This step is what is influenced bysourceRelativeLinksEval=true.Step 2: Produce the actual links in the HTML pages. This is affected by
relativeURLs=true, in that the relative links between two files are produced by computing relative paths between the paths generated in step 1.Now, when in theory it shouldn’t matter whether the baseURL is included in the paths generated in step 1, or if it is added afterwards. In the current code base it just happens to be included. For relative URLs, the relative positions of two files will stay the same regardless of prefix.
The issue here is that the behaviour of step 1 is inconsistent between HTML pages generated from markdown, and other file assets included in the source tree. So the HTML page paths do include the baseURL prefix, while the asset paths do not. This means that when the relative paths are computed in step 2, they are going to be wrong, and will break out of the baseurl prefix (or, if not using relative paths, the prefix will just be missing).
The patch by @ks888 fixes step 1 to be consistent between HTML pages and non-HTML assets which subsequently makes both relative and absolute URLs in links be correct.
Tested the pull request and it does indeed seem to fix the issue 😃