The theme was pinned at v2.86.0, which declares that it works with Hugo 0.137.0
to 0.147.5. Hugo has been 0.165.0 here and 0.163.3 in the pinned nixpkgs branch
for a while, so every build complained:
WARN Module "blowfish" is not compatible with this Hugo version: 0.87.0/0.147.5
WARN deprecated: .Site.LanguageCode was deprecated in Hugo v0.158.0
WARN deprecated: .Site.Data was deprecated in Hugo v0.156.0
The two deprecated calls were in the templates of the theme, in head.html,
baseof.html, schema.html and several shortcodes, so they could not be fixed
from here. v2.106.0 accepts 0.158.0 to 0.165.0, which covers both Hugo versions
we build with, and no longer uses either of them. The build is free of warnings
now. v3 was not taken, it is a new major version.
The theme reorganised its JavaScript along the way and dropped js/process.js.
Our layouts/partials/footer.html is a copy of the footer of the theme with a
link to the Git repository added to the "powered by" line, and it still loaded
that file, which broke the build outright:
ERROR ... execute of template failed: ... <resources is nil
Take the footer of v2.106.0 and add the link to it again. It is the only
template we override that belongs to the theme, the others are our own, and
nothing else in layouts/ refers to a file the theme removed. The German strings
for the 404 page still apply, the theme keeps its translations as YAML now but
the keys are unchanged, and no configuration parameter we set was dropped.
The site builds identically apart from the theme itself: no page is lost, none
lost its content, the largest pages grow by about a third from added markup,
and the churn in public/ is the renamed bundles, the dropped jQuery and
differently named image derivatives.
While at it, replace the note in the README that told the reader not to update
nixpkgs because it would bring a Hugo the theme cannot handle. That is what
just got resolved, so name the actual range instead.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The upcoming events table pulled its ICS parser straight from a CDN with
`import ICAL from "https://unpkg.com/ical.js/dist/ical.min.js"`. That sends
every visitor of the start page to unpkg.com, which hands their IP address and
user agent to a third party before any of our own code runs. The URL is not
even pinned to a version, so whatever ical.js publishes next is executed on our
site without anybody looking at it, and the start page silently breaks when the
CDN is unreachable.
Check the parser into `assets/js/vendor/` and let Hugo bundle it. This is what
`js.Build` is for: it runs the esbuild that is built into Hugo, so it resolves
the import at build time and needs no node_modules and no extra tooling in the
build environment. The result is minified and fingerprinted like the other
scripts of the site, and the script tag carries a subresource integrity hash.
Since the bundle now has a content hash in its name, its URL cannot be written
by hand in the markdown any more. Move the table and the script tag into an
`upcoming` shortcode, which is the same pattern `calendar.html` already uses,
and move `upcoming.js` from `static/` to `assets/` so Hugo can process it.
The vendored file is the unminified `dist/ical.js` of the pinned release: it
carries the MPL-2.0 header and is the source form of what we ship, and Hugo
minifies it for delivery anyway. `assets/js/vendor/README.md` records the
version, where it came from and how to update it.
The built bundle renders the same table as before, checked against
https://berlin.ccc.de/calendars/all.ics.
Fixes: c28f04c6e8 ("switch to ics files; make calendars work; fix some minor issues")
Assisted-by: Claude:claude-opus-5
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
`build.sh` no longer post-processes anything: since the switch to ICS files it
just deletes `public/` and runs `hugo`. The `CALENDAR` placeholder, the Python
dependency on `icalendar`, `python-dateutil` and `pytz`, and the `de_DE.UTF-8`
locale requirement are all gone, and nothing in `packages.nix`, `devShells.nix`
or `flake.nix` pulls in Python any more. Drop those claims.
Describe instead where the two calendar views actually come from: the
"Nächste Veranstaltungen" table and the calendar page are rendered in the
browser from `/calendars/all.ics`, which is published next to the site and is
not built from this repository. That also replaces the old advice to preview
them via `./build.sh` plus a local HTTP server, which no longer helps.
Without that file the two of them stay empty. Hugo serves everything below
`static/` from the root of the site, so it can simply be put there, and the
command that downloads it is worth writing down. Checked from an empty state:
afterwards the file is served under `/calendars/all.ics` by `hugo serve` and the
table on the start page fills with the upcoming events. It is a copy of
published data and has no business in the repository, so ignore it.
Mention the per-section `.ics` feeds Hugo does generate, so the ICS templates
under `layouts/` are not mistaken for the source of `all.ics`.
Fixes: c28f04c6e8 ("switch to ics files; make calendars work; fix some minor issues")
Assisted-by: Claude:claude-opus-5
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
`hugo serve` rendert die Tabelle „Nächste Veranstaltungen" auf der
Startseite nicht — die wird erst durch `./build.sh` per sed in
`public/index.html` eingefügt. Die README beschreibt jetzt den
Build-und-Servieren-Workflow inklusive Python-Abhängigkeiten und
benötigtem Locale.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
