Public assets gets weird paths when Zola app is used in Docker container (Fly.io)

Support
1

Hi,

I’ve been getting frustrated all day over an issue I was facing, where the stylesheet I used from the ‘tranquil’ theme was applied correctly when serving the site on the local dev server, but not applied at all when deployed in a container in the cloud (Fly.io).

I read this forum looking for answers, built the image in my local Docker environment and started to try and debug from there. Confusing thing was that I noticed that the compiled tailwind .css file seemed to be in the correct path inside the container, but still the HTTP request wouldn’t resolve on that path.

After trying a bunch of things, I eventually got the styling to work in my Fly app without really knowing what did it. But then I noticed in the network tab in the browser dev tools that the link to the stylesheets resolved to this adress: https://helibom-net.fly.dev//styles/styles.css and the page sources looked like this,
image

However, upon each refresh of the page I get, seemingly randomly, a different directory structure in the source tab, where the js or img directory might also be within the nameless directory another level down.

What had happened was that I had accidently gotten things to work when I changed the base_url variable in config_toml to https://helibom-net.fly.dev/ instead of https://helibom-net.fly.dev.

My current solution is to either set the base_url to https://helibom-net.fly.dev/ or hardcode double forward slashes in the href, like so <link href="{{ config.base_url }}//styles/styles.css" rel="stylesheet">. I don’t like neither solution.

So what might be going on here?
I’m starting to believe it’s the webserver that is showing some bug, because when I inspect the container on Docker Desktop, the directory structure in /public looks rather flat, just like it does on my local machine, without that nameless directory creating an extra in the tree.

Any ideas would be appreciated, thanks!

2

My guess is it’s an issue with the theme.

This is how it loads the CSS file:

<link href="{{ config.base_url }}/styles/styles.css" rel="stylesheet">

If base_url ends with a slash, you’ll get the double slash.

A much more reliable way to get the path to files in Zola is:

{{ get_url(path="filename.css", cachebust=true) }}

(The cachebust is not required, but a good idea)

Try updating the theme to remove the line I linked above, and add this instead:

<link rel="stylesheet" href="{{ get_url(path="styles/styles.css" , cachebust=true) }}">

Hope that helps!

1 Like
3

@welpo I apologize for the late response, life has been busy, took me a while to revisit this. But I really appreciate your reply and attempt at helping me.

I tried your suggestion to load the file path the with that utility function, but unfortunately that didn’t seem to be my solution.

What I discovered was that I must’ve been inconsistent after all when providing the base_url property to Zola and static-web-server.

A note to any other person trying to troubleshoot a similar thing is this:
If the base_url returned by {{ config.base_url }} or {{ get_url(path) }} does not have an initial “http://”, then static-web-server will interpret any <link/> tag with that reference as a relative address and proceed to prepend it with the base_url that static-web-server uses.
And watch out, because sws looks for a config.toml as its config by default, just like Zola.
You can use the -w flag to specify another config file for sws.

1 Like