I’ve been making a number of Hugo patches that I’ll be submitting soon. In the process, I noticed that RelURL claims to do something that it’s not.
In the docs (and comment in the code), it says
RelURL takes a given string and prepends the relative path according to a page’s position in the project directory structure.
However, it does no such thing. It’s obvious from the code, but just to make sure, I added code to a single.html template and looked at what was rendered. With this {{ "file.txt" | relURL }} in the template, I get http://site.com/file.txt no matter where the content file is in the hierarchy.
This is what it actually does - if the path is not prefixed with scheme+host (absolute path), or it’s not prefixed with “/”, then it acts as if it’s prefixed with “/”. It prefixes the language code if that’s needed, and then it prefixes the link with a “/” if one was missing. All the tests reflect this, and while you could say it’s meeting spec, I get the feeling the tests were written to make them pass, not against the spec of RelUrl as commented in the code or in the Hugo documentation.
This is also true for AbsUrl, relLangURL, and AbsLangURL. I imagine that layout creators just fiddle with things until they work.
I think it would be nifty if it actually worked as advertised. Yes, the documentation could be updated to reflect reality, but that would be less useful. However.
I bring this up because this would be a breaking change - suddenly, relative URLs would give real paths. Since I’ve noticed that layout creators are lazy (giving relative urls like “post” instead of path-absolute-URLs like “/posts”), if fixed, this would probably break a lot of themes.
There’s another approach, which I will mock up in a patch, and that’s to deprecate all these broken template functions in lieu of just “url” and “langURL”. These would do the right thing, and the documentation would be changed to note that the other ones really don’t do what they advertise.