(admin.E402) 'django.contrib.auth.context_processors.auth' must be enabled

Using Django Getting Started
1

Hi,

I’m a novice with this framework, but have an old django-1.6 project I started and want to work on again. I have a new install with django-5.0.2 and python-3.11

I’ve fixed a few deprecated details using check, but I can’t figure out how to get past (admin.E402)

‘django.contrib.auth.context_processors.auth’ must be enabled in DjangoTemplates (TEMPLATES) if using the default auth backend in order to use the admin application.

I think I had some kind of auth in the old version, but I don’t care if it’s disabled globally for now, just to get it working on localhost. (I do want it working eventually.)

I’m just hacking at the moment, but it will be great if I can get the project working, and not have to recreate it from scratch.

My settings.py has…

TEMPLATES = [
    {
        "BACKEND": "django.template.backends.django.DjangoTemplates",
        "DIRS": [os.path.join(PROJECT_PATH, 'templates/'),],
        "APP_DIRS": True,

        "OPTIONS": {
            'context_processors': [
                'django.contrib.messages.context_processors.messages',
            ],
        },        
    },
]    

INSTALLED_APPS = (
    'django.contrib.sites',
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
  . . 
)

MIDDLEWARE = (
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware'
    'django.middleware.common.CommonMiddleware',
    'django.middleware.csrf.CsrfViewMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
    'django.middleware.clickjacking.XFrameOptionsMiddleware',
)

Any suggestions appreciated! :slight_smile:

2

If you start a project from scratch, using the django-admin startproject command, it creates a TEMPLATES setting containing these four context_processors:

  'context_processors': [
      'django.template.context_processors.debug',
      'django.template.context_processors.request',
      'django.contrib.auth.context_processors.auth',
      'django.contrib.messages.context_processors.messages',
  ],

What I suggest you do is to start a new project to see what a current settings.py file looks like, and compare all the settings in your old project with what’s current.

1 Like
3

Hi Ken,

I agree. If my own classes are going to work with the newer Django, it won’t be too difficult to port them over to a new project.

I was just trying to spin things up to get a quick idea of where it was at. I was probably dreaming…

Btw, I noticed that some entries in the MIDDLEWARE list are order sensitive. Is this a common thing? It suggests interdependencies…

4

Yes. Middleware is called in order.

More of functional dependencies, not code interdependencies.

For example, you may have middleware that checks request.user for some reason. That code isn’t going to work unless the current user object is assigned to that request.

Or, you may have middleware that compresses and decompresses data. You don’t want middleware adding data to the response after it has been compressed. Nor do you want to examine data in the request before it has been decompressed.

So yes, there are some requirements built into the order that the middleware is called. But it’s almost always based on how they interact with the requests and responses, not on the code itself.

1 Like
5

More of functional dependencies, not code interdependencies.

Ah, I see. So more like a chain of filters than a list of includes. All the more reason to have the framework manage changes!

6

I was surprised startproject didn’t end up with a runnable instance, but I got this after running testserver…

CommandError: Error: No database fixture specified. Please provide the path of at least one fixture in the command line.

What’s the minimum database and how do I specify it? I’ll use sqlite anyway, which I understood was the default.

7

See the docs for testserver.

This error message is not saying you don’t have a database defined, it’s saying you haven’t specified the data fixtures to use to populate that database.

Your database definition is specified in the DATABASES section of your settings file.

See part 2 of the Official Django Tutorial for some information on getting started with databases.

This is not quite an accurate statement. There is no “default” database, it must be specified in the DATABASES setting. However, if you use the startproject command to start the project, it defines a sqlite database in the settings.

8

Thanks! very helpful. Last question: what would be the minimum possible fixture? Does it necessarily involve adding a new Python file or class?

9

It depends upon what you want to do with this.

In most general cases, you use runserver to run your project. You would only use test server if you want to test your application with data that isn’t normally in your database.

10

Haha, yes sorry, just realised I’d asked a dumb question.

I just wanted to get the server up. All good, thank you. :slight_smile: