* Add support for Webpack as frontend pipeline
* Rename CI jobs
* Fix a couple of issues with Webpack + Docker
* Don't include Boostrap CSS from CDN with Webpack
* Rename variable
* Set publicPath in prod webpack config
* Fix removal of SASS files in post-gen hooks
* Add Webpack to readme usage section
* Run Django + Webpack dev server concurrently without Docker
* Fix async runserver command with Gulp/Webpack
* Upgrade django-webpack-loader to 1.5.0
* Pass variables required by Webpack at build time
* Upgrade django-webpack-loader to 1.7.0
* Add missing condition
* Add support for Azure Storage + Webpack
* Whitespaces
* Rename ROOT_DIR -> BASE_DIR
* Rename jobs
* Bump django-webpack-loader to latest
* Document limitation of Docker + Webpack + no Whitenoise
* Update section on custom Bootstrap compilation in generated readme
* Adds swagger api documentation when drf is enabled
Changes
* Integrate drf-spectacular module
* Added routes and tests for swagger-ui
* Removes swagger ui tests when drf is not enabled
* Changes url names and documentation title
* Apply suggestions from code review
Co-authored-by: Fábio C. Barrionuevo da Luz <bnafta@gmail.com>
Co-authored-by: Bruno Alla <browniebroke@users.noreply.github.com>
* Fixes typos and linting issues
* Update domain in swagger description
Co-authored-by: Fábio C. Barrionuevo da Luz <bnafta@gmail.com>
Co-authored-by: Fábio C. Barrionuevo da Luz <bnafta@gmail.com>
Co-authored-by: Bruno Alla <browniebroke@users.noreply.github.com>
* 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_`.
