I get the following error when trying to run Django from the command line.

File manage.py, line 8, in <module>
     from django.core.management import execute_from_command_line
ImportError: No module named django.core.management

Any ideas on how to solve this?

It sounds like you do not have django installed. You should check the directory produced by this command:

python -c "from distutils.sysconfig import get_python_lib; print get_python_lib()"

To see if you have the django packages in there.

If there’s no django folder inside of site-packages, then you do not have django installed (at least for that version of python).

It is possible you have more than one version of python installed and django is inside of another version. You can find out all the versions of python if you type python and then press TAB. Here are all the different python’s I have.

$python
python            python2-config    python2.6         python2.7-config  pythonw2.5
python-config     python2.5         python2.6-config  pythonw           pythonw2.6
python2           python2.5-config  python2.7         pythonw2          pythonw2.7

You can do the above command for each version of python and look inside the site-packages directory of each to see if any of them have django installed. For example:

python2.5 -c "from distutils.sysconfig import get_python_lib; print get_python_lib()"
python2.6 -c "from distutils.sysconfig import get_python_lib; print get_python_lib()"

If you happen to find django inside of say python2.6, try your original command with

python2.6 manage.py ...

sudo pip install django --upgrade 

did the trick for me.

I got the same error and I fixed it in this manner:

I had to activate my virtual environment using the following command

source python2.7/bin/activate

Most probably in your manage.py the first line starts with !/usr/bin/python which means you are using the system global python rather than the one in your virtual environment.

so replace

/usr/bin/python

with

~/projectpath/venv/bin/python

and you should be good.

well, I faced the same error today after installing virtualenv and django. For me it was that I had used sudo (sudo pip install django) for installing django, and I was trying to run the manage.py runserver without sudo. I just added sudo and it worked. :)

Are you using a Virtual Environment with Virtual Wrapper? Are you on a Mac?

If so try this:

Enter the following into your command line to start up the virtual environment and then work on it

1.)

source virtualenvwrapper.sh

or

source /usr/local/bin/virtualenvwrapper.sh

2.)

workon [environment name]

Note (from a newbie) – do not put brackets around your environment name

I am having the same problem while running the command-

python manage.py startapp < app_name >

but problem with me is that i was running that command out of virtual environment.So just activate your virtual environment first and run the command again –

This problem occurs when django is not installed on your computer. When django is not installed which means django.core.management module is also is not installed. So it didn’t find this module and it gives error.
For solving this problem we should install django using pip. Open comand line cmd(on windows) and type as

pip install django

This command will install django in your computer. If you don’t have install pip. you should install pip. Here how to install pip on windows

I experience the same thing and this is what I do.

First my installation of

pip install -r requirements.txt

is not on my active environment. So I did is activate my environment then run again the

pip install -r requirements.txt

Okay so it goes like this:

You have created a virtual environment and django module belongs to that environment only.Since virtualenv isolates itself from everything else,hence you are seeing this.

go through this for further assistance:

http://www.swegler.com/becky/blog/2011/08/27/python-django-mysql-on-windows-7-part-i-getting-started/

1.You can switch to the directory where your virtual environment is stored and then run the django module.

2.Alternatively you can install django globally to your python->site-packages by either running pip or easy_install

Command using pip: pip install django

then do this:

import django print (django.get_version()) (depending on which version of python you use.This for python 3+ series)

and then you can run this: python manage.py runserver and check on your web browser by typing :localhost:8000 and you should see django powered page.

Hope this helps.

In case this is helpful to others… I had this issue because my virtualenv defaulted to python2.7 and I was calling Django using Python3 while using Ubuntu.

to check which python my virtualenv was using:

$ which python3
>> /usr/bin/python3

