Key class_attrib missing in result_headers dict used in change_list_results template

[zdenek.bohm@…]

Template change_list_results required key class_attrib in result_headers dict.

browser/django/trunk/django/contrib/admin/templates/admin/change_list_results.html

{% for header in result_headers %}<th{{ header.class_attrib }}>

But function result_headers() returns only {"text": header} item (line 112):

browser/django/trunk/django/contrib/admin/templatetags/admin_list.py

if not admin_order_field:
    yield {"text": header}
    continue

[Jacob]

This key is used elsewhere (i.e. ​http://code.djangoproject.com/browser/django/trunk/django/contrib/admin/templatetags/admin_list.py#L127).

[zdenek.bohm@…]

Hm. I probably described this problem badly. If function result_headers ends on the line 113 (!!!), it returns only dict {"text": header}. But template change_list_results.html needs value class_attrib. If this value missing, the html code looks like this: <thINVALID VARIABLE>. This situation occurs, when the column in the list is not defined as a field in model but as a function only.

For example:

class Person(models.Model):
    first_name = models.CharField(max_length=50)
    last_name = models.CharField(max_length=50)

    def upper_case_name(obj):
        return ("%s %s" % (obj.first_name, obj.last_name)).upper()
    upper_case_name.short_description = 'Upper Name'

class PersonAdmin(admin.ModelAdmin):
    list_display = ("first_name", "upper_case_name")

And now see title of the column Upper Name in the person admin list. Correction is simple: Just add if to the template change_list_results.html:

<th{% if header.class_attrib %}{{ header.class_attrib }}{% endif %}>

I hope, it is clear now.

[Malcolm Tredinnick]

This isn't a bug. Templates are designed to be able to handle missing attributes. If there are no attributes required for the "th" element, then not supplying the class_attrib variable is quite valid. It will simply be rendered as an empty string.

You are only seeing something different because you've set TEMPLATE_STRING_IF_INVALID to something other than the empty string. That is not designed for anything other than testing and debugging (that is documented). There are lots of templates (Django's admin being one of them) that rely on missing variables failing silently. It means we can write templates in the way it's done now, rather than the much more verbose version that you are proposing as the "fix".

So there's no bug here. When you run the site with TEMPLATE_STRING_IF_INVALID set back to the empty string, it will work perfectly.