mirror of
https://github.com/django/django.git
synced 2024-11-29 22:56:46 +01:00
Fixed #7943: added documentation on overriding admin templates. Thanks, mwdiers
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8858 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
parent
23f012dbfa
commit
b1f5ed00cb
@ -851,6 +851,104 @@ and ``GenericStackedInline`` and behave just like any other inline. See the
|
||||
:ref:`contenttypes documentation <ref-contrib-contenttypes>` for more specific
|
||||
information.
|
||||
|
||||
Overriding Admin Templates
|
||||
==========================
|
||||
|
||||
It is relatively easy to override many of the templates which the admin module
|
||||
uses to generate the various pages of an admin site. You can even override a few
|
||||
of these templates for a specific app, or a specific model.
|
||||
|
||||
Set up your projects admin template directories
|
||||
-----------------------------------------------
|
||||
|
||||
The admin template files are located in the ``contrib/admin/templates/admin``
|
||||
directory.
|
||||
|
||||
In order to override one or more of them, first create an ``admin`` directory in
|
||||
your project's ``templates`` directory. This can be any of the directories you
|
||||
specified in ``TEMPLATE_DIRS``.
|
||||
|
||||
Within this ``admin`` directory, create sub-directories named after your app.
|
||||
Within these app subdirectories create sub-directories named after your models.
|
||||
Note, that the admin app will lowercase the model name when looking for the
|
||||
directory, so make sure you name the directory in all lowercase if you are going
|
||||
to run your app on a case-sensitive filesystem.
|
||||
|
||||
To override an admin template for a specific app, copy and edit the template
|
||||
from the ``django/contrib/admin/templates/admin`` directory, and save it to one
|
||||
of the directories you just created.
|
||||
|
||||
For example, if we wanted to add a tool to the change list view for all the
|
||||
models in an app named ``my_app``, we would copy
|
||||
``contrib/admin/templates/admin/change_list.html`` to the
|
||||
``templates/admin/my_app/`` directory of our project, and make any necessary
|
||||
changes.
|
||||
|
||||
If we wanted to add a tool to the change list view for only a specific model
|
||||
named 'Page', we would copy that same file to the
|
||||
``templates/admin/my_app/page`` directory of our project.
|
||||
|
||||
Overriding vs. replacing an admin template
|
||||
------------------------------------------
|
||||
|
||||
Because of the modular design of the admin templates, it is usually neither
|
||||
necessary nor advisable to replace an entire template. It is almost always
|
||||
better to override only the section of the template which you need to change.
|
||||
|
||||
To continue the example above, we want to add a new link next to the ``History``
|
||||
tool for the ``Page`` model. After looking at ``change_form.html`` we determine
|
||||
that we only need to override the ``object-tools`` block. Therefore here is our
|
||||
new ``change_form.html`` ::
|
||||
|
||||
{% extends "admin/change_form.html" %}
|
||||
{% load i18n %}
|
||||
{% block object-tools %}
|
||||
{% if change %}{% if not is_popup %}
|
||||
<ul class="object-tools">
|
||||
<li><a href="history/" class="historylink">{% trans "History" %}</a></li>
|
||||
<li><a href="mylink/" class="historylink">My Link</a></li>
|
||||
{% if has_absolute_url %}
|
||||
<li><a href="../../../r/{{ content_type_id }}/{{ object_id }}/" class="viewsitelink">
|
||||
{% trans "View on site" %}</a>
|
||||
</li>
|
||||
{% endif%}
|
||||
</ul>
|
||||
{% endif %}{% endif %}
|
||||
{% endblock %}
|
||||
|
||||
And that's it! If we placed this file in the ``templates/admin/my_app``
|
||||
directory, our link would appear on every model's change form.
|
||||
|
||||
Templates which may be overridden per app or model
|
||||
--------------------------------------------------
|
||||
|
||||
Not every template in ``contrib\admin\templates\admin`` may be overridden per
|
||||
app or per model. The following can:
|
||||
|
||||
* ``change_form.html``
|
||||
* ``change_list.html``
|
||||
* ``delete_confirmation.html``
|
||||
* ``object_history.html``
|
||||
|
||||
For those templates that cannot be overridden in this way, you may still
|
||||
override them for your entire project. Just place the new version in your
|
||||
``templates/admin`` directory. This is particularly useful to create custom 404
|
||||
and 500 pages.
|
||||
|
||||
.. note::
|
||||
|
||||
Some of the admin templates, such as ``change_list_request.html`` are used
|
||||
to render custom inclusion tags. These may be overridden, but in such cases
|
||||
you are probably better off creating your own version of the tag in question
|
||||
and giving it a different name. That way you can use it selectively.
|
||||
|
||||
Root and login templates
|
||||
------------------------
|
||||
|
||||
If you wish to change the index or login templates, you are better off creating
|
||||
your own ``AdminSite`` instance (see below), and changing the ``index_template``
|
||||
or ``login_template`` properties.
|
||||
|
||||
``AdminSite`` objects
|
||||
=====================
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user