torchbox/cookiecutter-wagtail

cookiecutter-wagtail's Issues

django version

in https://github.com/torchbox/wagtail-cookiecutter/blob/master/%7B%7Bcookiecutter.repo_name%7D%7D/puppet/%7B%7Bcookiecutter.repo_name%7D%7D-production.pp#L18 (and the staging file too)

django_version   => '1.7',

but in https://github.com/torchbox/wagtail-cookiecutter/blob/master/%7B%7Bcookiecutter.repo_name%7D%7D/requirements.txt#L1

Django==1.8.3

RFC: A theme app

This one would mainly be of interest to FE devs (ping @davecranwell)

The idea is to add a new app to the template called "theme" which would contain:

• All global static files
• All base templates (base.html, 404.html, 500.html)
• Any template tags needed by the theme (eg. a pagination_links inclusion tag)
• (bonus) A component library and styleguide view for developers

Themes could be copied from existing sites which may make initial development easier. Not very experienced developers would definitely benefit from starting with a premade theme as well.

This would also solve the issue with all templates needing to be in an app in order to be translated.

Make it easier to install dependencies

There's no obvious way to install the dependencies if you're not using Vagrant.

Need comment adding re the <meta http-equiv="X-UA-Compatible" content="IE=edge"> tag

This tag should only be used if support for IE 8 and 9 is required, see http://stackoverflow.com/questions/6771258/what-does-meta-http-equiv-x-ua-compatible-content-ie-edge-do

Installation on a MBP results in error

I get the following when trying to install on a Macbook Pro:

Unable to create file 'docs/make.bat'
Error message: 'project_name' is undefined

This is right after entering the 'project_name' & 'repo_name'

I'm using the following to install: cookiecutter https://github.com/torchbox/cookiecutter-wagtail.git

Show manage.py instead of dj on start page

If the user isn't using our Vagrant box,they are unable to run the dj command.

Still maintained?

This package is a couple of years behind now, and I'm wondering if it is superceded by.

• https://github.com/torchbox/vagrant-django-template
• https://github.com/torchbox/bakerydemo-p13n
• ...something else I'm not aware of.

Django 1.8 support

The following error is produced when running vagrant up after changing the requirements file to specify

Django==1.8.2
wagtail==1.0b2

==> default:   Applying home.0002_create_homepage...
==> default: Traceback (most recent call last):
==> default:   File "/home/vagrant/.virtualenvs/wagtailproj/lib/python3.4/site-packages/django/db/models/query.py", line 405, in get_or_create
==> default:     return self.get(**lookup), False
==> default:   File "/home/vagrant/.virtualenvs/wagtailproj/lib/python3.4/site-packages/django/db/models/query.py", line 334, in get
==> default:     self.model._meta.object_name
==> default: __fake__.DoesNotExist: ContentType matching query does not exist.
==> default:
==> default: During handling of the above exception, another exception occurred:
==> default:
==> default: Traceback (most recent call last):
==> default:   File "/vagrant/manage.py", line 10, in <module>
==> default:     execute_from_command_line(sys.argv)
==> default:   File "/home/vagrant/.virtualenvs/wagtailproj/lib/python3.4/site-packages/django/core/management/__init__.py", line 338, in execute_from_command_line
==> default:     utility.execute()
==> default:   File "/home/vagrant/.virtualenvs/wagtailproj/lib/python3.4/site-packages/django/core/management/__init__.py", line 330, in execute
==> default:     self.fetch_command(subcommand).run_from_argv(self.argv)
==> default:   File "/home/vagrant/.virtualenvs/wagtailproj/lib/python3.4/site-packages/django/core/management/base.py", line 390, in run_from_argv
==> default:     self.execute(*args, **cmd_options)
==> default:   File "/home/vagrant/.virtualenvs/wagtailproj/lib/python3.4/site-packages/django/core/management/base.py", line 441, in execute
==> default:     output = self.handle(*args, **options)
==> default:   File "/home/vagrant/.virtualenvs/wagtailproj/lib/python3.4/site-packages/django/core/management/commands/migrate.py", line 221, in handle
==> default:     executor.migrate(targets, plan, fake=fake, fake_initial=fake_initial)
==> default:   File "/home/vagrant/.virtualenvs/wagtailproj/lib/python3.4/site-packages/django/db/migrations/executor.py", line 110, in migrate
==> default:     self.apply_migration(states[migration], migration, fake=fake, fake_initial=fake_initial)
==> default:   File "/home/vagrant/.virtualenvs/wagtailproj/lib/python3.4/site-packages/django/db/migrations/executor.py", line 147, in apply_migration
==> default:     state = migration.apply(state, schema_editor)
==> default:   File "/home/vagrant/.virtualenvs/wagtailproj/lib/python3.4/site-packages/django/db/migrations/migration.py", line 115, in apply
==> default:     operation.database_forwards(self.app_label, schema_editor, old_state, project_state)
==> default:   File "/home/vagrant/.virtualenvs/wagtailproj/lib/python3.4/site-packages/django/db/migrations/operations/special.py", line 183, in database_forwards
==> default:     self.code(from_state.apps, schema_editor)
==> default:   File "/vagrant/wagtailproj/home/migrations/0002_create_homepage.py", line 19, in create_homepage
==> default:     model='homepage', app_label='home', defaults={'name': 'Homepage'})
==> default:   File "/home/vagrant/.virtualenvs/wagtailproj/lib/python3.4/site-packages/django/db/models/manager.py", line 127, in manager_method
==> default:     return getattr(self.get_queryset(), name)(*args, **kwargs)
==> default:   File "/home/vagrant/.virtualenvs/wagtailproj/lib/python3.4/site-packages/django/db/models/query.py", line 407, in get_or_create
==> default:     return self._create_object_from_params(lookup, params)
==> default:   File "/home/vagrant/.virtualenvs/wagtailproj/lib/python3.4/site-packages/django/db/models/query.py", line 439, in _create_object_from_params
==> default:     obj = self.create(**params)
==> default:   File "/home/vagrant/.virtualenvs/wagtailproj/lib/python3.4/site-packages/django/db/models/query.py", line 346, in create
==> default:     obj = self.model(**kwargs)
==> default:   File "/home/vagrant/.virtualenvs/wagtailproj/lib/python3.4/site-packages/django/db/models/base.py", line 480, in __init__
==> default:     raise TypeError("'%s' is an invalid keyword argument for this function" % list(kwargs)[0])
==> default: TypeError: 'name' is an invalid keyword argument for this function

