Still trying to work out the problem with CloudFlare when they munge the mime type of the css for the generated and deployed site. There is actually a question in all of this: skip to Q U E S T I ON below.
Their support is working at cross-purposes with their devs, but that is nothing new. So, they asked me to create a subdomain, say test999.a-view.org, which will point to one of the dev (non-production) versions.
Sort of like Vercel and Netlify, but without really understanding what they are doing, they keep all of your non-product builds around. Eventually, they’ll have to gc them but for now they leave them around. they look like e45678.a-view-hugo.pages.dev.
For clarity, I named the project “a-view-hugo” so that becomes a subdomain of their standard dev url: .dev.pages. When there are multipe ones they put the hex string in front, but it has nothing to do with SHAs of commits. My custom domain is a-view.org so that is where you can see the final site. And I use CloudFlare as the dns (though I don’t have to–they are cheap, generate https certificates automatically so a-view.org and www.a-view.org work with https).
Each time you build you get another one of the development subdomains. So, their support people want a set subdomain like test.a-view.org. But there are fundamental problems with this:
- All these site builder things need to know your custom domain. That let’s them stub it into their tooling when they generate some resources that need a url tied to the site–headers that aren’t under Hugo’s control. But, you can only have ONE custom domain for a project–and it is used to point to the production build (naturally, that is what you want users to see at your publicly visible URL). I can stick a CNAME record to point to another project subdomain, but it can’t ever work. Indeed, after about 6 hours, test.a-view.org won’t resolve (522 error).
- Another result of these somewhat persistent ephemeral, dynamically named subdomains for dev builds is that I can’t set a baseURL so the site css ALWAYS has an incorrect url. Now, if they knew what they were doing–like Netlify, vercel, Render and others–they would use the -b cmdline option with the url they generated. They can do this under-the-hood and it would fix the problem. I can give any hugo command line I want for the build, but I can’t use -b with the dynamically generated url because I don’t know what it will be.
- What they need to do is use one of the dev builds to do their debugging. One problem is that it’s a beta still and the support people aren’t well-versed in their own product and certainly aren’t familiar with other build and deploy competitors. But, even if they did understand, I can’t build them a version with properly configured baseURL. See the question below…
- Another option is that I just turn off the worker (like an AWS Lambda, Netlify now has something like it) for the custom domain. This is easy and then they could inspect the problem. The site would be broken until I turned the worker back on. The world would keep turning. I promise you there aren’t a lot of people reading my wonderful (if I do say so myself…) Hugo blog. This is probably the simplest way out of the mess for the few days they need to poke at the patient.
Q U E S T I O N: is there a way in Hugo I can set a baseURL that enables the dev site to work properly even though that setting doesn’t match the actual URL of the site? Will either of “/” or “” work? Can I put the site CSS lower than the root level of the site? (I suspect not: browsers need to find that css before they can render any html properly)
If not, option 4 is the answer and I won’t die…
In the end, if they never fix this then I can always go back to Render (or any of the others) that do not munge the mime type of resources. The basics are pretty commoditized (the “icing” varies quite a bit…). I am just trying to help these guys get it right. They won’t be doing anything all that magical in building and deploying SSGs. But, they have their icing: strong security at outer edge of websites, a good CDN (YMMV), and pretty strong “edge” capabilities for doing stuff fancier than I’ll ever need. Ultimately, if they don’t want to get it right then that’s weird and the product “Pages” will have a bad rep and no one will use it. Doubt that is their goal. Problem with a bigg-ish company that shifts devs around is people may be technically ok but don’t always understand what they are working on. But, I doubt AWS, Google Sites or FireBase, or the MS Azure stuff have such a basic problem and they’re big companies.
If no one has an answer, don’t worry. I’ll convince them to use option 4 (I’ll suffer… 
).