Hugo Multilingual Multihost and Netlify

[alcarazr]

The thing is that JavaScript is trying to be loaded from the /en/ folder even though using a different baseURL

[alcarazr]

This line seems to be the culprit:

{{ $js_academic := resources.Get "js/wowchemy.js" | js.Build (dict "targetPath" (printf "%s/js/wow-core.js" .Lang ) "params" $js_params) }}

[davidsneighbour]

Yes/No. The problem is, that wowchemy.min.0e1dc40e07de343ba83181ae07edc3bd.js can’t be found so Netlify is sending a 404 error page (text/html, which is not text/javascript).

I would try different “hacks” (without knowing the complete layout:

{{ $js_academic := resources.Get "js/wowchemy.js" | js.Build (dict "targetPath" "js/wow-core.js" "params" $js_params) }}

or

{{ $js_academic := resources.Get "/js/wowchemy.js" | js.Build (dict "targetPath" (printf "/%s/js/wow-core.js" .Lang ) "params" $js_params) }}

The thing is, that you don’t have /en/ directories, because you have your own custom domain, right? so you won’t need to separate by language for the scripts. This is most probably some form of bug in the wowchemy (not a fan very complicated setup) theme. Try removing anything that looks like a language directory.

Sometimes (on the other side) there are some issues with missing slashes at the beginning of the path. That however is only the second thing to check out. Subfolders are probably the culprit.

[alcarazr]

@davidsneighbour

I would try different “hacks” (without knowing the complete layout:

Thanks a lot @davidsneighbour. Apparently that specific line was a workaround proposed by @bep to allow importing page resources in js.Build for multilingual sites. I’ve tried both solutions as well as this other option:

{{ $js_academic := resources.Get "js/wowchemy.js" | js.Build (dict "params" $js_params) }}

It’d be great if we could check whether a site is using a multihost setup or not (something like a .IsMultiHost variable. Is that possible @bep?

@davidsneighbour

The thing is, that you don’t have /en/ directories, because you have your own custom domain, right?

That’s right, and that’s where that .IsMultiHost variable would be very welcome.

@davidsneighbour

wowchemy (not a fan very complicated setup)

I agree that the initial setup may be a bit involved, but at the same time it gives users great versatility for creating a lot of different sites. George Cushen (the author) is also making great efforts to keep it up-to-date with the latest best practices and available libraries and Hugo features. I admit that my personal opinion here is quite biased, as:

1. I’m using Wowchemy to build/publish my site and I’m quite happy with it.
2. I’m one of the moderators of the Wowchemy Discord server built around the community using it.

I’ll report back as soon as I have it fixed. Thanks for all the help received, really appreciate it.

[davidsneighbour]

Just to be 100% clear (hopefully): keep the subdirectories, but the resulting domains do not have the subdirectory path due to the redirect, so links in your layouts should not have subdirectories in the pathname.

Do you have the repository somewhere public? If so we can take a look into it. Getting that working would probably be a very helpful use case for a deep dive into Hugos language abilities.

[alcarazr]

@davidsneighbour

Just to be 100% clear (hopefully): keep the subdirectories, but the resulting domains do not have the subdirectory path due to the redirect, so links in your layouts should not have subdirectories in the pathname.

I’m not sure if I understand what you’re saying here. As I’m using a multihost configuration, each language is generated with its own root, and since I have defaultContentLanguageInSubdir: false, that means my URLs do not have any language subfolder. The problem with that Wowchemy line is that is trying to get wowchemy.js from an URL containing a language subfolder (which doesn’t exist). The only thing I need is, when using a multihost configuration, change the URL so that the language subfolder is not included.

@davidsneighbour

Do you have the repository somewhere public? If so we can take a look into it. Getting that working would probably be a very helpful use case for a deep dive into Hugos language abilities.

My repo is here and Wowchemy’s repo is here.

[davidsneighbour]

@alcarazr

The problem with that Wowchemy line is that is trying to get wowchemy.js from an URL containing a language subfolder (which doesn’t exist).

So, that is a bug within wowchemy in my opinion. It should not use printf "%s/js/wow-core.js" .Lang, it should use the available language path functions:

urls.RelLangURL

urls.AbsLangURL

[alcarazr]

Thanks. As I said, that line was modified after @bep suggested it as a workaround in another thread (not sure but probably this one). Probably in that case it was being suggested for conventional multilingual sites, but in the case of a multihost configuration it needs fixing. The creator of Wowchemy is already aware of this so hopefully he’ll be able to provide a fix using the available language path functions (which should work for both configurations, multihost or not) .

[alcarazr]

@davidsneighbour

So, that is a bug within wowchemy in my opinion. It should not use printf "%s/js/wow-core.js" .Lang , it should use the available language path functions:

One thing I still don’t get @davidsneighbour. Why am I not able to reproduce that locally (with hugo server). Is there any way I can test/debug it locally? Thanks!

[alcarazr]

I can confirm that reverting these changes works in my case (multihost configuration), although not in a conventional multilingual setup (hence the changes introduced). I’ll try next to test the relLangURL approach, which should work in both configurations.