1👍
The Problem
The issue is the same for Django 1.7 and 1.8 and for foreseeable future version. It is not impossible to happen with 1.6 and earlier versions but unlikely.
The issue is that if you use the configuration most likely to be used for a Django project, then Django CMS will cause an access to the cache to be made whenever the cms
application is initialized.
Here is what happens when you run a management command, with some irrelevant steps omitted:
-
Django goes through the app initialization procedure. (Documented here.) When it gets to
django.contrib.admin
, it uses the defaultAppConfig
for this app. -
The default
AppConfig
foradmin
callsadmin
‘sautodiscover()
function. (Documented here.) -
Eventually
autodiscover()
gets tocms
‘ ownadmin.py
file, and loads it. This file initiates the discovery of Django CMS’ plugins, which in turn causes Django CMS to invalidate its page cache. So you get a cache access there, which fails because your cache service is not turned on.
The Solution
What you can do is, as the documentation about admin explains, use django.contrib.admin.apps.SimpleAdminConfig
in your INSTALLED_APPS
rather than django.contrib.admin
. This app configuration does not call autodiscover()
automatically. When you use this configuration, then you must call autodiscover()
yourself. Putting the call in your project-wide urls.py
, like we were required to do prior to 1.7, is your best bet:
from django.contrib import admin
admin.autodiscover()
The above should make it clear that the OP’s problem is unlikely to happen with Django versions prior to 1.6. People who followed Django’s documentation to configure their project would have the call to autodiscover()
in their urls.py
file, which is read only when a network query is made. However, the problem can happen for for people who diverged from the recommended practices and ended up with a project that calls autodiscover()
elsewhere.