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.
I'm sure this can be useful, but since I validate before storing, this is just
a ReallyBadIdea(TM). For one, it makes it so that running with different settings
of VALIDATE_ON_DIGEST leads to different data in the DB
according to spec, this is possible (though I did not yet observe it in the data).
the need for this was exposed when introducing fastjsonschema, which (by default)
fills in all keys with their default values (None for pre_context/post_context)
we've observed that this is sent-in-practice. we don't want to
actually remove it from the stored data, so we remove it only
from the thing we validate (not the actual data)
Klaas van Schelven