So I just made a few changes to my website and I hope it didn’t break anything like feeds and such. Here’s a small changelog of the changes:Stopped using Hugo categories for post types (replies, notes, articles, etc) and started using sections, i.e., I know put a note under the /note path. So this …
After publishing the post to which I’m replying to, @jlelse contacted me and I noticed the import directive in Caddy can be used to import files:
import allows you to use configuration from another file or a reusable snippet. It gets replaced with the contents of that file or snippet.
So I just decided to build the redirects file using Hugo itself. First of all, I needed to import a lot of redirects as aliases because I had them in a separate file, but this way it’s much better. After that, I needed to add a new output type to Hugo’s config:
disableAliases: true
outputFormats:
redir:
mediaType: text/plain
baseName: redirects
isPlainText: true
notAlternative: true
outputs:
home:
- redir
Then, I created a layouts/index.redir.txt file with the following content:
{{- range $p := .Site.Pages -}}
{{ range .Aliases }}
{{ . | printf "%-70s" }} {{ $p.RelPermalink -}}
{{ end -}}
{{- end -}}
This is mostly what you can see on this commit of the official hugo docs for their netlify redirects. With this, my Hugo website does not build any HTML aliases (disableAliases), but creates a file on the root called redirects.txt. I can just block the access through Caddy but there’s no reason I should do so. Is there?
On Caddyland, I just added this snipped:
hacdias.com {
root /the/public/path/
redir 301 {
import /the/public/path/redirects.txt
}
}
And voilá! It works! But now you ask: what if we change the redirects file and we don’t wanna have any downtime? Just configure your Micropub entrypoint or whatever software you’re using on the backend to do a config hot reload by executing the following command:
pkill -USR1 caddy
There it is! 301 redirects working flawlessly!
