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>
85 lines
3.1 KiB
Markdown
85 lines
3.1 KiB
Markdown
# CCCB Website
|
|
|
|
This is the website of the CCCB.
|
|
|
|

|
|
|
|
## Getting started
|
|
|
|
1. Get Hugo: <https://gohugo.io/getting-started/installing>
|
|
2. Clone this repo (`--recursive` is needed to check out submodules)
|
|
|
|
```shell
|
|
git clone --recursive https://git.berlin.ccc.de/cccb-website-team/www.git cccb-website
|
|
```
|
|
|
|
3. Switch directory
|
|
|
|
```shell
|
|
cd cccb-website
|
|
```
|
|
|
|
4. Run hugo webserver
|
|
|
|
```shell
|
|
hugo serve
|
|
```
|
|
|
|
5. Point your browser to: <http://localhost:1313/>
|
|
|
|
Every change you make on the project will be reflected in your browser as long as `hugo serve` is running.
|
|
|
|
The *"Nächste Veranstaltungen"* table on the home page and the calendar under `/verein/calendar/` are rendered in the
|
|
browser by `assets/js/upcoming.js` and `assets/js/calendar.js`. Both fetch `/calendars/all.ics`, which is **not**
|
|
generated by Hugo and is not part of this repo — it is published separately on the web server. Without it both tables
|
|
stay empty. Download the published calendar into `static/`, which Hugo serves under the same path, and they work
|
|
locally, under `hugo serve` as well as in a built site:
|
|
|
|
```shell
|
|
mkdir -p static/calendars
|
|
curl -o static/calendars/all.ics https://berlin.ccc.de/calendars/all.ics
|
|
```
|
|
|
|
The file is only there to look at the site, it is not checked in. Download it again whenever you want the events that
|
|
are currently published.
|
|
|
|
Hugo does generate an `.ics` feed per section (for example `/veranstaltungen/index.ics`) from the `dtstart`, `dtend`
|
|
and `rrule` front matter of the pages in `content/veranstaltungen/`, using the `.ics` templates under `layouts/`.
|
|
|
|
The site must not make the browser load anything from an external server, so third party JavaScript is checked into
|
|
`assets/js/vendor/` and bundled in by Hugo instead of being pulled from a CDN. See the README there before updating it.
|
|
|
|
To build the site for upload, run:
|
|
|
|
```shell
|
|
./build.sh
|
|
```
|
|
|
|
This deletes `public/` and runs `hugo` with the parameters from `.hugo-params`. To build with *nix* instead:
|
|
`nix build '.?submodules=1#production-content'`
|
|
|
|
## Making a change
|
|
|
|
1. Use your local dev setup (see Getting started) or via the Forgejo editor.
|
|
2. Make your change in `staging` branch.
|
|
3. Commit (and push) your change.
|
|
4. ~~GitHub Actions is running the release workflow.~~
|
|
- If successful, check [Staging Website](https://staging.berlin.ccc.de/) if change is correct.
|
|
5. Create a merge request to merge changes from `staging` to `production` branch. Ask somebody to check merge request or
|
|
if small change, merge yourself.
|
|
6. ~~GitHub Actions is running the release workflow.~~
|
|
- If successfull, check [Website](https://berlin.ccc.de/) if change is correct.
|
|
7. Profit!
|
|
|
|
## Nix stuff
|
|
|
|
- After entering the shell with `nix develop`, hugo is available and `hugo serve` and `./build.sh` should work
|
|
- You can build the staging and production builds with `nix build .#staging-content` and
|
|
`nix build .#production-content`
|
|
- Do not update the nixpkgs branch - 25.05 contains a newer hugo version that is incompatible with the theme (last
|
|
checked June 2025)
|
|
|
|
---
|
|
|
|
Made with ❤️ and [Hugo](https://gohugo.io).
|
|
|