404 pages ignoring baseURL?

support
1

My 404 page ignores my (null) baseURL - and makes everything relative to the baseURL of the (faulty) link.

Example:
https://pages.graphics.cs.wisc.edu/VisSnacks/bleet - works correctly
https://pages.graphics.cs.wisc.edu/VisSnacks/bleet/ - doesn’t work correctly because it uses the baseURL of “bleet/” and tries to access everything (such as the CSS) as being in the /bleet/ directory

If you want to see the source code: GitHub - uwgraphics/VisSnacks: Hugo Site for the VisSnacks project - this is the public facing page

Explanation:
My site uses relative URLs (this is based on superstition from years of using Hugo - it’s in my hugo.toml):

baseURL = ""
relativeURLs = true
canonifyURLs = true
enableGitInfo = true

Everything works fine, except the 404 page.

The 404 page is OK if the link is to the root directory, so https://pages.graphics.cs.wisc.edu/VisSnacks/bleet does the right thing (the relative link to the CSS is relative to the site root)

But, if the 404 page link is not in the root directory, things don’t work, so if I try https://pages.graphics.cs.wisc.edu/VisSnacks/bleet/blat, its as if the baseURL got changed to “/bleet/” (so it can find the CSS and other things because it is looking in “https://pages.graphics.cs.wisc.edu/VisSnacks/bleet/” rather than “//pages.graphics.cs.wisc.edu/VisSnacks/”

This only seems to be a problem for the 404 page. The 404 page itself has correct relative links, but somehow the browser is telling it to do something different. I think this is because it is doing things relative to the link (rather than relative to the 404 page).

Is there an easy fix for this? Can I put a base tag on the 404 page?

(a non-easy fix would be to switch to using baseURL and absolute links for the whole site, which I prefer not to do - but I don’t have a good reason).

And a minor annoyance… the 404 page seems to not get the correct date stamp from GitHub for its creation date.

2

Your baseURL should be valid, not empty.

3

I had experienced similar if a subdirectory was set in the baseURL and worked around it by adding a

<base href="{{ .Site.BaseURL }}">

in the <head> of my 404.html

As @chrillek pointed out, you need to set the baseURL for it.

4

Thanks @chrillek and @McShelby - I was going to say that #1 doesn’t work (I tried it). It breaks other things (I know there are ways to make non-null base-url work, but after years of fighting with it, I gave in and switched to using relative URLs).

@McShelby - is there a way to put something in the head of JUST the 404 page? Maybe it’s just the theme I am using, but the 404 page uses the same “baseof.html” as the rest of the pages (and setting the base tag on those would break the relative links).

5

If it’s a theme not developed by you, I would strongly encourage you to just open an issue in that themes issue tracker.

As you observed already, I strongly recommend to only use the above technique in the 404 template.

Although there might be a more elegant way, you could just put this into an if statement like

{{ if eq .Kind "404" }}
<base href="{{ .Site.BaseURL }}">
{{ end }}
6

Thanks! That’s what I needed.

But there is a different weirdness… (since you seem to understand baseURL, maybe you can explain this)…

if I use the “correct” baseURL https://pages.graphics.cs.wisc.edu/VisSnacks/, all of the links on my pages go to “./VisSnacks/foo” rather than “./foo” - which is why I have baseURL to “” (which causes other problems).

Any advice on this?

7

I have two Hugo sites running from subdirectories with baseURL pointing to the correct location. Never any problem with that. It might therefore be easier to help if you provided a link to your repo instead of tiny bits of information.

8

Thank you.

Short version: this is a deeper issue with me not understanding how RelPermalink and baseURL interact when relative links are used.

The link to the repo was in the first post… here it is again:
https://github.com/uwgraphics/VisSnacks/

As it turns out, I have many older sites that work correctly with baseURL - and I can’t figure out why this one is different. (there is a confound here - multiple things changed, and I didn’t realize what was going on - the 404 error was a Canary in the coal mine). Just because baseURL="" in the config, it does get set correctly elsewhere (I had to check that).

