Usage of absURL for internal links prevents hostname changes

[VeitSanner]

Expected Behavior

When I change the hostname or DNS name of the server, all internal links of the site should still work. Hence, the usage of

<img src="/img/main/logo.jpg" alt="Hugo Future Imperfect">

is preferred over

<img src="https://example.com/img/main/logo.jpg" alt="Hugo Future Imperfect">

This behavior is needed when the generated site is promoted to a staging environment before it is promoted to the live environment.

Current Behavior

Currently, many of the internal links are generated including the baseurl value from config.toml. When the hostname changes many links break.

Possible Solution

relURL should be used over absURL.

 <link rel="stylesheet" href="{{ "css/site.min.css" | relURL }}">

instead of

 <link rel="stylesheet" href="{{ "css/site.min.css" | absURL }}">

Your Environment

Hugo Version: Hugo Static Site Generator v0.30.2 darwin/amd64 BuildDate: 2017-11-01T22:26:30+01:00

[pacollins]

@VeitSanner - This was a simple fix so I jumped the gun early, but I want to note that this has future issues within the theme. If you ever use Site.BaseURL, the site will have to be rebuilt. Other issue cases similarly persist. What are you thoughts on this?

[VeitSanner]

My understanding is that most of the site should be be working with relative URLs. So that I would be able to click through the generated site and verify that it is working. If there are some links which cannot be generated using a relative URL, that would be fine for me.

E.g. I have added JSON LD elements to provide additional information on blog posts. And here I do need the absolute URL. I believe that RSS might be another area where absolute URLs are needed. But that should be rather the exception than the norm.

[mtjandra]

Can someone let me know why we need to specify a baseurl at all? The way I see it, the baseurl should always be /, and all resources should be relative from the root site or pages your on (starting with /root/resource.png or fromhere/resource.png, with the exception of external resources.

[pacollins]

@VeitSanner - I totally agree with you in that sense. I am going to try to find more information on the intended purpose of baseURL. So that we can have a more definitive answer, because if we don't really need to set baseURL, then all of the site related, internal links should be relURL.

@mtjandra - I'm not really sure. I'm working on trying to find that information. I'm guessing its for SEO because as far as I understand absURL is better for SEO. As for it not being /, if the site doesn't stem from the root, you wouldn't want it as /.

[pacollins]

So there is a discussion that occurred on the Hugo board. It seems that .site.baseURL is antiquated, but maintained for niche use (from my interpretation) and that the easiest solution is to change all URLs (excluding dependencies) to relURL if it isn't language dependent, and relLangURL if it is language dependent.

The issue that comes with your case is any kind of data that is connected to the .site.baseURL (for example, the current Google Search) would end up broken. Now search needs to be discussed still in #65, but we need to think of any future cases that this causes an issue and how to circumvent that. The discussion gives this as an example, where the the URL must be defined and not just /:

<link rel="dns-prefetch" href="{{ .Site.BaseURL }}">
<link rel="preconnect" href="{{ .Site.BaseURL }}">

Will gladly get this fixed tonight, I just need some more thoughts and input.

The other option would be to leave it as is, and encourage people that may have this issue to use hugo --baseURL="YOUR-URL-HERE" when building via something like Netlify.

[VeitSanner]

@pacollins as far as I can see there are always going to be some links which would need the absolute URL incl. the hostname. Every URL which is provided to an external system has to be an absolute URL. That applies among others:

• Google Search Function - Otherwise it would not be possible to provide the site:example.com parameter.
• RSS - the links in RSS need to be absolute. cf. RSS 2.0 Specification
• Site Map - the URLs in the sitemap XML have to be absolute. cf Sitemaps

The resource hint you mention instruct the browser to resolve the DNS name as soon as possible, and in the case of preconnect establish a TSP connection incl. TLS handshake, cf. Resource Hints. Both apply in my opinion only to resources located under another hostname. Where as prefetch and prerender should be working with relative URLs as well. At least for prefetch there is a matching example provided.

[pacollins]

I will put together another PR with this, but that leads me to this question - does changing to relURLs solve your initial problem if functions such as RSS, Google Search, and Site Map don't work without rebuilding the site?

[VeitSanner]

@pacollins, it would be fine if some areas of the site don't work due to the usage of the absolute URL.

[pacollins]

I have created #83, would you mind reviewing that all the appropriate URLs have been changed. I think I got it all changed. I searched the directory for absURL, relURL, and href=" to try to cover them all.

EDIT: After reviewing, {{ .Permalink }} also breaks because it delivers an absURL instead of relURL. For example, this breaks blog posts.

[VeitSanner]

I revisited the Hugo page regarding URL Management and there they refer to .RelPermalink which seems to provide the permalink as a relative URL. At least it worked for me when I tested the behavior in a single place.

[pacollins]

Updated .permalink to .RelPermalink. After this update, the issue arises for all of the share links that you need .permalink. I assume this fits in the category of things you are fine with.

[VeitSanner]

Share links are provided to a third party, henc, only an absolute URL would work.

Yes, I’m fine with that.

Thanks for your quick responses.