Make possible to extend some of admin's templates

[Marinho Brandão]

The current admin/index.html template should be renamed to admin/base_index.html and a new admin/index.html created with only a {% extends "admin/base_index.html" %}, to make possible extends the Admin index page with no needs to generate a new and non-dynamic file using manage.py admin_index command.

This is a little change that can helps developers to avoid rewrite a customized AdminSite.index method or generate a static template.

[Julien Phalip]

+1 for this. The index.html template is currently not extensible (provokes recursive importing). Moving all the code to an extra file base_index.html seems like a good approach to me.

[Jacob]

This really just papers over a bigger problem, that of letting a template extend its parent (like Jinja `{% extends "!parent.html" %}). I'm going to call this a "feature" and push it post-1.0; for now folks can just copy/paste.

[(none)]

Milestone post-1.0 deleted

[lpetrov]

any updates?

[Tay Ray Chuan]

While we await the {% extends "!parent.html" %} feature (I don't know if this planned or not), one could do this in the meantime:

{% extends '/path/to/default/admin/templates/admin/base.html' %}

[Luke Plant]

Another way to do the above is to have a template directory which contains the other template directories (possibly via symlinks). This is added to the end of your TEMPLATE_DIRS. Then, the tag looks like:

{% extends 'alltemplate/admin/base.html' %}

See ExtendingTemplates

[Julien Phalip]

I don't think this ticket should have been closed. No decision has been taken yet about whether or not the template extension system will be improved to cover this issue.

[vinyll]

making a symlink and extending it does the trick.
However, +1 for making it extendable.

[Matthias Kestenholz]

Related tickets:
#2414 coredump of python by a template extending itself
#14140 There is no way to override admin templates to the project level

[Marinho Brandão]

This change should be done for many of admin templates, like:

• app_index.html
• change_form.html
• change_list.html
• delete_confirmation.html
• index.html
• login.html
• object_history.html

All of those above could be renamed as "base_*" and a new one with original name would just "{% extends "base_..." %}" .

The worst part on customizing Admin is to make a symlink of admin's templates directory with a fake name to can extend them to avoid a bad copy/paste of all a directory. It works, but it's a quick fix.

I think: what's the problem with this idea, if many other things in Django does the same? (i.e.: every class and templates starting with "base... ")

[Marinho Brandão]

BTW, Jacob, I guess that allow extending from another template with the same name, like a parent as Jinja does is incompatible with Django's model for templates.

Because Django just finds a template by name in the sequence of template loaders and their internal sequences (usually TEMPLATE_DIRS and INSTALLED_APPS).

There's no "parent", really. What's there is just a template that is found before another with the same name, so, how could we say to a template to extend its parent? Skipping its own to find the next in the sequency of paths?

So, I guess this would be a worse trick than just rename those templates as base_* and extend them to the right name.

[jacmkno]

Another ticket about this issue: http://code.djangoproject.com/ticket/14140. I think a good solution would be to change the template look up process to prevent cycles, initially by ignoring a template path which is the same as the template that triggered the lookup, and beyond, by changing the lookup algorithm to flag "search nodes" in order to prevent multi-node cycles.

[jacmkno]

Another ticket about this issue: ​#14140. I think a good solution would be to change the template look up process to prevent cycles, initially by ignoring a template path which is the same as the template that triggered the lookup, and beyond, by changing the lookup algorithm to flag "search nodes" in order to prevent multi-node cycles.

[Pablo Martín]

We have implemented a generic solution for a template so that a template loader can extend another template from another template loader. Both templates have the same name.It is described in ticket #15053.

I am going to upload a sample project​. You can see the example visiting the admin site ​index or a ​change list. This project work with trunk.

I think the principal is the idea:

• It makes sense that a template of a project extends a template for an application, both templates have the same name.
• It makes sense that a template of a project extends a template of an egg, both templates have the same name.
• It makes sense that a template for an application extends a template of an egg, both templates have the same name.

A template can extend always of another template of another template loader if the order of the template loaders are the correct.

It's posible that exists a case where a template of an application extends another template of another application, with the same name, but it's a strange case, this case will be hard to debug, and this should be delegated to the template loader "app_directories".

[Preston Timmons]

This was fixed as part of #15053.