Ben Sturmfels
3826b6fb66
The advantage of this approach is that the production and dev configurations are in version control, so there's less opportunity for surprises. As advocated by Jacob Kaplan-Moss (OSCON 2011) and Two Scoops of Django book.
19 lines
829 B
Markdown
19 lines
829 B
Markdown
# To-do
|
|
|
|
* remove `ForceCanonicalHostnameMiddleware` by ensuring canonical redirect and HTTPS redirect is done by Apache
|
|
* serve a 400 in Apache for a hostname we don't explicitly support
|
|
* use `<detail>` elements for supporter page hidden sections, rather than complex jQuery - or consider Alpine.js
|
|
* replace `internalNavigate` with inline flexbox layout
|
|
* add tests for main pages returning 200
|
|
|
|
|
|
# Done
|
|
|
|
* standardise settings to replace `settings.py` and `djangocommonsettings.py`
|
|
with `settings/prod.py` and move `SECRET_KEY` to an environment variable
|
|
* migrate to Django 4.2 LTS
|
|
* review `apache2` directory - may be unused
|
|
* add deployment script that runs migrations and collects static files
|
|
* switch `ParameterValidator` to use `SECRET_KEY` if possible to minimize
|
|
non-standard settings
|
|
* install staticfiles app
|