The listed site uses a layered theme, so it can be hard to see the problem.

I created a miniature version of the problem. I stuck this in baseof for testing:

        <p>Base URL: {{ .Site.BaseURL }}</p>
        {{- $testLogo := resources.Get "/svg/crest.svg" }}
        <p>Logo Link RelPermalink: {{ $testLogo.RelPermalink }}</p>
        <p>Logo Link Permalink: {{ $testLogo.Permalink }}</p>

If I run Hugo with a local baseURL, all is happy… hugo --baseURL https://localhost:1313/public gives (in index.html) …

        <p>Base URL: https://localhost:8080/public/</p>
        <p>Logo Link RelPermalink: /public/svg/crest.svg</p>
        <p>Logo Link Permalink: https://localhost:8080/public/svg/crest.svg</p>

Which doesn’t seem right (or, at least, it is not what I want). Although, from re-reading the documentation, it is clear that Glossary of terms | Hugo (relative permalink) is a link relative to the host, not the site (which is what I want).

The thing which is weird: this used to work just fine. (my 2021 website still works!) But something stopped working around the time I switched to using the new GH Pages build process. (the old sites still work - but they haven’t changed). There are many things that changed… I need to track down which one.

The thing which is weirded - other things (alternatives to .RelPermalink) give different (and desired) behavior.

At least now I can make the problem happen on localhost (running hugo serve over-rides the baseURL - but I can build the localhost/public version with an explicit baseURL) so I can try to figure it out.

9

I have not looked at this in detail, but this caught my attention right away:

baseURL = ""
relativeURLs = true
canonifyURLs = true

I would expect this instead:

baseURL = "https://pages.graphics.cs.wisc.edu/VisSnacks/"

There is almost never a good reason to enable relativeURLs, and canonifyURLs will be removed in a future release. Read more…

https://gohugo.io/content-management/urls/#canonical-urls
https://gohugo.io/content-management/urls/#relative-urls

1 Like
10

Don’t set baseURL to your localhost. That’s not needed, never. Just set it to “Visualization Snacks”, as @jmooring suggested. If you do that, your site is served from localhost:<port>/VisSnacks. As can be expected (I commented out the relativeURLs and canonifyURLs settings).

What do you want? Something that is not “right”? And why is “right” (as in the sense “it works”) not what you want?

That’s a repo without a theme. Or rather, with empty theme directories. Not helpful. hugo server does not even generate a home page, as there’s no template.

11

@chrillek Unless I’m missing something, the repository is functional:

git clone --recurse-submodules https://github.com/uwgraphics/VisSnacks/
cd VisSnacks
hugo
12

I didn’t use --recurse-submodules. And if I use it, I get ssh errors. I’m giving up.

13

It’s in fact simple:

  • set baseURL to the final URL you want to serve from, as @jmooring said
  • turnoff relativeURLs and canonifyURLs
  • instead of RelPermalink us Permalink to refer to you CSS etc.
  • for menu.js, use src="{{ absURL "js/menu.js" }}"

The latter might not be the best solution, but at least it got rid of the last error in the browser console.

14

Thank you!

This is 5 years of cruft building up and finally breaking. There were some historical reasons why those choices were made, and they interact with other things in weird ways. I didn’t think to get rid of the relativeURLs and canonicalURLs (since I had forgotten the reasons I used them in the first place).

The baseURL=“” thing was an artifact of bad decisions. In practice, this is set by the command line arguments that override what is here.

5 years ago, it was important for some of the sites to be portable. For now, it only needs to work on GitHub, so this works.

15

Thank you,

RelPermalink is from the original theme - and it does work. I will consider changing it. Trying to regression test these changes against a bunch of historical sites…

The original goal was to (1) minimize edits to the theme, and (2) have sites that are “portable” (you could drop it anywhere and it would just work). For now, #2 goes away for the sites that I know will be hosted on GitHub Pages.