created new virtualenv with python3 specified (using virtualenv wrapper https://virtualenvwrapper.readthedocs.org/en/latest/):

$ mkvirtualenv --python=/usr/bin/python3 ENV_NAME

the python path should now point to the virtualenv python:

$ which python3
>> /home/user/.virtualenvs/ENV_NAME/bin/python3

This also happens if you change the directory structure of your python project (I did this, and then puzzled over the change in behavior). If you do so, you’ll need to change a line in your /bin/activate file. So, say your project was at

/User/me/CodeProjects/coolApp/

and your activate file is at

/User/me/CodeProjects/coolApp/venv/bin/activate

when you set up your project, then you changed your project to

/User/me/CodeProjects/v1-coolApp/

or something. You would then need to open

/User/me/CodeProjects/v1-coolApp/venv/bin/activate

find the line where it says

VIRTUAL_ENV="/User/me/CodeProjects/coolApp"
export VIRTUAL_ENV

and change it to

VIRTUAL_ENV="/User/me/CodeProjects/v1-coolApp"

before reactivating

In my case, I am using Ubuntu. The problem can be that I don’t have the permission to write to that folder as a normal user. You can simply add the sudo before your command and it should work perfectly. In my case sudo python manage.py syncdb.

I had the same issue and the reason I was getting this message was because I was doing “manage.py runserver” whereas doing “python manage.py runserver” fixed it.

I had the same problem and following worked good, you should navigate main folder in your project than type:

source bin/activate 

had the same problem.run command ‘python manage.py migrate’ as root. works fine with root access (sudo python manage.py migrate )

My case I used pyCharm 5 on mac. I also had this problem and after running this command my problem was solved

sudo pip install django --upgrade 

You can try it like so : python3 manage.py migrate (make sur to be in the src/ directory)

You can also try with pip install -r requirements.txt (make sur you see the requirements.txt file when you type ls after the migrate

If after all it still won’t work try pip install django

Hope it helps

You must choose your Project first before running the server , type this workon your_project_name then python manage.py runserver

File and Directory ownership conflict will cause issues here. Make sure the ownership of the directories and files under the project are to the current user. (You can change them using the chown command with the -R option.) Try rerunning the command: this solved the problem for me when running through the “First Django App” sample:

python manage.py startapp polls

I got the same problem trying to use the python manage.py runserver. In my case I just use sudo su. Use the terminal as a root and try it again an it works partially. So I use python manage.py migrate comand and it fix it.

How do I get values from form fields in the django framework? I want to do this in views, not in templates…

Using a form in a view pretty much explains it.

The standard pattern for processing a form in a view looks like this:

def contact(request):
    if request.method == 'POST': # If the form has been submitted...
        form = ContactForm(request.POST) # A form bound to the POST data
        if form.is_valid(): # All validation rules pass
            # Process the data in form.cleaned_data
            # ...

            print form.cleaned_data['my_form_field_name']

            return HttpResponseRedirect('/thanks/') # Redirect after POST
    else:
        form = ContactForm() # An unbound form

    return render_to_response('contact.html', {
        'form': form,
    })

Take your pick:

def my_view(request):

    if request.method == 'POST':
        print request.POST.get('my_field')

        form = MyForm(request.POST)

        print form['my_field'].value()
        print form.data['my_field']

        if form.is_valid():

            print form.cleaned_data['my_field']
            print form.instance.my_field

            form.save()
            print form.instance.id  # now this one can access id/pk

Note: the field is accessed as soon as it’s available.

You can do this after you validate your data.

if myform.is_valid():
  data = myform.cleaned_data
  field = data['field']

Also, read the django docs. They are perfect.

To retrieve data from form which send post request you can do it like this

def login_view(request):
    if(request.POST):
        login_data = request.POST.dict()
        username = login_data.get("username")
        password = login_data.get("password")
        user_type = login_data.get("user_type")
        print(user_type, username, password)
        return HttpResponse("This is a post request")
    else:
        return render(request, "base.html")

I use django 1.7+ and python 2.7+, the solution above dose not work. And the input value in the form can be got use POST as below (use the same form above):

if form.is_valid():
  data = request.POST.get('my_form_field_name')
  print data

Hope this helps.

I’m working on a large Django app, the vast majority of which requires a login to access. This means that all throughout our app we’ve sprinkled:

@login_required
def view(...):

That’s fine, and it works great as long as we remember to add it everywhere! Sadly sometimes we forget, and the failure often isn’t terribly evident. If the only link to a view is on a @login_required page then you’re not likely to notice that you can actually reach that view without logging in. But the bad guys might notice, which is a problem.

My idea was to reverse the system. Instead of having to type @login_required everywhere, instead I’d have something like:

@public
def public_view(...):

Just for the public stuff. I tried to implement this with some middleware and I couldn’t seem to get it to work. Everything I tried interacted badly with other middleware we’re using, I think. Next up I tried writing something to traverse the URL patterns to check that everything that’s not @public was marked @login_required – at least then we’d get a quick error if we forgot something. But then I couldn’t figure out how to tell if @login_required had been applied to a view…

So, what’s the right way to do this? Thanks for the help!

Middleware may be your best bet. I’ve used this piece of code in the past, modified from a snippet found elsewhere:

import re

from django.conf import settings
from django.contrib.auth.decorators import login_required


class RequireLoginMiddleware(object):
    """
    Middleware component that wraps the login_required decorator around
    matching URL patterns. To use, add the class to MIDDLEWARE_CLASSES and
    define LOGIN_REQUIRED_URLS and LOGIN_REQUIRED_URLS_EXCEPTIONS in your
    settings.py. For example:
    ------
    LOGIN_REQUIRED_URLS = (
        r'/topsecret/(.*)$',
    )
    LOGIN_REQUIRED_URLS_EXCEPTIONS = (
        r'/topsecret/login(.*)$',
        r'/topsecret/logout(.*)$',
    )
    ------
    LOGIN_REQUIRED_URLS is where you define URL patterns; each pattern must
    be a valid regex.

    LOGIN_REQUIRED_URLS_EXCEPTIONS is, conversely, where you explicitly
    define any exceptions (like login and logout URLs).
    """
    def __init__(self):
        self.required = tuple(re.compile(url) for url in settings.LOGIN_REQUIRED_URLS)
        self.exceptions = tuple(re.compile(url) for url in settings.LOGIN_REQUIRED_URLS_EXCEPTIONS)

    def process_view(self, request, view_func, view_args, view_kwargs):
        # No need to process URLs if user already logged in
        if request.user.is_authenticated():
            return None

        # An exception match should immediately return None
        for url in self.exceptions:
            if url.match(request.path):
                return None

        # Requests matching a restricted URL pattern are returned
        # wrapped with the login_required decorator
        for url in self.required:
            if url.match(request.path):
                return login_required(view_func)(request, *view_args, **view_kwargs)

        # Explicitly return None for all non-matching requests
        return None

Then in settings.py, list the base URLs you want to protect:

LOGIN_REQUIRED_URLS = (
    r'/private_stuff/(.*)$',
    r'/login_required/(.*)$',
)

As long as your site follows URL conventions for the pages requiring authentication, this model will work. If this isn’t a one-to-one fit, you may choose to modify the middleware to suit your circumstances more closely.

What I like about this approach – besides removing the necessity of littering the codebase with @login_required decorators – is that if the authentication scheme changes, you have one place to go to make global changes.

There is an alternative to putting a decorator on each view function. You can also put the login_required() decorator in the urls.py file. While this is still a manual task, at least you have it all in one place, which makes it easier to audit.

e.g.,

    from my_views import home_view

    urlpatterns = patterns('',
        # "Home":
        (r'^$', login_required(home_view), dict(template_name='my_site/home.html', items_per_page=20)),
    )

Note that view functions are named and imported directly, not as strings.

Also note that this works with any callable view object, including classes.

In Django 2.1, we can decorate all methods in a class with:

from django.contrib.auth.decorators import login_required
from django.utils.decorators import method_decorator
from django.views.generic import TemplateView

@method_decorator(login_required, name='dispatch')
class ProtectedView(TemplateView):
    template_name = 'secret.html'

UPDATE: I have also found the following to work:

from django.contrib.auth.mixins import LoginRequiredMixin
from django.views.generic import TemplateView

class ProtectedView(LoginRequiredMixin, TemplateView):
    template_name = 'secret.html'

and set LOGIN_URL = '/accounts/login/' in your settings.py

It’s hard to change the built-in assumptions in Django without reworking the way url’s are handed off to view functions.

Instead of mucking about in Django internals, here’s an audit you can use. Simply check each view function.

import os
import re

def view_modules( root ):
    for path, dirs, files in os.walk( root ):
        for d in dirs[:]:
            if d.startswith("."):
                dirs.remove(d)
        for f in files:
            name, ext = os.path.splitext(f)
            if ext == ".py":
                if name == "views":
                    yield os.path.join( path, f )

def def_lines( root ):
    def_pat= re.compile( "\n(\S.*)\n+(^def\s+.*:$)", re.MULTILINE )
    for v in view_modules( root ):
        with open(v,"r") as source:
            text= source.read()
            for p in def_pat.findall( text ):
                yield p

def report( root ):
    for decorator, definition in def_lines( root ):
        print decorator, definition

Run this and examine the output for defs without appropriate decorators.

Here is a middleware solution for django 1.10+

The middlewares in have to be written in a new way in django 1.10+.

Code

import re

from django.conf import settings
from django.contrib.auth.decorators import login_required


class RequireLoginMiddleware(object):

    def __init__(self, get_response):
         # One-time configuration and initialization.
        self.get_response = get_response

        self.required = tuple(re.compile(url)
                              for url in settings.LOGIN_REQUIRED_URLS)
        self.exceptions = tuple(re.compile(url)
                                for url in settings.LOGIN_REQUIRED_URLS_EXCEPTIONS)

    def __call__(self, request):

        response = self.get_response(request)
        return response

    def process_view(self, request, view_func, view_args, view_kwargs):

        # No need to process URLs if user already logged in
        if request.user.is_authenticated:
            return None

        # An exception match should immediately return None
        for url in self.exceptions:
            if url.match(request.path):
                return None

        # Requests matching a restricted URL pattern are returned
        # wrapped with the login_required decorator
        for url in self.required:
            if url.match(request.path):
                return login_required(view_func)(request, *view_args, **view_kwargs)

        # Explicitly return None for all non-matching requests
        return None

Installation

1. Copy the code into your project folder, and save as middleware.py

2. Add to MIDDLEWARE

   MIDDLEWARE = [ … ‘.middleware.RequireLoginMiddleware’, # Require login ]

3. Add to your settings.py:

LOGIN_REQUIRED_URLS = (
    r'(.*)',
)
LOGIN_REQUIRED_URLS_EXCEPTIONS = (
    r'/admin(.*)$',
)
LOGIN_URL = '/admin'

Sources:

1. This answer by Daniel Naab

2. Django Middleware tutorial by Max Goodridge

3. Django Middleware Docs

Inspired by Ber’s answer I wrote a little snippet that replaces the patterns function, by wrapping all of the URL callbacks with the login_required decorator. This works in Django 1.6.

def login_required_patterns(*args, **kw):
    for pattern in patterns(*args, **kw):
        # This is a property that should return a callable, even if a string view name is given.
        callback = pattern.callback

        # No property setter is provided, so this will have to do.
        pattern._callback = login_required(callback)

        yield pattern

Using it works like this (the call to list is required because of the yield).

urlpatterns = list(login_required_patterns('', url(r'^$', home_view)))

You can’t really win this. You simply must make a declaration of the authorization requirements. Where else would you put this declaration except right by the view function?

Consider replacing your view functions with callable objects.

class LoginViewFunction( object ):
    def __call__( self, request, *args, **kw ):
        p1 = self.login( request, *args, **kw )
        if p1 is not None:
            return p1
        return self.view( request, *args, **kw )
    def login( self, request )
        if not request.user.is_authenticated():
            return HttpResponseRedirect('/login/?next=%s' % request.path)
    def view( self, request, *args, **kw ):
        raise NotImplementedError

You then make your view functions subclasses of LoginViewFunction.

class MyRealView( LoginViewFunction ):
    def view( self, request, *args, **kw ):
        .... the real work ...

my_real_view = MyRealView()  

It doesn’t save any lines of code. And it doesn’t help the “we forgot” problem. All you can do is examine the code to be sure that the view functions are objects. Of the right class.

But even then, you’ll never really know that every view function is correct without a unit test suite.

Would be possible to have a single starting point for all the urls in a sort of include and that decorate it using this packages https://github.com/vorujack/decorate_url.

There’s an app that provides a plug-and-play solution to this:

https://github.com/mgrouchy/django-stronghold

pip install django-stronghold

# settings.py

INSTALLED_APPS = (
    #...
    'stronghold',
)

MIDDLEWARE_CLASSES = (
    #...
    'stronghold.middleware.LoginRequiredMiddleware',
)

I’ve googled around for this, but I still have trouble relating to what Django defines as “apps”.

Should I create a new app for each piece of functionality in a site, even though it uses models from the main project?

Do you guys have good rule of thumb of when to split off a new app, and when to keep functionality together with the “main project” or other apps?

James Bennett has a wonderful set of slides on how to organize reusable apps in Django.

I prefer to think of Django applications as reusable modules or components than as “applications”.

This helps me encapsulate and decouple certain features from one another, improving re-usability should I decide to share a particular “app” with the community at large, and maintainability.

My general approach is to bucket up specific features or feature sets into “apps” as though I were going to release them publicly. The hard part here is figuring out how big each bucket is.

A good trick I use is to imagine how my apps would be used if they were released publicly. This often encourages me to shrink the buckets and more clearly define its “purpose”.

Here is the updated presentation on 6 September 2008.

DjangoCon 2008: Reusable Apps @7:53

Slide: Reusable_apps.pdf

Taken from the slide

Should this be its own application?

• Is it completely unrelated to the app’s focus?
• Is it orthogonal to whatever else I’m doing?
• Will I need similar functionality on other sites?

If any of them is “Yes”? Then best to break it into a separate application.

I tend to create new applications for each logically separate set of models. e.g.:

• User Profiles
• Forum Posts
• Blog posts

The rule I follow is it should be a new app if I want to reuse the functionality in a different project.

If it needs deep understanding of the models in your project, it’s probably more cohesive to stick it with the models.

The two best answers to this question I’ve found around the web are:

1. The Reusable Apps Talk (slides)(video) also mentioned in other answers. Bennett, the author and Django contributor, regularly publishes apps for others to use and has a strong viewpoint towards many small apps.
2. Doordash’s Tips for Django at Scale which gives the opposite advice and says in their case they migrated to one single app after starting with many separate apps. They ran into problems with the migration dependency graph between apps.

Both sources agree that you should create a separate app in the following situations:

• If you plan to reuse your app in another Django project (especially if you plan to publish it for others to reuse).
• If the app has few or no dependencies between it and another app. Here you might be able to imagine an app running as its own microservice in the future.

An ‘app’ could be many different things, it all really comes down to taste. For example, let’s say you are building a blog. Your app could be the entire blog, or you could have an ‘admin’ app, a ‘site’ app for all of the public views, an ‘rss’ app, a ‘services’ app so developers can interface with the blog in their own ways, etc.

I personally would make the blog itself the app, and break out the functionality within it. The blog could then be reused rather easily in other websites.

The nice thing about Django is that it will recognize any models.py file within any level of your directory tree as a file containing Django models. So breaking your functionality out into smaller ‘sub apps’ within an ‘app’ itself won’t make anything more difficult.