Opened 5 years ago

Closed 5 years ago

#11918 closed (invalid)

Admin URLs troubles

Reported by: camilonova Owned by: nobody
Component: Contrib apps Version: 1.1
Severity: Keywords: admin urls 404
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description

Hi now i have:
Django version 1.2 pre-alpha

SNV Trunk Revision: 11585

When i start a new project:
$ django-admin.py startproject foo

by default creates the file urls.py in the folder foo, and this file has the line:
(r'admin/', include(admin.site.urls)),

to get easy to uncomment for access to admin, this line works fine in DEBUG=True, but when DEBUG=False admin says it dont find any module pages, if i just change that line for:
(r'admin/(.*)', admin.site.root),

works great in DEBUG=False and DEBUG=True, why dont you change the default generation of this line, or tell us what happen in this case.

Cheers

Attachments (1)

urls.py (633 bytes) - added by camilonova 5 years ago.

Download all attachments as: .zip

Change History (5)

Changed 5 years ago by camilonova

comment:1 Changed 5 years ago by camilonova

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

Hi now i have: Django version 1.2 pre-alpha

SNV Trunk Revision: 11585

When i start a new project:

$ django-admin.py startproject foo

by default creates the file urls.py in the folder foo, and this file has the line:

(r'admin/', include(admin.site.urls)),

to get easy to uncomment for access to admin, this line works fine in DEBUG=True, but when DEBUG=False admin says it dont find any module pages, if i just change that line for:

(r'admin/(.*)', admin.site.root),

works great in DEBUG=False and DEBUG=True, why dont you change the default generation of this line, or tell us what happen in this case.

Cheers

comment:2 Changed 5 years ago by kmtracey

  • Resolution set to invalid
  • Status changed from new to closed

I'm not sure what exactly you are trying to report. What does "easy to uncomment" have to do with which line is present? You also don't give specifics on what exactly you do to generate the error you see, nor specifics of the error. A full traceback is much more helpful when reporting problems then "admin says <some paraphrase of an error message>".

At any rate, the line in question is correct for 1.1 and forward, regardless of DEBUG setting. The line you propose replacing it with was used for 1.0 and is on its way to being deprecated, so we won't be changing back to that for what startproject generates. If you need help figuring out why the generated line doesn't work for you with DEBUG set to False, please try reporting specifics of what you are doing and what you see as a result on the django-users mailing list or IRC, as it's mostly likely some config problem on your end and not a bug in Django.

comment:3 Changed 5 years ago by tobydeh@…

  • Component changed from django-admin.py to Contrib apps
  • Keywords admin urls 404 added
  • Needs tests set
  • Resolution invalid deleted
  • Status changed from closed to reopened
  • Version changed from SVN to 1.1

Unfortunately camilonova didn't leave a very good description of the problem, I'm encountering this error and have found a few other people talking about it too.

This is the first time, out of many django 1.1 deployments, that I have ever encountered this behaviour.

The admin site works as expected for a while, and then randomly starts returning 404 whist browsing / editing content. I returned the exception data from handlers/base.py before it had a chance to render the 404 page and it turns out that django stops adding the urls for the installed apps... a few refreshes later and pages start re appearing.

This only seems to happen when DEBUG is set to False meaning you never get any feedback on what urls django is matching against. The exception data isn't passed through to the 404 template.

Something causes django to stop appending the installed models to the admin url patterns, I haven't managed to find a consistent method of replicating the problem, its just a case of clicking around until it starts throwing 404's.

I read that someone managed to fix the issue by using the following:

from django.db import models
models.get_apps()

in urls.py after calling admin.autodiscover(). I can't imagine how on earth it would help but im giving it a go because I haven't got anything else to go on!

comment:4 Changed 5 years ago by tobydeh@…

  • Needs tests unset
  • Resolution set to invalid
  • Status changed from reopened to closed

Sorry, this is not a django issue the registration of models with the admin site should not live in models.py

Taken from: http://groups.google.com/group/django-users/browse_thread/thread/1e3ac5beaa4ab370/1fe62a0d92a6797e?lnk=gst&q=admin+urls+not+working+correctly#1fe62a0d92a6797e

"You've put your admin.site.register call in models.py. This should go
in an admin.py file, not models.py. Whether your model is registered with
admin is being determined by the accident of whether your models.py file has
happened to be loaded at the time you attempt to access it in admin. Your
models.py file will have been loaded when running under the development
server, since it does explicit model validation during startup. Similarly
the admin validation done when DEBUG=True will have ensured that your
models.py file is loaded when you first attempt to access admin.

When running under Apache with DEBUG=False, however, there has not
necessarily been any need to load your models.py by the time you attempt to
access admin. That's why you are getting 404 errors...that call to
admin.site.register has not yet been made.

admin.autodiscover() and placing admin registrations in admin.py files (what
are loaded by admin.autodiscover()) ensures that model registrations happen
once and only once, at a predictable time, regardless of deployment scenario
and debug setting. If you move your admin registrations to an admin"

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