django-admin2: a rewrite of the Django admin that is meant to be extended

The pitch: start over to avoid the legacy code

django-admin2 is described as an extendable, adaptable rewrite of django.contrib.admin, and the README explains the reasoning without pretending it is a drop-in replacement. It starts from the observation that one of the most useful parts of django.contrib.admin is the ability to configure various views that touch and alter data, and then says the library is a complete rewrite of that using modern Class-Based Views, with a design focused on extendibility and adaptability. By starting over, the project argues it can avoid the legacy code and make it easier to write extensions and themes. The three headline features are a rewrite of the Django Admin backend, drop-in themes, and a built-in RESTful API. The project sits under the Jazzband umbrella and follows the Jazzband Code of Conduct, and it states that it follows the best practices in Two Scoops of Django. The audience is a developer with an existing Django project whose admin has outgrown what the stock admin can do, and who is prepared to own a forked admin interface for the life of the project. That last part is the commitment this article keeps coming back to.

Installation is three edits to settings and urls

The install is a pip install from PyPI:

pip install django-admin2

Then you add the app and the REST framework to your settings:

INSTALLED_APPS = (
    ...
    'djadmin2',
    'rest_framework', # for the browsable API templates
    ...
)

And you register the site in your URLconf, which is where the autodiscovery call lives:

# urls.py
from django.conf.urls import include

from djadmin2.site import djadmin2_site

djadmin2_site.autodiscover()

urlpatterns = [
  ...
  url(r'^admin2/', include(djadmin2_site.urls)),
]

Note that the URL prefix is admin2 rather than admin, which is the pattern you want if you intend to run the two side by side during a migration. The requirements are listed as Django 2.2 or later and Python 3.5 or later, and the runtime dependencies are django-braces, django-extra-views, django-rest-framework and django-filter, with Sphinx for the documentation. The requirements.txt in the tree adds django-debug-toolbar and pytz on top of those, and the project also ships tox.ini, a fabfile.py, a .coveragerc, a HISTORY.rst and an AUTHORS.rst.

ModelAdmin2 and the autodiscovery pattern

Registering a model follows the shape Django developers already know, with two differences that matter. The site object is djadmin2_site rather than the default admin site, and the admin class is ModelAdmin2 from djadmin2.types rather than django.contrib.admin.ModelAdmin. The README's example shows the whole pattern, including the form-class hooks that let you reuse Django's own user forms:

# myapp/admin2.py
from django.contrib.auth.forms import UserCreationForm, UserChangeForm
from django.contrib.auth.models import User
from djadmin2.site import djadmin2_site
from djadmin2.types import ModelAdmin2

from .models import Post, Comment


class UserAdmin2(ModelAdmin2):
    # Replicates the traditional admin for django.contrib.auth.models.User
    create_form_class = UserCreationForm
    update_form_class = UserChangeForm


#  Register each model with the admin
djadmin2_site.register(Post)
djadmin2_site.register(Comment)
djadmin2_site.register(User, UserAdmin2)

The convention is that each app gets an admin2.py module, and the autodiscover call in the URLconf finds them. The create_form_class and update_form_class attributes are the extension point that a project immediately needs, because the stock admin lets you set add_form and change_form and this one lets you set the create and update forms directly. The example project in the tree shows the intended shape of a real installation, with example/manage.py and separate blog, polls, files and static directories, and a fixtures directory for sample content.

Themes are packages, and the default is whichever bootstrap is current

The theming model is the part of this project that has aged least gracefully, because it is tied to a specific generation of Bootstrap, but the mechanism is sound. A theme is a Django app that you add to INSTALLED_APPS and name in a setting, and the README is explicit that the default theme is whatever bootstrap is most current, with the current default being djadmin2theme_bootstrap3. You switch themes with two lines:

# In settings.py
INSTALLED_APPS += ('djadmin2.themes.djadmin2theme_bootstrap3',)
ADMIN2_THEME_DIRECTORY = "djadmin2theme_bootstrap3"

