#16637 closed Bug (invalid)
Admin site gives DoesNoteExist at /admin/
Reported by: | 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 , 13 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
comment:2 by , 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 , 12 years ago
Resolution: | invalid |
---|---|
Status: | closed → reopened |
Version: | 1.3 → 1.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 , 12 years ago
Cc: | added |
---|---|
Resolution: | → invalid |
Status: | reopened → closed |
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 , 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!
Not a bug