Re: Admin URLs not working correctly

[Michael Williamson]

> If you move your admin registrations to an admin.py file
> I believe your problem will go away.

Right you are! Well, that was somewhat foolish of me.

Thanks for your patience.

Mike
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Admin URLs not working correctly

[Michael Williamson]

> A small, recreatable example would help.

I've just recreated by doing the following, all with Django 1.1:

  1. Run django-admin startproject bug
  2. Set DATABASE_ENGINE to sqlite3 and DATABASE_NAME to /tmp/bug-
database
  3. Add 'django.contrib.admin' to INSTALLED_APPS
  4. Edit urls.py so that it looks like this:

from django.conf.urls.defaults import *

from django.contrib import admin
admin.autodiscover()

urlpatterns = patterns('',
(r'^admin/', include(admin.site.urls)),
)

  5. Run manage.py startapp blog
  6. Edit models.py so it looks like this:

from django.db import models
from django.contrib import admin

class Tag(models.Model):
name = models.CharField(max_length=50)

admin.site.register(Tag)

  7. Add 'bug.blog' to INSTALLED_APPS
  8. Run manage.py syncdb
  9. Add a VirtualHost to apache2:


DocumentRoot /var/www/django-admin-bug/public

Options Indexes FollowSymLinks
AllowOverride All
Order allow,deny
Allow from all



  10. Put the following .htaccess in /var/www/django-admin-bug/public:

SetHandler python-program
PythonHandler django.core.handlers.modpython
SetEnv DJANGO_SETTINGS_MODULE bug.settings
PythonOption django.root
PythonDebug On
PythonPath "['/var/www/django-admin-bug'] + sys.path"

  11. Set DEBUG=False
  12. Try to add a tag, and get a 404.

When running the application using manage.py runserver, the bug
disappears, so it seems mod_python is doing something differently.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Admin URLs not working correctly

[Michael Williamson]

> You've listed one that doesn't work -- /admin/blog/comment/add.  Is comment
> listed as a model at all under /admin/blog when things break?  Does
> /admin/blog/comment/ work to show a change list of comment models?  Can you
> bring up a detail page on an existing one?  Successfully change it?  I'm
> trying to figure out if something has happened to cause the comment model to
> disappear entirely from admin or if it's still partly there but broken.  If
> only partially broken, what parts, exactly, are broken?

Here's the error when DEBUG=True, and I've commented out the bit of
code that fixes the problem when DEBUG=True:

 Using the URLconf defined in mikesite.urls, Django tried these URL
patterns, in this order:

   1. ^$
   2. ^blog/
   3. ^admin/ ^$
   4. ^admin/ ^logout/$
   5. ^admin/ ^password_change/$
   6. ^admin/ ^password_change/done/$
   7. ^admin/ ^jsi18n/$
   8. ^admin/ ^r/(?P\d+)/(?P.+)/$
   9. ^admin/ ^(?P\w+)/$
  10. ^admin/ ^auth/user/
  11. ^admin/ ^auth/group/

So, I can't add one, view a list of existing ones, or change an
existing one. All I seem to be able to do with the blog app is visit /
admin/blog/.

> Again, I don't understand how that would help.  Someone did recently open a
> ticket (http://code.djangoproject.com/ticket/11918) saying that switching to
> the older url pattern for admin worked with DEBUG=False where the current
> one did not, but you haven't actually switched all the way back to the old
> pattern here.

Turns out I'm a fool. Changing the regex didn't really help -- it
stopped 404s coming up, but it also started showing the wrong pages,
so disregard this as a fix.

> Plenty of people are using the 1.1 pattern without trouble,
> so there's something in the configs where problems arise that is different.
> We've not gotten enough specifics on the failing configs for me to have any
> idea what it might be.  A small, recreatable example would help.

I'll try coming up with the smallest failing example tomorrow.

Thanks for the reply

Mike
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Overriding verbose_name in contrib or 3rd-party apps?

[Michael Williamson]

On Sep 25, 9:59 pm, ringemup  wrote:
> Is there an easy way to override strings like help_text or
> verbose_name or __unicode__ methods for models in contrib or third-
> party apps?  I can't seem to find anything on Google.
>
> Thanks!

A reasonably hacktastic way of doing this is monkey-patching. For
instance, say you want to override the __unicode__ method of the class
Blog. Firstly, write the new method e.g.

def new_unicode(self):
return self._name

Then, set the __unicode__ method of Blog to your new function:

Blog.__unicode__ = new_unicode

Is this a horrible piece of code? Absolutely. But it is quick, and it
works. A clean solution depends more on why you actually want to do
this.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Admin URLs not working correctly

[Michael Williamson]

Admin URLs do not seem to behaving themselves for me. My urls.py looks
like this:

from django.conf.urls.defaults import *

from django.contrib import admin
admin.autodiscover()

urlpatterns = patterns('',
(r'^$', 'django.views.generic.simple.redirect_to', {'url': '/
blog/'}),
(r'^blog/', include('mikesite.blog.urls')),
(r'^admin/', include(admin.site.urls)),
)

When DEBUG=True, the admin interface works fine. When DEBUG=False, I
get 404 errors when I attempt to access some URLs, such as /admin/blog/
comment/add/, yet others, such as /admin/blog/ or /admin/auth/user/
add/ work just fine.

After some digging around, I found that setting DEBUG=True fixes the
problem since this enables validation in django.contrib.admin.sites
(lines 69 to 72). When DEBUG is True,
django.contrib.admin.validation.validate is called, which in turn
calls django.db.models.get_apps().

Putting django.db.models.get_apps() at the top of urls.py fixes the
problem e.g.

from django.conf.urls.defaults import *

from django.contrib import admin
admin.autodiscover()

from django.db import models
models.get_apps()

urlpatterns = patterns('',
(r'^$', 'django.views.generic.simple.redirect_to', {'url': '/
blog/'}),
(r'^blog/', include('mikesite.blog.urls')),
(r'^admin/', include(admin.site.urls)),
)

I can also fix the problem by slightly changing the admin regex like
so:

from django.conf.urls.defaults import *

from django.contrib import admin
admin.autodiscover()

urlpatterns = patterns('',
(r'^$', 'django.views.generic.simple.redirect_to', {'url': '/
blog/'}),
(r'^blog/', include('mikesite.blog.urls')),
(r'^admin/.*', include(admin.site.urls)),
)

I'm using Django 1.1.

If anybody could shed some light on this, it would be greatly
appreciated.

Mike

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---