Add abbrlink to Hugo

support
1

I am a former user of hexo and recently migrated my blog to hugo. There is a plugin for hexo called hexo-abbrlink that can generate short URLs based on file names or titles, such as https://example.com/2966fc1/. Is it possible for hugo to support generating short URLs with an abbrlink param?

2

Do you want to change the URL from which the page is served, or do you want to provide an alternate URL?

3

To change the URL.

4

You will have to set the URL of each page when creating the page with hugo new. Add this to your archetype template (archetypes/default.md):

url ='{{ now.UnixNano | crypto.FNV32a }}'

This will set the URL to something like:
https://example.org/1007519435/

Or you could use crypto.SHA256 and use the first seven or eight characters, etc.

By using the time created, we can change the title or path and the permalink will not change.

6

Thank you very much for your advice, it is very helpful. I’m writing code to define a slug in front matter, maybe like this

slug: {{ .Abbrlink }}
or
abbrlink: {{ .Abbrlink }}

I’m using hex crc32 value based on TITLE.

7

I assume it is not possible to set

cascade:
  url: '{{ .Title | crypto.FNV32a }}'

somewhere instead ?

8

No, it is not. With the exception of archetypes, you cannot place template code in front matter.

9

Can I create a PR adding a new field in archetypeFileData?
It’s a new feature, supports to generate short permalink with crc32 algorithm.

10

I think that is unlikely to be accepted. If I want a hash in my front matter, then I should be able to specify the input (path, title, date, now, etc.).

If you want a template function, I suggest you create a proposal to implement pkg.go.dev/hash/crc32, probably in the crypto namespace, with signature:

crypto.CRC32 STRING [POLYNOMIAL]

where POLYNOMIAL:

  • defaults to the predefined Castagnoli constant (yields crc32c)
  • accepts any of the predefined constants (IEEE, Castagnoli, or Koopman)
  • accepts any valid arbitrary value

And you better have a compelling justification, explaining why these are not acceptable:

crypto.FNV32a
crypto.HMAC
crypto.MD5
crypto.SHA1
crypto.SHA256

1 Like