Henrique Dias 16 Feb 2020 11:06

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

    mediaType: text/plain
    baseName: redirects
    isPlainText: true
    notAlternative: true

    - 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 which you see here. 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: {
  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!