Add .UUID function to archetype context for RSS/Atom feeds

feature
1

In RSS and Atom feeds, pages need unique identities that persist across changes to titles, dates, slugs, and content. The only way to guarantee this works for everyone out of the box without requiring them to have closely read the page identity policy for a Hugo module is to add a page param like id = "<random unique string>" to all pages, and then reference it in the RSS/Atom template for the guid/id value.

2

If you are looking for samples : ATOM and RSS

uses the file url to generate a correct UUID

3

A permalink is a unique string, you cannot have (it will not work) if you will have more than two that same hence below will be sufficient.

<guid>{{ .Permalink }}</guid>
1 Like
4

This is Ok for “id” and not for “guid”,
see Universally unique identifier - Wikipedia

5

You have access to functions and the .File object within the archetype (both in front matter and in the body). The best I’ve come-up with is something like:

+++
title = '{{ replace .File.ContentBaseName "-" " " | strings.FirstUpper }}'
date = {{ .Date }}
uuid = {{ crypto.FNV32a (printf "%s%d" .File.Filename now.UnixNano) }}
+++

The odds of creating a file with same absolute path (which often includes user name) at the same time (in nano seconds) is a really small number.

The archetypes approach doesn’t help, obviously, with pages that may not be backed by a file (e.g., top-level sections, taxonomy pages, and term pages).

But none of this helps when a content author creates a new page by copying an existing page, which I do all the time.

4 Likes
6

@ju52 It doesn’t have to be a UUID, so you could just use the raw hash code.

@ju52 @idarek It looks like you’re basing the guid/id on the permalink, but the W3’s Atom document Introduction to Atom suggests following the suggestions in How to make a good ID in Atom [dive into mark], which says you shouldn’t use permalinks:

It’s valid to use your permalink URL as your <id>, but I discourage it because it can create confusion about which element should be treated as the permalink. Developers who don’t read specs will look at your Atom feed, and they see two identical pieces of information, and they pick one and use it as the permalink, and some of them will pick incorrectly. Then they go to another feed where the two elements are not identical, and they get confused.

In Atom, <link rel="alternate"> is always the permalink of the entry. <id> is always a unique identifier for the entry. Both are required, but they serve different purposes. An entry ID should never change, even if the permalink changes.

“Permalink changes”? Yes, permalinks are not as permanent as you might think. Here’s an example that happened to me. My permalink URLs were automatically generated from the title of my entry, but then I updated an entry and changed the title. Guess what, the “permanent” link just changed! If you’re clever, you can use an HTTP redirect to redirect visitors from the old permalink to the new one (and I did). But you can’t redirect an ID.

The ID of an Atom entry must never change! Ideally, you should generate the ID of an entry once, and store it somewhere. If you’re auto-generating it time after time from data that changes over time, then the entry’s ID will change, which defeats the purpose.

As I said above, the title or slug can change, which will change the permalink.

@ju52 Assuming that RSS 2.0 Specification (Current) is the RSS 2.0 “standard”, RSS 2.0 Specification (Current) specifies:

<guid> is an optional sub-element of <item>.

guid stands for globally unique identifier. It’s a string that uniquely identifies the item. When present, an aggregator may choose to use this string to determine if an item is new.

<guid>http://some.server.com/weblogItem3207 </guid>

There are no rules for the syntax of a guid. Aggregators must view them as a string. It’s up to the source of the feed to establish the uniqueness of the string.

So it doesn’t have to be a UUID.

The odds of creating a file with same absolute path (which often includes user name) at the same time (in nano seconds) is a really small number.

@jmooring Good idea. I suppose that’s good enough, although it would be nice if Hugo provided a method to generate guaranteed unique values.

7

Not an expert on valid UUID format, but how about using base64 for that purpose. Overall Base64 is a more human-friendly representation of UUID as some people saying :slight_smile:

8

here the ATOM spec
and the validator for RSS and ATOM feeds :wink:

9

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.