Writing your own theme means the same two lines with your own package name, and the README gives the example of a mythical theme package called djadmin2theme_foundation. The idea is that the theme owns the templates and the static assets, so replacing the entire look of the admin is a configuration change rather than a fork. The migration notes show the model evolving, with themes becoming explicitly defined from 0.5.x, including the default theme, and the default switching to bootstrap3 when migrating from 0.6.x. The theme list also confirms the inheritance structure, since the default themes live under a themes subpackage of djadmin2 while a custom one lives at the top level of the project's own package namespace.

The API comes with a pagination constraint

The built-in RESTful API is the feature that distinguishes this rewrite from a themed admin, and it comes with a documented constraint that is easy to miss. The README notes that Django REST Framework also includes multiple pagination systems, and that the only one supported now is the PageNumberPagination, so the settings have to say so explicitly:

REST_FRAMEWORK = {
    'DEFAULT_PAGINATION_CLASS': 'rest_framework.pagination.PageNumberPagination',
    'PAGE_SIZE': 10
}

The 'rest_framework' entry in INSTALLED_APPS is there for the browsable API templates, which is a useful detail if you want the HTML explorer rather than only JSON. The architecture behind the API is the reason for the dependency list, since django-extra-views, django-braces, django-filter and django-rest-framework are the declared dependencies. The practical benefit for a team is that the same models, the same permissions and the same filters end up reachable both through a browser interface and through a JSON endpoint, which is what a modern internal tool or a mobile client usually needs.

The release history is the part to check first

Here is the fact that should frame any evaluation. The repository's recent releases are 0.7.1, tagged on 2017-01-10, and 0.7.0 from 2016-11-15. The last push to the repository was on 2026-10-13, so the code is being touched, and the branch in use is main, with a GitHub Actions test badge in the README and a codecov badge for coverage. But the last published version of the package is from January 2017, which means the version on PyPI and the code in the repository are separated by nearly a decade of history, and the version you get from pip will not include that newer work. The stated requirements, Django 2.2 or later and Python 3.5 or later, are from the same era. The setup.py in the tree is a hand-written setuptools file that parses the version and the author out of the package's __init__.py with a regular expression, and it contains a helper that strips the screenshots section out of the long description because PyPI does not like them. None of this is a criticism of the code, which was a serious and well-executed rewrite for its time. It is a statement about what you are adopting: a project whose published artifact froze in 2017, whose modern branch is maintained without a release, and whose dependency floor predates most of the Django versions in use today.

Where django-admin2 is the wrong tool

The first and clearest case is a new project that simply wants a better looking admin. Django's own admin ships with the framework, third party packages add functionality, and it is versioned with Django, which means it keeps working. Rewriting it is a decision to own a fork, and owning a fork of an admin for a product that will live for years is a cost that only makes sense when the stock admin genuinely blocks you. The second case is a project already on a modern Django where the dependency set of this package is a problem, since the requirements start at Django 2.2 and the released version is from 2017. The third is a team that wants an API over their models, because django-admin2's API is a side effect of the admin rewrite rather than a first-class API framework, and a project that needs an API will usually want Django REST Framework with serializers that the API author wrote, not an API generated from admin configuration. The honest alternative in most cases is to stay on django.contrib.admin and add the specific thing that is missing, whether that is a theme, an extra view or a small set of API endpoints written by hand, because each of those is a smaller and more reversible commitment than replacing the whole interface.

Editorial conclusion

Adopt django-admin2 if you have to replace the Django admin wholesale and you want class-based views, a theme you can replace as a package, and an API over the same models. Do not adopt it for a new project that just needs a nicer admin, because the stated requirement set starts at Django 2.2 and Python 3.5, and the last release was tagged in 2017. Before you commit, check which release you would actually install, read HISTORY.rst, and confirm that the current dependencies of your project can satisfy a package whose last published version predates the modern Django admin.

Frequently asked questions

Official sources

1. Issues
2. jazzband/django-admin2 on GitHub
3. License: BSD-3-Clause
4. README
5. Releases