django-admin-interface: themed admin panels and modal windows without template overrides

A theme record in the database, not a config file or CSS override

Django's built-in admin presents the same visual style for every project. django-admin-interface changes that by registering a Theme model and storing the active configuration in the database. Header background, text colors, link colors, logo and site title are all fields in that record, and editing it through the admin itself updates the appearance on the next page load. No template files need to be overridden and no separate CSS override files need to be maintained in the project.

The project description calls it an admin interface customizable by the admin itself. That design intent is useful when designers and developers share a project, since a visual change no longer requires a code review or a deployment cycle. Color customization happens through a picker inside the Django admin, backed by django-colorfield, which is listed as the package's one declared dependency.

django-admin-interface is MIT-licenced, targets Django 4.2, 5.0, 5.1, 5.2 and 6.0 alongside Python 3.10 through 3.14, and was last pushed on 2026-10-01.

When only the active theme needs to change between environments, exporting the Theme record as a fixture with dumpdata and loading it with loaddata in the target environment carries the exact configuration across. No separate configuration files need to be copied for theme choices, and no environment variables control the visual state.

Install order, X_FRAME_OPTIONS and W019 are three requirements that interact

Install from PyPI:

pip install django-admin-interface

Add both app names to INSTALLED_APPS before django.contrib.admin, along with two extra settings:

INSTALLED_APPS = (
    #...
    "admin_interface",
    "colorfield",
    #...
    "django.contrib.admin",
    #...
)

X_FRAME_OPTIONS = "SAMEORIGIN"
SILENCED_SYSTEM_CHECKS = ["security.W019"]

Both extra settings exist for modal support. Django's default X-Frame-Options header is DENY, which prevents same-origin iframes. Setting it to SAMEORIGIN permits those frames, and Django then issues system check W019 to flag that relaxation. Adding W019 to SILENCED_SYSTEM_CHECKS suppresses the check. The README marks this with a WARNING: modal windows only work when X_FRAME_OPTIONS is set to SAMEORIGIN.

Projects that already send a Content-Security-Policy header with a frame-ancestors directive narrower than same-origin will find that the browser enforces the CSP instead of the Django setting, and modal frames are still blocked. The README does not address that case.

Three commands finish the setup:

python manage.py migrate
python manage.py collectstatic --clear

Then restart the application server. Migrate creates the Theme table; collectstatic --clear copies the interface's CSS and JavaScript to the static root. A server restart completes the process.

Four bundled fixture themes and the pull request process to add more

The package ships four themes as Django fixture files. Loading each one uses the same loaddata pattern pointing to a different filename:

python manage.py loaddata admin_interface_theme_django.json
python manage.py loaddata admin_interface_theme_bootstrap.json
python manage.py loaddata admin_interface_theme_foundation.json
python manage.py loaddata admin_interface_theme_uswds.json

The four designs follow Django's default look, Bootstrap, Foundation and the U.S. Web Design Standards. Each fixture has its active field set to true, so loading one immediately makes it the live theme. Only one theme is active at a time; switching between installed themes happens through the admin without any command-line step.

Contributing a new theme to the repository requires four steps according to the README. Export the customized theme record:

python manage.py dumpdata admin_interface.Theme --indent 4 -o admin_interface_theme_{{name}}.json --pks=N

Copy the exported file to the fixtures folder, remove the pk field from the JSON, confirm that active is set to true, and open a pull request with the README updated to document the theme. Fixture filenames must start with admin_interface_theme_ to prevent clashes with fixture files from other installed apps. That naming rule comes from the contributing guide in the README.

CSS variables map the active theme to any stylesheet in the admin

Switching themes only updates the package's own HTML elements. Third-party packages that inject their own HTML into admin pages keep their original styles unless they read from a shared source. django-admin-interface publishes a set of CSS custom properties for exactly that purpose.

The header group covers six properties: --admin-interface-header-background-color, --admin-interface-header-text-color, --admin-interface-header-link-color, --admin-interface-header-link_hover-color, --admin-interface-title-color and --admin-interface-env-color. The logo group adds four more for logo color, default background image, maximum width and maximum height. The modules and links group has nine properties for backgrounds, border radius, text color and link states across normal, selected and hover states.

