Opened 4 years ago

Last modified 4 years ago

#16915 new New feature

contrib.admin should use a variable to select base_site template

Reported by: CBWhiz Owned by: nobody
Component: contrib.admin Version: master
Severity: Normal Keywords:
Cc: Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


Currently, I have two AdminSite instances. I'd like them to be customized in different ways. For this example, suppose I want a different branding for each section (say 'Warehouse Admin' and 'Content Admin') at the top of every admin page.

The current suggested way to customize the admin is to create a new admin/base_site.html file and fill in the branding and title blocks. However, in the scenario above, both AdminSite instances will use the same base_site template.

I suggest AdminSite be given a new instance level attribute called base_template_name, have all admin views pass this variable to the template context (or create an admin ContextProcessor), and change each admin template from {% extends "admin/base_site.html" %} to {% extends admin_base %}.

Another option would be just changing the subdirectory of the include (that is, allow each AdminSite to change the '/admin' default).

I suspect this may be able to be solved externally from the AdminSite and templates with a customized TemplateLoader, but i'm not sure how to best indicate that a particular TemplateLoader be used for a particular view response, as that seems to be a global list in the settings module.

Change History (2)

comment:1 Changed 4 years ago by carljm

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Accepted
  • Version changed from 1.3 to SVN

I lean towards being able to set the template base directory per-AdminSite, rather than pointing to the base template itself, as that gives even more flexibility if you want to e.g. just customize the change page for a single model, per-AdminSite. In any case, this is a valid use case that ought to be made easier.

comment:2 Changed 4 years ago by CBWhiz

As a temporary workaround, this Middleware and TemplateLoader does the job:

Note that this uses the threadlocal hack everyone seems to hate. Also note that if you're using Coffin for Jinja2 support, that will break due to until you apply a workaround like that described in

Note: See TracTickets for help on using tickets.
Back to Top