Teknikal's_Domain

#<ENT:NTA:NnT:SSrgS:H66-198:W300:CBWg>

Hugo? More Like HuNO!

2019-09-16 4 min read Behind the scenes Fails Rants Teknikal_Domain Unable to load comment count

So I have no doubt, given Cloudflare’s metrics, that plenty have seen this site. They’ve probably also experienced one of the longest load times in existence, default fonts, and broken icons. Well, I just about fixed it.

The Problem

There were two main problems: The first is that a few directories referenced in the template didn’t exist by default. For example, /fonts when the actual contents are at static/fonts. This has an easy fix, we call that a symlink. But that’s not what I’m talking about.

For some reason, the minified SCSS (contains all the styling and layout rules) file generated made multiple references to https://teknikaldomain.me for various fonts, icons, and the like. As far as I can tell, that’s a problem with the template, I can’t see how my config is messing with it.

Here’s a list of the effects:

Slow Page Load Times

With so may requests to localhost (38, last count), the browser needs to wait for that connection attempt to time out before it can say “this doesn’t exist” and move on.

It could take anywhere from 1 second, to 10 just to watch the page slowly build up piece by piece because of this.

Requests to localhost

Again… localhost, port 1313. This combination is used with the hugo server command to provide a local only debug webserver to watch changes in real time as you write. That is not the address anything should use for public facing material! Why it’s being inserted? I have no clue.

Insecure Request Weirdness

Notice how that said http:// at the front now https://?

If you replaced every verbatim instance of localhost:1313 with teknikaldomain.me, everything would still fail to load, but at least it would be quicker.

This is because (Chrome, at least) will not allow, under the current site configuration, a secure page to request resources in an insecure manner. Instead of just… upgrading the request like a sane person, or better yet, enforcing HSTS by rewriting all http to https automatically, it just gives up. Google’s programming, everybody.

Invalid Fonts

Notice the font change? Nearly every single font file referenced was actually trying to be grabbed from a nonexistent path, on localhost. Not the end of the world, the default font is still legible (maybe even more so), though not as visually interesting.

No Icons

The hamburger menu at the top, the YT and GitHub icons at the bottom, all the little markers on the side of posts… and yes, the home icon when rolling over that lovely picture of a Ghost. Why? See the previous point, same reason. The only difference is that a big hollow rectangle, or one with an X through it, is really obviously not what should be there. So despite having less screen space, this would probably me a more recognizable issue.

The Real Solution

The real solution would be to pick through the various templates, find which one is generating that file, and rewrite it to not be stupid. Unfortunately that will have to wait until I have enough time (and understanding) to figure it out.

The Current Solution

Currently, there’s a script that automatically updates the site files, and this is run as an hourly cron job. The old script looked like this:

#!/bin/sh

cd ~/teknikaldomain.me/tekpro-blog
git pull
hugo

Changes into the right directory, pulls any new changes, and then generates the site files.

My current working, yet sort of hacky solution, was to add these two lines at the end:

for file in `grep localhost:1313 public/* -l -r`; do sed -i -e 's/http:\/\/localhost:1313/https:\/\/teknikaldomain.me/g' $file; done
for file in `grep http://teknika public/* -l -r`; do sed -i -e 's/http:\/\/teknikal/https:\/\/teknikal/g' $file; done

Both these are two part lines: Search for all files in the public folder that contain the offending phrase, and then search and replace the offending phrase with a correct one.

The first line regex replaces https://teknikaldomain.me with https:teknikaldomain.me to solve that, and then the second replaces https://teknikal with https://teknikal, which solves an edge case that I had pop up: It just rewrites the http to https without affecting the domain name.

Why not just regex all http:// to https:// on that second one? Some files have legitimate http:// in them that I don’t want affected. I’m searching for once specific case, and I’m like to only modify that specific case. A wider regex might change other things that I’m not looking at.

I’m done here.. go enjoy an actually responsive site!

comments powered by Disqus