layouts: use new try function

[l-zeuch]

Summary

Hugo 0.141.0 introduced a new try function, replacing the way error
handling is done. Update the affected render hooks and shortcodes such
that they no longer break on Hugo 0.141.0 and above.

Basic example

See gohugoio/hugo#13216 for migration instructions and further details.

Motivation

1. New users of this theme are likely to use the latest version of
   Hugo--ensure the build does not break for those.

2. Our CI (and probably most of other automated Hugo builds) is set to
   always use the latest extended version of Hugo. Without this change,
   we'd have to pin it to 0.140.2 or below.

Checks

• Read Creating a pull request
• Supports all screen sizes (if relevant)
• Supports both light and dark mode (if relevant)
• Passes npm run test (if relevant)

---

Some further remarks, which I wish to fully resolve before landing this
change. We can downgrade Hugo in our CI for the meantime.

Should we bump the minimum Hugo version in the affected files? I'm
seeing a minimum of 0.114.0 at the moment, checked individually.
Alternatively, should we just introduce a safeguard around the affected
block of code, checking if we are required to use try and do so
conditionally, based on the Hugo version in use?

Personally I'm leaning towards not touching that minimum version, and
instead wrap the affected blocks in a new safeguard. That way, we can
comfortably cut a patch-level release and not worry about a
(technically) breaking change. Please let me know what you think.

[changeset-bot]

🦋 Changeset detected

Latest commit: e906dff

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@thulite/doks-core	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[l-zeuch]

Hey @h-enk! I hope you're alright.

I do wish to get this addressed quite soon, as Hugo certainly won't stop pushing new releases out and we can't keep Hugo pinned forever; patching dependencies is quite cursed, so we'd prefer to not do that either.

I deliberately left out a changeset because I wish to discuss the way to go about this--should we make reasonable attempts at keeping backwards compatibility as far back as possible, or just face the reality that Hugo is going to break things in the long run and also make Doks users upgrade to ^0.141.0 (which introduced this breakage)?

[h-enk]

Hey @l-zeuch, sorry for not getting back to you earlier. Times are a bit wild, but I'm getting things back on track.

I deliberately left out a changeset because I wish to discuss the way to go about this--should we make reasonable attempts at keeping backwards compatibility as far back as possible, or just face the reality that Hugo is going to break things in the long run and also make Doks users upgrade to ^0.141.0 (which introduced this breakage)?

My take is that we always update Doks to support the latest Hugo (I'm aware it's an effort). If Doks breaks for users not using the latest and greatest Hugo, updating would be the advice.

[l-zeuch]

My take is that we always update Doks to support the latest Hugo (I'm aware it's an effort). If Doks breaks for users not using the latest and greatest Hugo, updating would be the advice.

Understood--I'll bump the minimum version at the start of this file in that case, and we should be good to go (after I created a changeset as well).

[h-enk]

So, also no extra safeguard. But, do follow Hugo's Deprecation process

[l-zeuch]

follow Hugo's Deprecation process

Unfortunately this is not easy (if not outright impossible) to deprecate how Hugo suggests -- they themselves started failing the build out of the blue, which is why we had to pin Hugo to a previous version in the meantime.

[h-enk]

LGTM