* Bump Django version to 3.0.x to see what breaks
* Update places where Django 2.2 is mentioned to 3.0
* Update to latest Django 3.0 version
* Bump version in setup.py
https://docs.djangoproject.com/en/2.2/howto/error-reporting/#errors
> If those conditions are met, Django will email the users listed in the
> MANAGERS setting whenever your code raises a 404 and the request has a
> referer. It doesn’t bother to email for 404s that don’t have a referer –
> those are usually just people typing in broken URLs or broken Web bots.
> It also ignores 404s when the referer is equal to the requested URL,
> since this behavior is from broken Web bots too.
This allows for usage of settings variables in templates, e.g
```
{% if settings.USE_ANALYTICS %}
<!-- Google Tag Manager (noscript) -->
<noscript><iframe src="https://www.googletagmanager.com/ns.html?id={{ settings.GOOGLE_TAG_MANAGER_ID }}" style="display:none;visibility:hidden"></iframe></noscript>
<!-- End Google Tag Manager (noscript) -->
{% endif %}
```
> 'debug': a boolean that turns on/off template debug mode. If it is
> True, the fancy error page will display a detailed report for any
> exception raised during template rendering. This report contains the
> relevant snippet of the template with the appropriate line highlighted.
> It defaults to the value of the DEBUG setting.
https://docs.djangoproject.com/en/2.2/topics/templates/#module-django.template.backends.django
I could be wrong about this, but it seems like setting the template
DEBUG setting is redundant, since it should follow whatever the DEBUG
variable is set to.
The settings which are normally prefixed `CELERYD_` are for worker-related config, but since we instantiate the Celery app with a namespace, the prefix for these config should actually be `CELERY_`.
- Change celery app to not be a Django app, more like a WSGI app
- Define a Celery task in the Django users app
- Write a test to execute the task
- Update scripts to use the new app to start workers
- Update documentation
Fix#865
## Description
Fixes#591.
## Rationale
We are currently not testing many combinations, we run Flake8 on the generated project with default options, but that rarely catch any issues.
## Use case(s) / visualization(s)
Catch problems with invalid combinations, for instance, it fails due to Whitenoise breaking flake8 with `django-compressor` because `STATIC_URL` was undefined here:
b91c70d755/%7B%7Bcookiecutter.project_slug%7D%7D/config/settings/production.py (L185)
* Create a test matrix on Travis CI to help testing multiple options
* Change test_docker.sh to fail if any command in it fails
* Run black on the CI with --check option
* Fix formatting of project files using black
* Install black in the docker container
* Exclude migrations in black checks
* Fix Black formatting violations
* Run black on the whole generated project & fix issues
* Prettify and re-order settings entries
* Use old-style .format() for the time being
* Remove redundant linebreaks at the settings files' beginning
* Fix E303 too many blank lines
* Remove a redundant linebreak from requirements.txt
* Some linebreake juggling in config.settings.base
