aldryn-boilerplates 0.4

Installation

pip install aldryn-boilerplates

Configuration

INSTALLED_APPS = [
    ...
    'aldryn_boilerplates',
    ...
]

TEMPLATE_CONTEXT_PROCESSORS = [
    ...
    'aldryn_boilerplates.context_processors.boilerplate',
]

STATICFILES_FINDERS = [
    'django.contrib.staticfiles.finders.FileSystemFinder',
    # important! place right before django.contrib.staticfiles.finders.AppDirectoriesFinder
    'aldryn_boilerplates.staticfile_finders.AppDirectoriesFinder',
    'django.contrib.staticfiles.finders.AppDirectoriesFinder',
]

TEMPLATE_LOADERS = [
    'django.template.loaders.filesystem.Loader',
    # important! place right before django.template.loaders.app_directories.Loader
    'aldryn_boilerplates.template_loaders.AppDirectoriesLoader',
    'django.template.loaders.app_directories.Loader',
]

Now set the name of the boilerplate you want to use in your project:

ALDRYN_BOILERPLATE_NAME = 'standard'

Adding aldryn-boilerplate support to existing packages

The recommended approach is to add a dependency to aldryn-boilerplates and to move existing static and template files to a boilerplate folder (completely remove static and templates). If you’re in the process of re-factoring your existing templates with something new, put them into the legacy boilerplate folder and set ALDRYN_BOILERPLATE_NAME='legacy' on projects that are still using the old templates. The new and shiny project can then use ALDRYN_BOILERPLATE_NAME='standard' to use the new Standard Aldryn Boilerplate (aldryn-boilerplate-standard). Or any other boilerplate for that matter.

Removing static and templates has the benefit of removing likely deprecated templates from the very prominent location, that will confuse newcomers. It also prevents having not-relevant templates and static files messing up your setup.