Further Update:
It works as expected when building on vercel: use the url of the actual site–including custom domain–and there is no problem with vercel.
So, I’ve answered the question about baseurl–as per docs and the way I had it.
the problem is with CloudFlare and we’ll see what they suggest about the additional header record they stick on the site that changes the mime type of the style sheet. So, I have confirmed that the mime type for the style sheet created by Hugo becomes application/octet-stream when it MUST be text/css. It is possible that this is the result of some bs “safety” feature of cloudflare that detects non-text in the css file. Or it might not like the long name that hugo generates for the output compiled stylesheet which might look to some not well-written filter like binary data. This is certainly the real problem as I’ve confirmed looking at the received object type in 2 browsers. Of course, there is nothing weird about the css Hugo generates except it can be rather long for some themes and minified. But, normal.
Update: here is the browser web panel error message: The stylesheet https://a-view.org/style.main.min.5ea2f07be7e07e221a7112a3095b89d049b96c48b831f16f1015bf2d95d914e5.css was not loaded because its MIME type, “application/octet-stream”, is not “text/css”.
That’s a new one! I never changed anything in the theme. This is hugely bizarre because that string is not in my hugo directories locally or in the repo. So, CloudFlare is doing some bizarro thing at generate time. Phew!
I have had hours of problems getting the site to render properly. Pages are malformed, etc, because no theme is being applied. I’ve seen this before and it has been because the baseurl is not set correctly. You can see it a-view.org
I have tried many, many permutations of base url to no avail this time.
The site is being generated on CloudFlare Pages. I did not have this problem at Render but Render doesn’t clear caches properly and leaves old versions around that get built.
CloudFlare presents a bit of a challenge. The site is built on one of their generated domains: https://a-view-hugo.pages.dev. When you set a custom domain and have a correct cname record (which they enforce for you) then the site will ALSO be available at https://a-view.org.
So, what’s a choosy mother to do? (from the old American ad for Jif peanut butter). We have several choices:
baseURL = “https://a-view-hugo.pages.dev”
baseURL = “https://a-view.org”
baseURL = “”
None work. Always broken. But, building locally with hugo server always works–it replaces the base url to localhost:1313. At least this shows that the site is otherwise designed properly.
When I switched from Render to Cloudflare I did not initially change the baseurl in my repo–I forgot–so the rest of the hugo site is the same as it was on Render. I then changed the baseurl in config.toml to every choice above. Very time consuming: edit, commit, push, build each time.
It could be that Cloudflare has the same problem as Render by not cleaning the deploy cache they use. Some of these jamstack places seem a bit rough around the edges technically (even though CloudFlare does lots of other stuff…).
the repo is http://github.com/lewisl/a-view-hugo
I assume that even though the site is always available at the private Cloudflare pages url, no one will ever use that so it’s ok if that one renders broken. And I should use baseurl = “https://a-view.org” when I get that to render correctly.
Let me know if there is something obvious to do.
If not, that means it is a caching problem at CloudFlare for which the only thing is to delete the static site and start over. Which is really no big deal, but a pain to do every time something changes.
Many people have pointed out the caching problem to Render, who have done nothing to fix it.
I just posted the problem at CloudFlare–which is the first time so I’m nice in suggesting that they need to look into it.
Hours lost on minor gotchas.
