- JavaScript 52.7%
- HTML 29%
- CSS 12.6%
- Nix 4.6%
- Shell 1.1%
| Filename | Latest commit message | Latest commit date |
|---|---|---|
Hauke Mehrtens
6782da49d4
Both views read the same file and ask it the same question, only the answer is presented differently: the start page lists the next few occurrences, the calendar page marks the occurrences of one month. Since they were taught to read a calendar properly they also carry the same code for it, twice and word for word, some 130 lines of `eventUrl()`, `exceptionsByUid()`, `iterationEnd()`, the fetch with its check of the response and the walk over the events of the calendar. Every fix so far had to be written twice, and the next one that is only written once leaves the two views disagreeing about the same calendar. Put it into `assets/js/events.js`, which offers what both need: - `loadCalendar()` fetches and parses `/calendars/all.ics` - `occurrencesBetween()` walks the occurrences that touch a window, expanding recurring events and resolving the ones that were modified on their own - `eventUrl()` reads the URL of an event `upcoming.js` and `calendar.js` keep what is really theirs, the shape of their entries and how they are drawn, and both lose their own import of ical.js: it is the concern of the module that reads the calendar now. The two of them shrink from 259 and 549 lines to 105 and 406. Hugo bundles the module into both scripts, so no shortcode changes and no second request. The walk keeps an occurrence when it starts at or before the end of the window and ends after its start. That is the condition the start page used; the calendar page compared against the start of the month with "<" instead of "<=". Its window reaches two days past the month, so the day this can differ on is nowhere near it. No behaviour changes with this: the upcoming list over 120 days and every day of the month view from 2025 to 2028, taken from https://berlin.ccc.de/calendars/all.ics with the name, URL, start, end and all day flag of each entry, are identical before and after, and so are the results of the tests for moved occurrences, for modifications between two series and for all day events in Berlin, Tokyo, Los Angeles and Kiritimati. Assisted-by: Claude:claude-opus-5 Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> |
||
| .forgejo/workflows | ||
| archetypes | ||
| assets | ||
| config/_default | ||
| content | ||
| i18n | ||
| layouts | ||
| static | ||
| themes | ||
| tools | ||
| .editorconfig | ||
| .gitignore | ||
| .gitmodules | ||
| .hugo-params | ||
| build.sh | ||
| devShells.nix | ||
| flake.lock | ||
| flake.nix | ||
| LICENSE | ||
| old_config.yaml.txt | ||
| packages.nix | ||
| README.md | ||
| TODO.md | ||
CCCB Website
This is the website of the CCCB.
Getting started
-
Clone this repo (
--recursiveis needed to check out submodules)git clone --recursive https://git.berlin.ccc.de/cccb-website-team/www.git cccb-website -
Switch directory
cd cccb-website -
Run hugo webserver
hugo serve -
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:
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:
./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
- Use your local dev setup (see Getting started) or via the Forgejo editor.
- Make your change in
stagingbranch. - Commit (and push) your change.
GitHub Actions is running the release workflow.- If successful, check Staging Website if change is correct.
- Create a merge request to merge changes from
stagingtoproductionbranch. Ask somebody to check merge request or if small change, merge yourself. GitHub Actions is running the release workflow.- If successfull, check Website if change is correct.
- Profit!
Nix stuff
- After entering the shell with
nix develop, hugo is available andhugo serveand./build.shshould work - You can build the staging and production builds with
nix build .#staging-contentandnix 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.