[Django]-How to have 2 different admin sites in a Django project?

You can subclass Django’s AdminSite (put it eg. in admin.py in your project root):

from django.contrib.admin.sites import AdminSite

class MyAdminSite(AdminSite):
    pass
    #or overwrite some methods for different functionality

myadmin = MyAdminSite(name="myadmin")   

At least from 1.9 on you need to add the name parameter to make it work properly. This is used to create the revers urls so the name has to be the one from the urls.py.

Then you can use it in your app’s admin.py the same way as you do with the normal AdminSite instance:

from myproject.admin import myadmin
myadmin.register(MyModel_A)

You also need to define some urls for it (in your project’s urls.py):

from django.urls import path
from myproject.admin import admin, myadmin

urlpatterns = [
    path('admin/', admin.site.urls),
    path('myadmin/', myadmin.urls),
]

Also see this: http://docs.djangoproject.com/en/dev/ref/contrib/admin/#adminsite-objects

I’m not sure that my finding, reported here, would have been entirely helpful to kender because, among other things, I don’t know if he was talking not only about two admin sites but also two databases, one for each. That’s my situation. I got the bright idea that I wanted one of my apps, a new app, to have its own database and own admin pages.

But I ran into a problem with the AdminSite subclassing approach of Bernhard Vallant, though it seems to be the orthodox and essentially correct thing to do. I resolved the problem.

Here’s the mod to Bernhard Vallant’s code that I found to be utterly necessary:

from django.contrib.admin.sites import AdminSite
class MyAdminSite(AdminSite):
    pass
    #or overwrite some methods for different functionality
myadmin = MyAdminSite(name='anything')

Yes, I do really mean name=’anything’ that you choose (as long as it isn’t ‘admin’). And I’ve toggled in and out with it and it fails every time without the anything-but-admin name assignment.

The symptoms that I acquired were that when I added the second database and created a myadmin for it and then registered the model with myadmin.register(My_ModelA), and went to look at the two admin app pages, the one for my new app that used the second database and myadmin and the model My_ModelA looked fine, but my old admin page showed dead links for its models and when I clicked there on a non-dead link for an app (an old app that uses the old database) I got a 404 code to the effect that the page didn’t exist.

Also, I don’t know that it matters, but I did something different from what
Bernhard Vallant did in the project urlconf:

from django.conf.urls import patterns, include, url
from django.contrib import admin
admin.autodiscover()

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

OK, “someword” is irrelevant— there for appearances with regard to the end user and not the name of an app or the project. But the associated admin is the one for my old app and old database. Note the autodiscover() inclusion. There’s some murky language in the docs to which Bernhard Vallant linked regarding its use when the project urlconf is configured as Bernhard Vallant has it with the myadmin import but also with a reference to the default admin.

And for the urlconf for mynewapp I have:

from django.conf.urls import patterns, url, include
from myproject.admin import myadmin

urlpatterns = patterns('',
    url(r'/', include(myadmin.urls) )
)

urlpatterns += patterns('mynewapp.views',"... url() stuff for mynewapp's views"),
)

Notwithstanding the utter necessity of naming your AdminSite instance internally to something other than ‘admin’, I must add that when it came time to jazz up the mynewapp’s admin.py file with some admin.ModelAdmin subclassing, it was necessary to indeed use admin.ModelAdmin as the parent class. myadmin is after all an instance of a subclass of AdminSite. As such I gather that it’s on a par with admin.site, not with admin.

This is all very confusing to a NOOB like me because admin, with the lower case, looks like an instance, and I am unfamiliar with subclassing instances. So I assume that it isn’t.