Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Broken JS and CSS paths with hugo serve since Hugo v0.123.0 #2053

Open
4 tasks
mlange-42 opened this issue Jul 10, 2024 · 8 comments
Open
4 tasks

Broken JS and CSS paths with hugo serve since Hugo v0.123.0 #2053

mlange-42 opened this issue Jul 10, 2024 · 8 comments
Labels
bug Something isn't working needs-triage
Milestone

Comments

@mlange-42
Copy link

mlange-42 commented Jul 10, 2024

Environment

  • Version of Docsy you are using: v0.10.0
  • How are you using Docsy? As a: Hugo module
  • Version of Hugo you are using (output of hugo version): hugo v0.123.0-3c8a4713908e48e6523f058ca126710397aa4ed5+extended windows/amd64 BuildDate=2024-02-19T16:32:38Z VendorInfo=gohugoio
  • OS: Windows

Problem

I have a Docsy site that is served in a folder of a domain, not on its root, so baseURL = "https://example.com/knowledge/"

When running hugo serve, the layout is completely broken because wrong URLs for built-in JS and CSS files are generated. Note the duplicate knowledge:

<script src="http://localhost:1313/knowledge/knowledge/js/main.js"></script>

The same problem occurs with scss/main.css, offline-search-index.json and js/click-to-copy.js.

With Hugo v0.122.0, it works fine:

<script src="http://localhost:1313/knowledge/js/main.js"></script>

It also seems that the problem does not occur when building the site normally, without serve. However, I don't want to test it on the real site, risking breakage.

@mlange-42 mlange-42 added bug Something isn't working needs-triage labels Jul 10, 2024
@chalin chalin added this to the 24Q3 milestone Jul 12, 2024
@chalin
Copy link
Collaborator

chalin commented Jul 12, 2024

Thanks for filing an issue. Can you share a link to your repo? Or provide a small repro? I'm overloaded and won't have the time to look into this for a while. @fekete-robert @deining @LisaFC - might any one of you have time to look into this?

@mlange-42
Copy link
Author

The original repository is not public, so I made a simplified version without the actual content: https://github.com/mlange-42/knowledge

It turns out that the problem does not only occur with the hugo serve command, but also with simply hugo. See the rendered version here: https://mlange-42.github.io/knowledge/

@huanlin
Copy link
Contributor

huanlin commented Jul 22, 2024

Hi @mlange-42 ,
How about modify the baseURL in your Hugo configuration file as below:

baseURL = "/"

This should fix the JS and CSS path errors when you run hugo server command locally.

Then, in your CI/CD pipeline, try to use the --baseurl option as below:

hugo --baseURL https://mlange-42.github.io/knowledge/

If I understand it correctly, you can also set environment variable HUGO_BASEURL in your CI/CD pipeline. Reference: Configure with environment variables

Hope this helps.

@fekete-robert
Copy link
Collaborator

@huanlin 's advice is good, that's what usually I use as well. A slight alternative is to have different config files for the different environments (https://gohugo.io/getting-started/configuration/#configuration-directory) - this is useful if there are other parameters that you want to change between local/production, not only the baseurl. Also, hugo/docsy does some optimizations on the output if the environment is production.

@mlange-42
Copy link
Author

@huanlin @fekete-robert Many thanks for advising this workaround. Will give it a try. However, as the non-serve version is also broken, I guess hugo --baseURL https://mlange-42.github.io/knowledge/ won't help.

As it worked well before v0.123.0, I still think this is a bug, not sure if on the side of Hugo or Docsy.

@huanlin
Copy link
Contributor

huanlin commented Jul 22, 2024

@huanlin @fekete-robert Many thanks for advising this workaround. Will give it a try. However, as the non-serve version is also broken, I guess hugo --baseURL https://mlange-42.github.io/knowledge/ won't help.

As it worked well before v0.123.0, I still think this is a bug, not sure if on the side of Hugo or Docsy.

Hey @mlange-42 , the reason I think it is a normal way to do it, is because that is exactly what I did for my Hugo+Docsy websites. The target servers have different environments, so I use hugo --baseURL in my CI/CD pipeline to generate and deploy my websites.

However, it's just me. Maybe other guys also find that it is a bug.

@deining
Copy link
Collaborator

deining commented Jul 22, 2024

As it worked well before v0.123.0, I still think this is a bug, not sure if on the side of Hugo or Docsy.

I investigated this issue, thanks for sharing the repo. The culprit is this setting in your config.toml:

canonifyurls = true

As soon as you set this setting to false or remove the line alltogether, everything works as expected.

From the official documentation:

Canonical URLs

This is a legacy configuration option, superseded by template functions
and Markdown render hooks, and will likely be removed in a future release.

@mlange-42
Copy link
Author

Thanks @deining, this fixes the layout issue.

However, all the link are broken now, as the folder where the site is served is not included.
E.g. the test link I inserted in the minimal reproducing example [test link](/how-to-contribute/) becomes:

https://mlange-42.github.io/how-to-contribute/

instead of (as with canonifyURLs):

https://mlange-42.github.io/knowledge/how-to-contribute/

The same with hugo serve. Using --baseURL ... does not have an effect here.

@chalin chalin modified the milestones: 24Q3, 24Q4 Oct 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working needs-triage
Projects
None yet
Development

No branches or pull requests

5 participants