I Needed Collapsible App Groups in Django Admin, So I Built a Package

Fyodor — Fri, 10 Jul 2026 12:59:01 +0000

The built-in Django Admin works well, especially while a project is still small. But as a project grows, the sidebar gradually fills up with more applications and models: users, permissions, products, orders, reports, integrations, internal reference data, and many other sections.

Most of these sections are not used all the time. In one project, an administrator may spend most of the day working with orders and customers, while dozens of rarely used models remain visible in the sidebar.

At some point, I wanted to add a very simple feature to the standard Django Admin sidebar: click an arrow next to an application name and collapse its list of models.

It seemed like a small interface improvement. However, I could not find a lightweight package that added exactly this behavior to the standard Django Admin without replacing it with a custom theme.

So I built django-admin-collapse-apps.

What the package does

The package adds a toggle next to every application group heading. When the toggle is clicked, the model list is hidden and only the application name remains visible.

The selected state is stored in a cookie. After refreshing the page or returning to the admin later, previously collapsed groups remain collapsed. When the user expands all application groups again, the cookie is removed.

The package does not replace Django’s standard navigation, change the order of applications or models, or interfere with permission checks. It only adds collapsible behavior to the application groups already generated by Django.

This is what the sidebar looks like before collapsing groups:

And this is what it looks like after:

Installation

The package is available on PyPI and can be installed with:

python -m pip install django-admin-collapse-apps

After installation, add it to INSTALLED_APPS before django.contrib.admin:

INSTALLED_APPS = [
    "django_admin_collapse_apps",
    "django.contrib.admin",
    # Other project applications
]

That is all that is required for the basic setup. After restarting the project, collapse toggles will appear next to all application groups in the standard Django Admin sidebar.

The position before django.contrib.admin is important because the package adds its own templates and static files on top of the standard admin templates.

Restricting collapse toggles to selected applications

By default, toggles are added to every application group. For most projects, this is the simplest behavior because each user can decide which sections should remain visible.

In some cases, however, part of the menu should always stay expanded. For example, you may want to allow collapsing only for rarely used internal applications.

To do this, add a list of Django app labels to the project settings:

ADMIN_COLLAPSE_APPS = [
    "auth",
    "reports",
    "integrations",
]

After that, toggles will only appear for the listed applications. All other groups will continue to behave like regular Django Admin navigation items.

These values are Django app labels, not application display names. In most projects, the label matches the application name, but in more complex configurations it is better to check the application’s AppConfig.

Why cookies instead of localStorage

At first, localStorage seemed like the obvious choice for storing the collapsed state. This is a purely client-side feature, so using browser storage would have been reasonable.

However, cookies have one practical advantage here: they can be scoped to a particular admin path and separated between multiple administrative interfaces hosted on the same domain.

The cookie stores only the app labels of collapsed applications. It does not contain user data, model content, or any other information from the admin interface.

A simplified value looks like this:

catalog,orders,reports

When the user expands the final collapsed group, the cookie is no longer needed and is deleted.

If several independent admin interfaces are hosted on the same domain, each one can use its own namespace:

ADMIN_COLLAPSE_APPS_COOKIE_NAMESPACE = "backoffice"

This prevents the menu state from one admin interface from being accidentally applied to another.

Working with Django Admin search

The standard Django Admin sidebar includes a search field for filtering applications and models.

This created a less obvious edge case: what should happen when a matching model belongs to a collapsed application group?

Without additional handling, Django would find the model, but the user would not see it because its group would still be collapsed. To avoid this, matching application groups are temporarily expanded while the search field contains text.

When the search field is cleared, the interface returns to the state selected by the user before the search started. Searching does not overwrite the saved collapse state or permanently expand any applications.

It is a small detail, but without it the collapse feature would conflict with one of the useful built-in Django Admin tools.

Why I did not completely replace the navigation template

The most direct way to implement this feature would be to copy the standard Django Admin navigation template and modify it.

That approach works, but it leaves the project with its own copy of a relatively large Django template. After every Django update, the copied template has to be compared with the new standard version.

Django may add markup changes, accessibility improvements, or new features that do not automatically appear in the copied template.

For this reason, the package tries to interfere with the standard admin as little as possible. Django still generates the applications, models, links, ordering, and permissions. The package’s JavaScript only finds the existing groups in the DOM and adds collapse buttons.

This approach still depends on the structure of the standard Django Admin, but the amount of overridden behavior is much smaller than it would be with a complete template replacement.

If the expected markup is not present on a page, the script simply stops. The admin remains available and continues working without the collapse feature.

The admin should still work without JavaScript

The feature is implemented as progressive enhancement. JavaScript improves the interface, but it is not required to access administrative sections.

If the script fails to load, is blocked, or JavaScript is disabled in the browser, every application group remains expanded. Links to models continue working, and the user does not lose access to any admin functionality.

In the worst case, Django Admin simply returns to its normal default behavior.

Accessibility

The toggles are implemented as real elements rather than clickable div or span elements. This makes them keyboard accessible and allows them to receive focus correctly.

When the state changes, the package updates the aria-expanded attribute. Each button is also connected to its model list through aria-controls.

The styles take the prefers-reduced-motion setting and forced-colors mode into account. This does not replace a full accessibility audit of Django Admin, but it helps ensure that the package does not make the standard interface less accessible.

Customizing the arrows and appearance

By default, the package uses simple Unicode symbols: a downward arrow for an expanded group and a right-pointing arrow for a collapsed group.

This avoids adding an icon library, SVG sprite, or any external dependency. The symbols can still be replaced through CSS variables:

:root { --django-admin-collapse-apps-toggle-expanded-symbol: "▼"; --django-admin-collapse-apps-toggle-collapsed-symbol: "▶"; }

CSS can also be used to change the button color, symbol size, spacing, and focus styling.

The package uses colors from the standard Django Admin interface and works with both its light and dark modes.

What the package deliberately does not do

django-admin-collapse-apps is intentionally a small enhancement. It does not replace Django Admin with a custom theme, rebuild the menu, reorder models, add a separate user settings system, or store preferences in the database.

It does not use jQuery, third-party JavaScript libraries, a CDN, or external resources. The entire feature is implemented with a small amount of JavaScript and CSS.

This also defines the main limitation of the package: it is designed primarily for the standard Django Admin interface. Themes that completely replace the sidebar may use different markup and usually provide their own navigation features.

Why publish a package for one small feature?

Collapsible application groups can be implemented directly inside a single project. Installing another dependency is not strictly necessary.

However, when the same improvement is needed in several projects, it becomes necessary to copy templates, JavaScript, styles, cookie settings, and fixes for various edge cases.

At that point, maintaining one small package is easier than maintaining several slightly different local implementations.

Publishing the feature as a separate project also encourages more careful work on compatibility, documentation, tests, and behavior across different Django versions.

The result is a small package without any attempt to become a new admin platform. It does one thing: it allows users to hide application groups they do not currently need.

The source code is available on GitHub:

https://github.com/kroxiksut/django-admin-collapse-apps

The package is available on PyPI:

https://pypi.org/project/django-admin-collapse-apps/

Feedback is welcome, especially from developers using the package in large projects with heavily extended Django Admin interfaces. If you find a bug or an unusual edge case, feel free to open an issue on GitHub.

DEV Community: Fyodor

I Needed Collapsible App Groups in Django Admin, So I Built a Package