A stylesheet that references any of these properties picks up the current theme value at render time. When the active theme changes, all references in all stylesheets update in one step. A library author integrating a third-party plugin with this theme system replaces hard-coded color values with the matching property names.

Three CSS variable groups are documented: the header group with six properties, the logo group with four, and the modules and links group with nine. A buttons group and further groups exist in the package's CSS source; those are not fully listed in the project's README.

Tabbed fieldsets, collapsible inlines and four filter controls

Five features carry a NEW label in the feature list: collapsible inlines, tabbed fieldsets, tabbed inlines, list filter removal links and list filter highlight for selected options.

Tabbed fieldsets replace the default vertical stacking of ModelAdmin.fieldsets with a tab bar. Tabbed inlines apply the same presentation to inline sets. Neither changes the underlying model structure or form validation.

Collapsible fieldsets in Django default to a collapsed state. This package adds an option to start a fieldset expanded with a Hide button visible, by including the string "expanded" in the fieldset's classes tuple:

class MyModelAdmin(admin.ModelAdmin):
    fieldsets = [
        ("Section title", {
            "classes": ("collapse", "expanded"),
            "fields": (...),
        }),
    ]

Adding "expanded" to the classes tuple reverses the default collapsed state. That is the only change the fieldset definition requires; the package handles the initial render.

List filter removal links place an x beside each active filter so users can remove individual filters without clearing all of them. List filter highlight colors the selected option in a filter sidebar. Both are among the features marked as new.

The package also ships older controls: list filter dropdown converts filter sidebars to menus, and list filter sticky keeps filters visible while scrolling. Form controls sticky fixes the actions row, pagination and save buttons so they remain in view during a long form. The navigation bar supports foldable app groups as accordions.

Eight compatibility patches and the gap for unlisted packages

Eight packages receive compatibility or style patches: django-ckeditor, django-dynamic-raw-id, django-json-widget, django-modeltranslation, django-rangefilter, django-streamfield, django-tabbed-admin and sorl-thumbnail. These are described as optimizations without detail on what each one changes.

Projects relying on any of those eight can expect at least the documented visual conflicts to be handled. An unlisted package gets nothing automatic. Opening the admin with the unlisted package active and switching themes is the only way to find conflicts, because no claim is made for packages outside the eight.

The admin interface is translated into 10 languages: Arabic, German, Spanish, Persian, French, Italian, Polish, Brazilian Portuguese, Russian and Turkish. Translation covers the strings the package adds to the interface, not the content of Theme records themselves.

The environment name feature displays a visible label in the admin header, which is set through the theme record rather than a Django setting. Its purpose is distinguishing a staging panel from a production one when both run the same package. The language chooser feature adds a language selector to the admin header, letting admin users switch between the 10 supported languages without changing any server configuration.

requirements.txt and pyproject.toml specify django-colorfield at different constraints

Reading both dependency files in the repository reveals a discrepancy that matters before deploying. The requirements.txt file pins `django-colorfield == 0.14.0` while pyproject.toml declares `django-colorfield >= 0.8.0, < 1.0.0`, so a fresh pip install of the package resolves to any compatible colorfield release in that range rather than the exact version used during development.

That split is a common Python packaging pattern: pyproject.toml names the compatible range, and requirements.txt names the exact dependency used in testing. A production install could get a colorfield package that the test run never exercised.

Pinning django-colorfield in your own project's lock file closes that gap. The project does not name a preferred colorfield build in its README, so that choice falls to the consuming project. If the theme editor's color picker behaves unexpectedly after a fresh deploy, confirming that both files agree on which colorfield is installed is where to start.

The pyproject.toml declares setuptools as the build backend with no compiled extension required. Installing the package needs only pip and the three migration and static-file steps.

Editorial conclusion

django-admin-interface suits teams who want a branded admin panel without managing template overrides or a separate CSS file. The fixture workflow lets staging and production carry identical themes through a single loaddata command. Teams with a Content Security Policy that restricts framing should check whether SAMEORIGIN conflicts with existing frame-ancestors directives, since the install guide silences Django's W019 check on that point. Before deploying, test the admin with each third-party plugin active and switch themes, because the eight listed packages get visual patches and unlisted ones do not.

Frequently asked questions

Official sources

1. fabiocaccamo/django-admin-interface on GitHub
2. Issues
3. License: MIT
4. README
5. Releases