Database settings getting overwritten?

Just tried deploying a simple project based on this template to Dokku. Despite modifying settings.py to pick up the correct environment variables for DATABASES they seem to be getting overwritten somewhere:

Database

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.postgresql_psycopg2',
        'NAME': os.environ['DB_NAME'],
        # number of seconds database connections should persist for
        'CONN_MAX_AGE': 600,
        'USER': os.environ['DB_USER'],
        'HOST': os.environ['DB_HOST'],
        'PASSWORD': os.environ['DB_PASS'],
        'PORT': os.environ['DB_PORT'],

        # User, host and port can be configured by the PGUSER, PGHOST and
        # PGPORT environment variables (these get picked up by libpq).
    }
}

What is meant by picked up by libpq? Does this look like it should work with the following env variables:

DB_HOST 172.17.0.10 
DB_NAME aname 
DB_USER auser 
DB_PASS whatever 

If I start shell and print settings.DATABASES I get:

{'default': {'PORT': '', 'AUTOCOMMIT': True, 'ATOMIC_REQUESTS': False, 'TEST': {'CHARSET':     None, 'NAME': None, 'MIRROR': None, 'COLLATION': None}, 'USER': '', 'TIME_ZONE': 'UTC', 'NAME':    'icontractpromo', 'CONN_MAX_AGE': 600, 'PASSWORD': '', 'ENGINE':    'django.db.backends.postgresql_psycopg2', 'OPTIONS': {}, 'HOST': ''}}

However if I run the following snippet:

>>> for key in os.environ.keys():
    ...     print "%30s %s \n" % (key,os.environ[key])

I get all the environment variables returned as I'd expect. Just to be clear the postgres server is running in a seperate Docker container.

Am I missing something simple?

Thanks

404 <title>

On the request of @kaedroho I've added this as a replication of a ticket in the main Wagtail issue list.

As part of the core 404 and 500 pages.

The current template variables don't get completed for 404 or 500 pages as part of cores base.html file.

<title>{% block title %}{% if self.seo_title %}{{ self.seo_title }}{% else %}{{ self.title }}{% endif %}{% endblock %}{% block title_suffix %}{% endblock %}

Neither self.seo_title or self.title exist for 404s or 500s so something relevant should be output instead. I would suggest something containing the response code so that it's easier to track in GA but there is some argument for not presenting the complexity of response codes to users (even if it is just in the page title). Personally I don't agree with this argument.

I can't think of an argument for this to take place on a project by project basis. A developer could always change the content but something should get output as standard.

Make use of REDIS_URL environment variable in settings

dokku/dokku-redis automatically creates an environment variable called REDIS_URL when it gets linked to a container. It's a DSN in a format like this redis://dokku-redis-hello:6379/0

It might be helpful to use this variable in settings/production.py so that further configuration isn't needed.

Licence

The repository doesn't contain any licence file. I have forked it to repurpose it for RocketPod's infrastructure but I want to make sure this is ok and that the code is permissively licenced (preferably BSD) to encourage others to do the same.