Trouble with hugo uploaded and not in root?

I am having a problem with my Hugo instance where the site views properly when running ‘hugo server’ locally and then breaks when I publish to my website. The break is that it looks like the css is not referenced properly. Navigation buttons are huge, the dark/light button does not toggle, and no style shown.

I think it might have something to do with my baseURL and the fact that I do not have my hugo published content in the root of my website…

https://www.mywebsite.com/blog33

This is what I have in my hugo.yml… (where mywebsite is replaced with my real domain name

baseURL: "https://www.mywebsite.com/blog33"
languageCode: en-us
title: mywebsite blog
theme: "PaperMod"

Also, could it be my “deployment procedure”?

I am running ‘hugo’ and then copying the ‘public’ directory content into my ‘blog33’ directory. So that when folks visit the blog33 directory in the browser URL they see the blog.

supposedly you are right in some way - if your site is published to a subfolder you will have to use the right templating to generate proper urls for the CSS.

The exampleSite of the PaperMod has no problems with being generated for a subfolder.

You are doing something unexpected/wrong here. Without your sources it would be just guessing.

Pleasae spend a few minutes reading Requesting Help

Also a search here in the Forum should point you to topics dealing with sites in subfolders and maybe even paperMod

p.s. it’s much better to use https://www.example.com/mysite instead of a domain resellers one.

2 Likes

You have to view the content of the generated site using a browser. Opening the html file from the filesystem won’t work.

IF you really want a serverless site have a look at Crafting and configuring a "serverless" site

Thanks. I meant to write the full url there but the link feature kept taking the text and making it a link.
So, yes I do want the blog to be visible at…

http://www.example.com/blog33

When we go to deploy, should all the files to upload come from the ‘public’ directory? i.e. just uploading that directory should work, correct?

if the html content is generated properly. fe the src/href attributes.

check the dev tools in your browser where it tries to find the css and adjust.

if you need further assitance you will have to provide a replayable example

1 Like

Thank you. I will get onto getting the instance code into a repo.

In the meantime I tried switching the theme to ‘hugo-paper’ and it does work after being uploaded to the website. So it could be something with the ‘PaperMod’ theme or missing some extra configuration to it.

definitely something like that one. As stated before the themes exampleSite works in a subfolder.

1 Like

Thanks to @irkode for help thus far!

After finding that ‘hugo-paper’ theme worked and ‘PaperMod’ did not, I found something via searching the PaperMod theme GH page…

Issue with Hugo not building the css

That little fix there, adding a config setting for the params/assets/disableFingerprinting, did allow the css to show properly in a browser on my website’s server. So there is something there with a ‘deprecated’ setting and such, but for now my issue is resolved. I am going to add a note to the GH issue for that so that there is another datapoint that this was the same/similar.

found that one

updated the link to Papermod repo

played a little:

hugo server generates absolute links using portnumbers, AND serves the baseURL … so that hugo server works.

this works when deploying the public folder to the root of my webserver.

hugo -b http://localhost/hugo-PaperMod/ -d public/hugo-PaperMod

I use a very basic webserver without CORS/SRI settings running on port 80 only, no https.

paperMod uses absolute links for some of the elements. and menu entries

<link rel="icon" href="http://localhost/hugo-PaperMod/favicon.ico" />
<a href="http://localhost/hugo-PaperMod/fr/" title="French"

serving from a different port 808 will break on my simple server, cause the request for these go to port 80 which is not bound and break that icon

No issues with the fingerprinting locally also with a simple WEB server.

deploying to a real server, incl https, CORS, SRI, guess will need the appropriate configuration

maybe that would be a nice tips and tricks article :wink: