Code

Opened 8 years ago

Closed 8 years ago

Last modified 8 years ago

#1591 closed defect (fixed)

Multiple-level template inheritance doesn't work if "extends" tag is not first in the template

Reported by: Chris Chamberlin <dja <@…> Owned by: adrian
Component: Template system Version:
Severity: minor Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description

I have a three-template chain of inheritance - my templates are named "p1.html", "p2.html", and "p3.html", and are as follows: p1:

<html><body>
P1 BODY BEGIN<p>
{%block p1a%}
P1 A!<p>
{%endblock%}
{%block p1b%}
P1 B!<p>
{%endblock%}
</body></html>

p2:

{%comment%}This comment comes first in P2{%endcomment%}
{%extends "p1"%}
{%block p1a%}
P2 (should replace P1A)<p>
{%endblock%}

p3:

{%extends "p2"%}
{%block p1b%}
P3 (should replace P1 B)<p>
{%endblock%}

The defect is if the {%comment%} tag in p2 is present, the replacement of block p1b in p3 does not happen. A rendering of p3 comes out like so:

P1 BODY
P2 (should replace P1A)
P1 B!

If I remove the comment tag, or move the {%extends "p1"%} in p2 above it, then it works, and for p3 I get:

P1 BODY
P2 (should replace P1A)
P3 (should replace P1 B)

Note that this apparent "extends tag must be first in the template" requirement only occurs for the situation where the block I'm replacing was not defined in the immediate parent, but only in an earlier ancestor. So even if it is desirable (I think not), or technically necessary (don't know), for the "extends" tag to be first, it should be consistent.

This appears in both 0.91 and in the trunk.

Attachments (0)

Change History (1)

comment:1 Changed 8 years ago by adrian

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

Thanks for pointing this out. I think the solution here is better documentation. In [2660], I added an explicit note to the template docs that the extends tag needs to be the first tag in a template.

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.