Missing Admin Template Context Variables in Django 5.2.4 (e.g., adminform, inline_admin_formsets)

[hazra1991]

Python version
3.13.5
Django version
5.2.4

Package version
0.30.1

Current behavior (bug description)
Django-admin-interface still renders visually, but backend logs show errors due to missing context variables like adminform and inline_admin_formsets.

These variables are typically used in overridden admin templates like admin/base_site.html.

Additionally, a similar issue has been observed in "filter.html", particularly involving the "value" template tag.

Expected behavior
No backend errors

[fabiocaccamo]

@hazra1991 thank you for reporting this, could you work on a PR?

[hazra1991]

@fabiocaccamo sure ,i will start working on a PR. Thanks for the quick response !

[fabiocaccamo]

@hazra1991 any update?

[hazra1991]

@fabiocaccamo Kindly check the PR and let me know.

Also in our env we have safely suppressed these log noises via

LOGGING = {
    "loggers": {
        "django.template": {
            "handlers": ["null"],
            "level": "WARNING",
            "propagate": False
        }
    }
}

[merwok]

I find the PR a bit baffling. Can we take a step back: why are these variables missing in the template context in the first place?

[fabiocaccamo]

@hazra1991, @merwok is right, we should just check where these variables are used without checking before if they are available and use a condition in the template.

[merwok]

I was saying more: let’s make sure they are present in the template contexts defined by the right views. In other words: do we know why they are missing?

[hazra1991]

What I observed is that the admin/change_form.html template use the adminform and inline_admin_formsets variables, and when that file is rendered, Django properly populates those variables in the context.

in file django/contrib/admin/options.py

 context = {
    **self.admin_site.each_context(request),
    "title": title % self.opts.verbose_name,
    "subtitle": str(obj) if obj else None,
    "adminform": admin_form,
    "object_id": object_id,
    "original": obj,
    "is_popup": IS_POPUP_VAR in request.POST or IS_POPUP_VAR in request.GET,
    "to_field": to_field,
    "media": media,
    "inline_admin_formsets": inline_formsets,
    "errors": helpers.AdminErrorList(form, formsets),
    "preserved_filters": self.get_preserved_filters(request),
    }
return self.render_change_form(
            request, context, add=add, change=not add, obj=obj, form_url=form_url
        )

But if any other page, like the index page or pages that don’t require the admin form, is rendered, the context is not populated with adminform. Since admin/base_site.html is extended, and the django-admin-interface includes adminform in admin/base_site.html, it causes a VariableDoesNotExist stack trace when the variable is missing. This doesn't break anything , Django just logs it , but it unnecessarily pollutes the logs.

@fabiocaccamo not sure if the same is required in the base_site.html or not.

for a workaround we are suppressing the debug logs for the django.template for now

[merwok]

Thanks for the reply!

But if any other page, like the index page or pages that don’t require the admin form, is rendered, the context is not populated with adminform. Since admin/base_site.html is extended, and the django-admin-interface includes adminform in admin/base_site.html,

OK this is the heart of the problem. Could we just add if adminform in the base template then?
(I forget if django templates lets us test for undefined like this)

[hazra1991]

@merwok as far as i checked ,adding a {% if adminform %} guard doesn't actually help in this case, because Django attempts to resolve the adminform variable even within the conditional check. If adminform is not present in the context, this still triggers a VariableDoesNotExist exception internally, which gets logged.
Though Django is tolerant of these cases and returns an empty string, it still logs the error.