Opened 13 years ago

Closed 12 years ago

Last modified 12 years ago

#16637 closed Bug (invalid)

Admin site gives DoesNoteExist at /admin/

Reported by: camey@… Owned by: nobody
Component: Documentation Version: 1.4
Severity: Normal Keywords:
Cc: charette.s@… Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: yes UI/UX: no

Description

After enabling the admin site in settings.py and urls.py the admin site fails to come up and gives the error above. It appears that there is a missing step that isn't mentioned in the tutorial.


from django.contrib.sites.models import Site
import settings

Site(id=settings.SITE_ID, domain="localhost", name="mysite").save()


After adding that I was able to get the admin login screen to come up.

Change History (5)

comment:1 by anonymous, 13 years ago

Resolution: invalid
Status: newclosed

Not a bug

comment:2 by Aymeric Augustin, 13 years ago

The default site is supposed to be added during syncdb.

If you resolved the problem and closed your own ticket without logging in, fine. If it was someone else and you still encounter the problem, please provide more information, basically anything that could explain why the default site object isn't created during syncdb.

comment:3 by Bill Ellis, 12 years ago

Resolution: invalid
Status: closedreopened
Version: 1.31.4

This caught me out too.

In 1.4, default INSTALLED_APPS includes django.contrib.sites.
If we do syncdb, this sql is executed:

a$ python manage.py sqlall sites
BEGIN;
CREATE TABLE `django_site` (
    `id` integer AUTO_INCREMENT NOT NULL PRIMARY KEY,
    `domain` varchar(100) NOT NULL,
    `name` varchar(50) NOT NULL
)
;
COMMIT;

Note that the table is empty. If following the polls tutorial (like I was doing) the presence of this empty table leads to the "DoesNoteExist at /admin/".

There are loads of fixes/workarounds ; chuck some data into the table, use the one liner above, comment out "django.contrib.sites" before the first syncdb -- but for new folk like me, this was a bit confusing, and not easy to google.

Perhaps, for 1.4 documentation, adjust the polls tutorial to tell user to comment out "django.contrib.sites" before the first syncdb.
Perhaps, for next version, don't have "django.contrib.sites" as a default / or get it to have nicer syncdb behaviour.

comment:4 by Simon Charette, 12 years ago

Cc: charette.s@… added
Resolution: invalid
Status: reopenedclosed

As pointed out by @aaugustin the default site is supposed to be added during syncdb when the table is created.

Running python manage.py sqlall sites doesn't output the full SQL executed for the contrib.sites app -- only the SQL needed for table and constraint creation related to models. Did you actually run syncdb or just manually executed SQL returned by sqlall for all your INSTALLED_APPS?

I just tested it with a clean 1.4 install and the default site is correctly created when running syncdb.

simon@simon-laptop:~/Bureau$ virtualenv ticket_16637_venv --no-site-packages
New python executable in ticket_16637_venv/bin/python
Installing setuptools............done.
Installing pip...............done.
simon@simon-laptop:~/Bureau$ source ticket_16637_venv/bin/activate
(ticket_16637_venv)simon@simon-laptop:~/Bureau$ pip install django==1.4
Downloading/unpacking django==1.4
  Downloading Django-1.4.tar.gz (7.6Mb): 7.6Mb downloaded
  Running setup.py egg_info for package django
    
Installing collected packages: django
  Running setup.py install for django
    changing mode of build/scripts-2.7/django-admin.py from 664 to 775
    
    changing mode of /home/simon/Bureau/ticket_16637_venv/bin/django-admin.py to 775
Successfully installed django
Cleaning up...
(ticket_16637_venv)simon@simon-laptop:~/Bureau$ django-admin.py startproject ticket_16637
(ticket_16637_venv)simon@simon-laptop:~/Bureau$ cd ticket_16637
(ticket_16637_venv)simon@simon-laptop:~/Bureau/ticket_16637$ vim ticket_16637/settings.py 
(ticket_16637_venv)simon@simon-laptop:~/Bureau/ticket_16637$ chmod +x manage.py 
(ticket_16637_venv)simon@simon-laptop:~/Bureau/ticket_16637$ ./manage.py syncdb
Creating tables ...
Creating table auth_permission
Creating table auth_group_permissions
Creating table auth_group
Creating table auth_user_user_permissions
Creating table auth_user_groups
Creating table auth_user
Creating table django_content_type
Creating table django_session
Creating table django_site

You just installed Django's auth system, which means you don't have any superusers defined.
Would you like to create one now? (yes/no): no
Installing custom SQL ...
Installing indexes ...
Installed 0 object(s) from 0 fixture(s)
(ticket_16637_venv)simon@simon-laptop:~/Bureau/ticket_16637$ ./manage.py shell
Python 2.7.3 (default, Apr 20 2012, 22:39:59) 
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>> from django.contrib.sites.models import Site
>>> Site.objects.get()
<Site: example.com>

Note that deleting the default Site instance and re-running syncdb won't re-create a new one.

Resolving as invalid until you can provide steps to reproduce you issue.

comment:5 by anonymous, 12 years ago

Hi,

Thanks for this - you're right. Please close / ignore.

The problem was in a script I wrote to automate the deployment. Anyway, tracing back the code you cited, I discovered it was not getting executed due to a bug in the way I was invoking syncdb (a dumb pexepect error - oops..).

On the plus side, you've probably saved me some significant head scratching ; thanks!

Note: See TracTickets for help on using tickets.
Back to Top