Warning
The design of the admin has changed somewhat since this document was written, and parts may not apply any more. This document is no longer maintained since an official API for customizing the Django admin interface is in development.
Django’s dynamic admin interface gives you a fully-functional admin for free with no hand-coding required. The dynamic admin is designed to be production-ready, not just a starting point, so you can use it as-is on a real site. While the underlying format of the admin pages is built in to Django, you can customize the look and feel by editing the admin stylesheet and images.
Here’s a quick and dirty overview some of the main styles and classes used in the Django admin CSS.
The .module class is a basic building block for grouping content in the admin. It’s generally applied to a div or a fieldset. It wraps the content group in a box and applies certain styles to the elements within. An h2 within a div.module will align to the top of the div as a header for the whole group.
Note
All admin pages (except the dashboard) are fluid-width. All fixed-width classes from previous Django versions have been removed.
The base template for each admin page has a block that defines the column structure for the page. This sets a class on the page content area (div#content) so everything on the page knows how wide it should be. There are three column types available.
For instance, you could stick this in a template to make a two-column page with the sidebar on the right:
{% block coltype %}colMS{% endblock %}
Most HTML elements (headers, lists, etc.) have base font sizes in the stylesheet based on context. There are three classes are available for forcing text to a certain size in any context.
There are also a few styles for styling text.
Certain actions which apply directly to an object are used in form and changelist pages. These appear in a "toolbar" row above the form or changelist, to the right of the page. The tools are wrapped in a ul with the class object-tools. There are two custom tool types which can be defined with an additional class on the a for that tool. These are .addlink and .viewsitelink.
Example from a changelist page:
<ul class="object-tools">
<li><a href="/stories/add/" class="addlink">Add redirect</a></li>
</ul>
and from a form page:
<ul class="object-tools">
<li><a href="/history/303/152383/">History</a></li>
<li><a href="/r/303/152383/" class="viewsitelink">View on site</a></li>
</ul>
Admin forms are broken up into groups by fieldset elements. Each form fieldset should have a class .module. Each fieldset should have a header h2 within the fieldset at the top (except the first group in the form, and in some cases where the group of fields doesn't have a logical label).
Each fieldset can also take extra classes in addition to .module to apply appropriate formatting to the group of fields.
Each row of the form (within the fieldset) should be enclosed in a div with class form-row. If the field in the row is required, a class of required should also be added to the div.form-row.
Form labels should always precede the field, except in the case of checkboxes and radio buttons, where the input should come first. Any explanation or help text should follow the label in a p with class .help.
Sep 20, 2009