BaseURL minor issue and ../credits/ path resolving

[jehoshua7]

I have this theme on a test site at http://example.com/hugo , yet I found in the config.toml if I had as the baseURL = http://example.com/hugo , a lot of the links had ..hugo/hugo in them, so I just have the baseURL as http://example.com

It all works fine except for the 'credits', it should be resolving to http://example.com/hugo/credits , yet it is resolving to http://example.com/credits and of course nothing is displayed. The "credits" link works fine locally, as do all links.

I notice the /credits/ path resolves correctly at https://relearn.netlify.app/credits/

This is no big deal, as I'm slowly replacing a lot of the content with the blog content for the site.

(In all cases, example.com is replaced with the real domain name)

[McShelby]

I did a quick research. Internally the theme mangles the URL thru absLangURL. This and the baseURL config option are both provided by Hugo.

Although I did not find an issue in the Hugo repo for this case, the Hugo forum may be a better place to ask for support.

[jehoshua7]

@McShelby - Thanks for looking into this. It is actually two instances of the links not resolving correctly, just under the MORE, the /showcases and /credits .

Looking at the /exampleSite/Public/index.html file , for those two links, the code generated is

<li> <a class="padding" href="https://example.com/showcase"><i class='fas fa-fw fa-camera'></i> Showcases</a> </li>

and

<li> <a class="padding" href="https://example.com/credits"><i class='fas fa-fw fa-bullhorn'></i> Credits</a> </li>

the links are hard coded, so to speak. Whereas all the other links (which resolve correctly), are of the format

<a href="./shortcodes/">

I have to make the baseURL as http://example.com , and then when testing, go to http://example.com/hugo , and then it all resolves correctly (except /showcase and /credits).

Using the /credits/ path as an example, I assume that if the code was ...

<li> <a class="padding" href="./credits"><i class='fas fa-fw fa-bullhorn'></i> Credits</a> </li>

it would resolve correctly ?

This is only an issue when I have the theme at http://example.com/hugo ; I hope to test it soon in http://example.com

[McShelby]

the links are hard coded, so to speak

You may mean, they are absolutly addressed - and that's correct.

Nevertheless, the links are generated by Hugo. It works as followed:

The theme generates the menu from inside layouts/partials/menu.html.
It looks up entries for menu.shortcuts.url in the config.toml (see exampleSite: Languages.en.menu.shortcuts).
Then it feeds the configured URL to absLangURL and prints out whatever the result is.

So basically there is no modification done to the URL by the theme itself. It completly relies on Hugo mechanisms.
Therefore this is either a Hugo or configuration issue.

[jehoshua7]

the links are hard coded, so to speak

You may mean, they are absolutly addressed - and that's correct.

Yes, absolutely.

Nevertheless, the links are generated by Hugo. It works as followed:

The theme generates the menu from inside layouts/partials/menu.html.
It looks up entries for menu.shortcuts.url in the config.toml (see exampleSite: Languages.en.menu.shortcuts).
Then it feeds the configured URL to absLangURL and prints out whatever the result is.

So basically there is no modification done to the URL by the theme itself. It completly relies on Hugo mechanisms.
Therefore this is either a Hugo or configuration issue.

Okay, thanks for explaining that.

[jehoshua7]

The BaseURL issue sorted itself out when I uploaded the theme to https://example.com

[id027102]

Same problem here .
When using without subdomain : no problems.
Using with subdomain :

• need to put relativeurl to false
• need canonifyurls to true

The problem with absLangURL is that it gives the same adress with or without subdomain , and therefore the error 404
Can fix the problem by adding subdomain in config.toml menu.shortcuts url = "/subdomain/credits" , modify menu.html or ask hugo team.

[McShelby]

Please provide your config.toml and what commandline you've used to run hugo

[McShelby]

This may be fixed with #112. Now we are using relLangUrl in all cases and hope it does the right™ thing

[McShelby]

A complete fix is available with #120 - although it's still a Hugo bug (or just awkward).