Add an "out of date" alert

[tzinm]

I recently came across an interesting feature in another Zola theme, serene, and thought it could be a great addition to Tabi. The feature is an "out of date content" alert that warns readers when a post might contain outdated information.

In serene, this alert appears below the post title and before the main content. It can be enabled globally or set individually for each post. An example of this feature in action can be seen here.

Suggestion for Tabi

It would be great to implement a similar configuration in Tabi, allowing users to enable the alert either globally or per blog post. This setting should not affect other sections, such as the "Projects" section.

Would it be possible to implement a similar feature in Tabi? 😊

[welpo]

Yeah, this feature is in my backlog and I would like to add it.

I see two ways:

• Create the alert on Zola build. Simplest. Downside: if the site is built once and never updated after the X days of threshold that determines the warning should be shown, it will never be shown
• Use JS. We could create the warning dynamically, so that even sites with a single update show the warning after X days. Downside: requires JS.

Not too sure about which way I'd prefer to go.

In any case: would you be interested in contributing the implementation of the feature?

[tzinm]

From my perspective, the only viable option would be to use JS to generate the warning dynamically. The other approach doesn't seem practical. Just as you mentioned, if someone sets the threshold to 120 days but doesn’t rebuild their site for over a year, the alert would never appear once that threshold is reached.

Just like other features in tabi that require JS and are documented as such, this could follow the same approach. By default, it wouldn’t be enabled, but users could choose to activate it, keeping in mind that their site would need JS for it to work.

I'd be happy to contribute to this feature. Let me know if you have any preferences on the implementation or any guidelines I should follow!

[welpo]

I'm thinking of a middle ground:

• Have one (1) logic to build the warning div based on a hierarchy-respecting setting (e.g. warn_outdated_after_days = 120)
• On build, check if we're past the threshold
  • If we are: create the div normally
  • If we are not: prepare the HTML but hide it with CSS. JavaScript would check local user time and compare to a data tag in the HTML element

Important to note that the warn_outdated_after_days setting should be compared to updated date first, falling back to date and failing silently (i.e. do nothing) if there's no date?

This way we get JS-free warnings on build, and a fallback for non-potentially-outdated posts.

Does this make sense?

[tzinm]

Respecting the configuration hierarchy allows for more granular control over when the warning is displayed. Some examples:

1. If the warning is enabled globally (from config.toml), but we believe a specific post doesn't require it because its content doesn't become outdated, we can disable it for that post using the frontmatter.
2. Instead, if the default behavior is to keep the warning disabled globally, but some entries are time sensitive, we should be able to enable the warning specifically for those entries in the front matter.
3. Also, a site may contain other sections in addition to a blog. For example, there may be a quotes section where displaying the warning wouldn't make sense. Being able to control this behavior by section is useful.

Regarding the logic you proposed, I think it makes sense.

flowchart TD
    A{"Is 'updated' set?"}
    A -- Yes --> B{"Has 'updated' exceeded threshold?"}
    B -- Yes --> C["Display warning"]
    B -- No --> D["Do not display warning"]
    A -- No --> E{"Is 'date' set?"}
    E -- Yes --> F{"Has 'date' exceeded threshold?"}
    F -- Yes --> C
    F -- No --> D
    E -- No --> D

Loading

[welpo]

Right. Only thing I'd add is checking updated, if set, then date.