Fixes#7
I could not find any documentation on what the "standard" is, but I know that
we'll pick it up just fine either way (because Django's UUID field does the
magic for us).
Given that it's impossible to setup your JS client with the dashes, they should
simply be removed.
why: simply motivated by Python's own EOL-cycle; i.e. I'm not
actively going to use any 3.13 or 3.9 features now.
how: updating test-matrixes; but no actual local testing done yet
(this is the last version that supports Python 3.9, which we want to
support as it's not EOL for a full more year)
https://github.com/timonweb/django-tailwind/issues/210
Afterwards, I went through a full cycle of:
```
rm theme/static_src/package-lock.json theme/static_src/node_modules/ -rf
python manage.py tailwind install
python manage.py tailwind build
```
but this did not change any of our generated stuff.
in IMMEDIATE mode, project was passed from an (implicit) read transaction to
the immediate_atomic-wrapped code; this meant that it was possible to miscount
project.digested_event_count
Our goal with having Docker in the first place is to make it easy to
deploy the application. 'just migrating' is a good idea for that goal
in general, but the more so because running migration commands when
the container isn't running yet, while the container refuses to run
without them having run putch you in a catch-22.
(the above may not be strictly true when you run with a database that's
external to your image, i.e. with mysql, because then you can use 'run'
rather than 'exec', but even that feels a bit 'wrongish', because run
starts a container that is then left around for `docker ps -a` to see)
for sqlite containers it's even more pressing, because the writes-to-db
go to different databases for each of the incantations of run (including
server-start). Even if I get this to work (I can't find the solution
in 15 minutes) it will be so clunky to be unworkable.
Theoretical concerns about not migrating on-server-start (but rather,
as part of some CI/CD script or something) will have take take a back-seat
to the reasoning above... if they even hold up at all).
this should make it so that you get the debug information right at the moment
you're experiencing the problem (rather than having to go to a special page)
As in the website, where we said "Don't recommend X-Forwarded-Host"
We recommend just setting 'Host' in the production-installation guide,
so using X-Forward-Host is actually _wrong_.
I'd rather use Host than X-Forward-Host, it's much more straightforward.
here's a question on SO, which has answers, but I don't see any reason
there to not just use Host (in fact I understand none of the answers):
https://stackoverflow.com/questions/19084340/real-life-usage-of-the-x-forwarded-host-header
in the lists; this is easier to read than a strikethrough.
I experimented with text-decoration-style and text-decoration-style but that
didn't make it better.
Our big brother doesn't bother to reveal the resolvedness of issues in lists
_at all_, btw. Surprising!
Multiple problems w/ <a name
* in itself deprecated
* my approach of self-closing <a is illegal too
replaced w/ spans where necessary.
Further notes:
'topp' was never used; '#top' is taken too, so I went with first-frame (stil unused, 'maybe later')
The fixes in this and preceding commits were inspired by running "Nu Html Checker"
docker run -it --rm -p 8888:8888 ghcr.io/validator/validator:latest
files were simply saved in Firefox and then uploaded; make sure to ignore the warning which is caused by Firefox:
> A document must not include both a meta element with an http-equiv attribute whose value is content-type, and a meta element with a charset attribute.
I limited checking to the issue-list and various event-detail pages.
Klaas van Schelven