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
[//]: # (Thank you for helping us out: your efforts mean great deal to the project and the community as a whole!)
[//]: # (Before you proceed:)
[//]: # (1. Make sure to add yourself to `CONTRIBUTORS.rst` through this PR provided you're contributing here for the first time)
[//]: # (2. Don't forget to update the `docs/` presuming others would benefit from a concise description of whatever that you're proposing)
## Description
[//]: # (What's it you're proposing?)
Added a note around CELERY_TASK_ALWAYS_EAGER = True in docker config for local development. This causes tasks to be executed on the 'main' thread rather than by the workers. I understand why that might be desirable, but thought it worth calling out incase (like me) it makes people think something is broken.
## Rationale
[//]: # (Why does the project need that?)
Ease of use/troubleshooting
## Use case(s) / visualization(s)
[//]: # ("Better to see something once than to hear about it a thousand times.")
sorl-thumbnail serialized and deserializes the storage class and during this
process location parameter is lost if factory is used. Using a full-fledge
storage class fixes this issue.
See: https://stackoverflow.com/a/18046120/104731
* Add all internal IPs for multiple docker networks
When developing with modified docker-compose.yml that contains multiple
network definitions, all networks gateways of the created container
should be added to INTERNAL_IPS, otherwise Django-Debug-Toolbar will not
work.
* Add @flyudvik to contributors
* Convert old-styled string formatting to f-string
* Update flake8 explicit version to 3.5.0
* Make tox.ini in sync with requirements.txt
* Fix annoying flake8 F405
* 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
When creating a Mailgun add-on on Heroku, the app gets some environment
variables by default:
MAILGUN_API_KEY
MAILGUN_DOMAIN
However, the cookiecutter names do not match and requires a manual step
from the user deploying. It's used elsewhere but shouldn't harm the
other deployment methods to rename these variables.
While updating the docs I noticed a variable that appear unused
DJANGO_MAILGUN_SERVER_NAME so this removes it from the documentation.
Since config/production.py sets a new value for `DATABASES['default']`, the `DATABASES['default']['ATOMIC_REQUESTS'] = True` setting from base gets overridden. So it's probably a good idea to add it back.
* Fix ./hooks/pre_gen_project.py asking user to select an option once only
+ prettify output
* Fix pre_gen hook not really exiting when it should
* Refactor & prettify ./hooks/post_gen_project.py
* Ensure same POSTGRES_USER is set across environments
+ get rid of env.example in favor of pre-generated .env.
* Set CONN_MAX_AGE to 60 seconds -- fixes#710
Setting the value in the production config.
* Get CONN_MAX_AGE from the environment, default to 60 in .env
* Add test for CONN_MAX_AGE setting
* Remove duplication in default value & test cleanup
* Remove test for CONN_MAX_AGE value in settings
* More inline docs for DATABASES variable
Use of database url is not part of Django, but comes from django-environ. Was initially confusing where feature came from, as link points to offical django docs.
* Contributors update
