update template engine to work with Django 1.8 TEMPLATE setting

[wq]

update template engine to work with Django 1.8 TEMPLATE setting

[joshglenn]

Good to know. After looking into this further this morning, I found the problem. It turns out the problem in my case had nothing to do with the settings themselves, old or new. I needed to have my app listed before django.contrib.admin in the application loading order. Otherwise it found the original template first and ignored mine. From the django 1.7 documentation here:

The order of INSTALLED_APPS is significant! For example, if you want to customize the Django admin, you might choose to override the standard admin/base_site.html template, from django.contrib.admin, with your own admin/base_site.html in myproject.polls. You must then make sure that your myproject.polls comes before django.contrib.admin in INSTALLED_APPS, otherwise django.contrib.admin’s will be loaded first and yours will be ignored.

[sheppard]

We haven't fully updated wq.db's template engine to work with the new Django 1.8 template infrastructure. The main holdup is the need to be backwards-compatible with Django 1.7. Once Django 1.9 comes out (this fall) we will drop 1.7 support, create a proper BACKEND, and and this will be a lot simpler.

In the meantime, you could try one of the following workarounds:

• Use Django 1.7-style settings to configure the alternate template loaders. Django 1.8 should be able to pick them up and use them, though it will be a little harder to make it clear which templates are Mustache and which are Jinja.
• Run a separate Django WSGI instance for the admin.
• Create a Django 1.8-compatible Mustache template loader as a separate package (which we might do anyway). Django-Pystache already exists but it's a bit outdated.

[joshglenn]

I did however, put my settings back like they were:

Like this:

TEMPLATE_DIRS = (
   os.path.join(BASE_DIR, 'templates'),
)

instead of:

TEMPLATE_DIRS = (
    os.path.join(BASE_DIR, 'templates'),
    os.path.join(BASE_DIR, 'db/myapp/templates'),
)

...as the application directory gets read without explicitly calling it (as in the second case above, which actually causes my template to be read using pystaches render which was not the desired result).