No admin-url match when DEBUG=False

[Stephan John]

Hi all,

I have some trouble with my Admin-URLs. When I set DEBUG=False (in the
settings.py) I become this error (I've changed some lines in the file
../django/core/handlers/base.py to see the error in no-debug-mode):

Using the URLconf defined in project.urls, Django tried these URL patterns, in
this order:
1.^admin/ ^$
2.^admin/ ^logout/$
3.^admin/ ^password_change/$
4.^admin/ ^password_change/done/$
5.^admin/ ^jsi18n/$
6.^admin/ ^r/(?P<content_type_id>\d+)/(?P<object_id>.+)/$
7.^admin/ ^(?P<app_label>\w+)/$
8.^admin/ ^auth/group/
9.^admin/ ^auth/user/
10.^admin/ ^sites/site/
The current URL, admin/hauptseite/beitrag/, didn't match any of these.

But when I set DEBUG=True, everything is OK and I have no errors.
(I use Django version 1.1 beta)

Thanks for your help
Stephan

[Mawilo]

[Karen Tracey]

What you seem to be missing are the patterns that are added for each registered model.  Are your calls to admin.site.register (or your call to admin.autodiscover()) dependent on the DEBUG setting? 

Karen

[Karen Tracey]

Please see my reply in the other thread with this same question.

Karen

[Stephan John]

I registered the models with:
admin.site.register(Beitrag, BeitragAdmin)
admin.site.register(Container, ContainerAdmin)

It works fine in debug-mode. I have problems only if debug is false.

[Karen Tracey]

On Fri, Mar 27, 2009 at 9:19 AM, Stephan John <em...@stephanjohn.de> wrote:

I registered the models with:
admin.site.register(Beitrag, BeitragAdmin)
admin.site.register(Container, ContainerAdmin)

It works fine in debug-mode. I have problems only if debug is false.

And those lines are actually executed when DEBUG is False?  What I'm saying is that the urlpatterns displayed when it is not working look like no calls to register have been made.  I don't see anything in the admin code itself that is dependent on the DEBUG setting that would explain that, nor can I recreate the problem if I set DEBUG to False in my own app, so my first guess is that your code somehow doesn't actually execute those register lines when DEBUG is False.

Karen

[Stephan John]

Yes, both lines are in the file models.py as the last lines.

I've added the following lines in the file ../django/contrib/admin/sites.py
after line 87:
f = open('/tmp/error.tmp', 'w+')
f.write(str(admin_class))
f.write(str(model))
f.close()

The Output in the tmp-file is:
<class 'project.mainpage.models.ContainerAdmin'><class
'project.mainpage.models.Container'>

For me it looks ok – the model is registered.

[Karen Tracey]

On Fri, Mar 27, 2009 at 9:44 AM, Stephan John <em...@stephanjohn.de> wrote:

Am Freitag, 27. März 2009 14:28:28 schrieb Karen Tracey:

> On Fri, Mar 27, 2009 at 9:19 AM, Stephan John <em...@stephanjohn.de> wrote:
> > I registered the models with:
> > admin.site.register(Beitrag, BeitragAdmin)
> > admin.site.register(Container, ContainerAdmin)
> >
> > It works fine in debug-mode. I have problems only if debug is false.
>
> And those lines are actually executed when DEBUG is False?  What I'm saying
> is that the urlpatterns displayed when it is not working look like no calls
> to register have been made.  I don't see anything in the admin code itself
> that is dependent on the DEBUG setting that would explain that, nor can I
> recreate the problem if I set DEBUG to False in my own app, so my first
> guess is that your code somehow doesn't actually execute those register
> lines when DEBUG is False.
>
> Karen
>
>

Yes, both lines are in the file models.py as the last lines.

Your calls to admin.site.register should not be in your models.py file.  They should be in a file named admin.py and a call to admin.autodiscover() ought to be included in your urls.py, as described here:

http://docs.djangoproject.com/en/dev/ref/contrib/admin/

If you put the calls in models.py first it is intdeterminate when that file will be loaded, so unpredictable when the registrations will happen.  I'd guess when you run with DEBUG set to True your models.py hapens to be loaded early on, but not when you run with DEBUG=False.  Another problem with register calls in models.py is that if/when models.py file is imported multiple times, you will get AlreadyRegistered exceptions on the register calls, since the models were registered the first time models.py was loaded.

Placing the registrations in admin.py and calling admin.autodiscover() from urls.py ensures that the admin registrations happen only once, at a predictable time.

I've added the following lines in the file ../django/contrib/admin/sites.py
after line 87:
f = open('/tmp/error.tmp', 'w+')
f.write(str(admin_class))
f.write(str(model))
f.close()

The Output in the tmp-file is:
<class 'project.mainpage.models.ContainerAdmin'><class
'project.mainpage.models.Container'>

For me it looks ok – the model is registered.

I can't explain that, but as a first step I'd change your setup to match standard practice.  Having admin registrations in models.py is just asking for trouble.

Karen

[Stephan John]

Am Freitag, 27. März 2009 21:05:09 schrieb Karen Tracey:
> On Fri, Mar 27, 2009 at 9:44 AM, Stephan John <em...@stephanjohn.de> wrote:
>
> Your calls to admin.site.register should not be in your models.py file.
> They should be in a file named admin.py and a call to admin.autodiscover()
> ought to be included in your urls.py, as described here:
>
> http://docs.djangoproject.com/en/dev/ref/contrib/admin/
>
> If you put the calls in models.py first it is intdeterminate when that file
> will be loaded, so unpredictable when the registrations will happen. I'd
> guess when you run with DEBUG set to True your models.py hapens to be
> loaded early on, but not when you run with DEBUG=False. Another problem
> with register calls in models.py is that if/when models.py file is imported
> multiple times, you will get AlreadyRegistered exceptions on the register
> calls, since the models were registered the first time models.py was
> loaded.
>
> Placing the registrations in admin.py and calling admin.autodiscover() from
> urls.py ensures that the admin registrations happen only once, at a
> predictable time.
>

>

> I can't explain that, but as a first step I'd change your setup to match
> standard practice. Having admin registrations in models.py is just asking
> for trouble.
>
> Karen

YES! :-) That's it. With the registration in the file admin.py it works ok.
Thanks a lot!

Stephan