Code

Opened 4 years ago

Closed 4 years ago

#13672 closed (duplicate)

template cache tag should gracefully handle uninitialized variables

Reported by: nbv4 Owned by: nobody
Component: Uncategorized Version: master
Severity: Keywords: template cache
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description

I keep running into this problem. I have a page that uses the template cache tag. One of the variables that gets used as a cache key is sometimes available in the context, sometimes not (it's added to the context via middleware).

If the variable is not initialized, the whole page fails to render. EX:


context:

{key1: 'value', key2: 'another value'}


template:

{% if key3 %}
no errors are thrown here
{% endif %}

{% cache 1800 mycache key1 key2 key3 %}
causes a problem
{% endcache %}


result:

Caught VariableDoesNotExist while rendering: Failed lookup for key [key3] in u"[{'key1: 'value', key2: 'another value'}]"

I think it would be best to just have the key be "None" if it's uninitialized instead of throwing an error.

Attachments (1)

tcache.diff (930 bytes) - added by nbv4 4 years ago.

Download all attachments as: .zip

Change History (3)

Changed 4 years ago by nbv4

comment:1 Changed 4 years ago by d0ugal

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

I don't know off hand which do and which don't but it seems fairly common for a tag to fail if the template doesn't exist. Presumably this could be resolved by wrapping {% cache %} in a if statement?

I think this might be a case of DDN. Since there is a fine line where failing gracefully is good and obfuscating errors is bad. I don't like the idea of thinking i'm caching only to realise later that the variable is not quite making it to the template.

comment:2 Changed 4 years ago by kmtracey

  • Resolution set to duplicate
  • Status changed from new to closed

#13167 is open for tracking the general problem of VariableDoesNotExist being raised by non-existent filter/tag arguments. There is at least one tag (if) that suppresses this behavior, but in general VariableDoesNotExist has been raised for these error cases since before 1.0. The proposal to change the general behavior involves checking TEMPLATE_DEBUG to decide whether to raise an exception or not. Since I believe we want to fix the problem in general and not take a tag-by-tag approach, I'm going to close this as a dupe of that.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.