Add support for URLs relative to context root

[jbenet]

Try as I might, I cannot figure out how to get hugo to stop making urls absolute, and use only relative urls. I've set:

canonifyurls = false

in config.toml and removed the default baseurl directive. (The generated html files do not get a <base> html tag.) But hugo continues to make all urls absolute:

<a href="/post/0-hello-worlds/">(read more)</a>

instead of a relative

<a href="./post/0-hello-worlds/">(read more)</a>
<a href="./0-hello-worlds/">(read more)</a>

If you need motivation (in case you ask "why are you doing this?"): many static website use cases cannot predict what url they will be hosted at, and MUST work with only relative urls. For example, a content addressed static host (say, using hash-trees to make the resulting hierarchy content addressed) would place the generated site at <domain>/<base hash>/. Obviously, the hugo site could know its hash a priori :)

[bep]

I guess the term relative is ... relative.

[insanity54]

@jbenet What does your content source look like? I guess I'm confused as to how you're feeding the links into hugo.

I set canonifyurls = false, and removed the default baseurl directive in config.toml.

I'm able to get a relative link by rendering this markdown:

+++
date = "2015-05-05T07:17:44-07:00"
draft = true
title = "fart"

+++

[carrot rel](./assets/carrot.jpg)
[carrot abs](/assets/carrot.jpg)

[jbenet]

@insanity54 setting canonifyurls = false and without any baseurl directive (how did you remove the default?) i still get generated links to posts like:

<a href="/post/0-hello-worlds/">(read more)</a>

@insanity54 when you built, how do the links to the first post look in public/index.html ? I get:

<h3><a href="/post/0-hello-worlds/">Hello Worlds</a></h3>
<span>2015-05-05</span>
<p><pre><code class="language-sh">&gt; echo &quot;hello worlds&quot; | ipfs add
added QmZ4tDuvesekSs4qM5ZBKpXiZGun7S2CYtEZRB3DYXkjGx
&gt; ipfs cat QmZ4tDuvesekSs4qM5ZBKpXiZGun7S2CYtEZRB3DYXkjGx
hello worlds
</code></pre>

<p>Greetings Internet!</p>

... abridged ...

<div class="read-more-link">
  <a href="/post/0-hello-worlds/">(read more)</a>
</div>

note the /post/...

[jbenet]

To clarify, my issue here is not with links i make inside posts, it's with links hugo generates to posts from lists and so on. They are generated absolute, which simply do not work at all with many kinds of static hosting where the final location is not known at compile time. (e.g. content addressing/content hashing).

[bep]

@jbenet what you want isn't currently supported in Hugo. The definition of relative in Hugo is "relative to the domain root", but includes the context-root.

So for site hosted at "http://mydomain.com/site" a relative URL will look like "/site/css/somecss.css".

"css/somecss.css" would be relative to the context-root, but that would only not work when used below "/mysection".

[insanity54]

@jbenet when I followed the quickstart guide and did $ hugo new site ., it generated a config.toml file:

baseurl = "http://yourSiteHere/"
languageCode = "en-us"
title = "My New Hugo Site"

I just removed the line with the baseurl directive. (I was guessing that was what you did)

Ah I see what you're saying. Not links insite the post, but the links on the index to the post. In that case, I'm getting the same as you.

    <h1 class="post-title">
      <a href="http://localhost:1313/post/neu/">
        neu
      </a>
    </h1>

[jbenet]

@jbenet what you want isn't currently supported in Hugo. The definition of relative in Hugo is "relative to the domain root", but includes the context-root.

Could you explain to me what would be involved in adding support for this? I can see if I can PR. (IMO, lack is brittle)

[bep]

• If you set canonifyurls = false you shouldn't see any absolute URLs (in my definition of it) if not set explicit in the template.

But to get to where you want, I'm not sure.

URL creation isn't as "in one place" as I would want, but even if it was, your problem is contextual (a page's URL should be different when rendered on the home page, ./section/post vs ./post). To put it simply, Hugo renders a given page once, then reuses that same content in different contexts. So you may fix the metadata methods to answer differently, but not the bytes in the rendered page.

At first thought, you would think that you could expand on the mechanism used for canonifyurls. If you replace baseurl below with ./ you will in theory get correct result for the top level node.

https://github.com/spf13/hugo/blob/master/transform/absurlreplacer.go#L270

But it will fail further down.

I may come up with a better idea later.

[wking]

The way I've seen this worked around in Jekyll is to declare the per-page relative URL pointing to the root path (e.g. . from the root directory and .. from a subdirectory), and then to use those references when linking a resource (e.g. here).

I think that's a sound approach, but it would be great if the static generator could automatically calculate the relative path from a given page to the site root. In Hugo's case, this will depend on the ugly URLs setting. That should be pretty easy with Rel.

[bep]

Sure, the Page knows its normal place in the hierarchy. Adjusting Page.RelPermalink would go a long way, but ...

In Hugo it's also possible to use a Page in other sections (mostly on the home page).

[wking]

On Thu, May 07, 2015 at 05:01:41AM -0700, Bjørn Erik Pedersen wrote:

Sure, the Page knows its normal place in the
hierarchy. Adjusting Page.RelPermalink would go a long way, but
...

In Hugo it's also possible to use a Page in other sections (mostly
on the home page).

So you'd have to re-render that Page using it's new context for
constructing relative links. That doesn't seem too difficult…

[jbenet]

Yeah, i think that would work

[bep]

Most things are doable, but it's not a one-liner change, either.

[jbenet]

Thank you @bep

[doesntgolf]

The relative URL-ifier doesn't seem to kick in on the action attribute on form tags.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.