Opened 15 years ago

Closed 10 years ago

Last modified 10 years ago

#12008 closed Cleanup/optimization (fixed)

included templates' blocks do not get processed as if they were from the context of the including page

Reported by: tim@… Owned by: conor
Component: Documentation Version: dev
Severity: Normal Keywords: include block
Cc: Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

Consider the following example:

A.html:

{% block B %}{% include 'B.html' %}{% endblock %}

B.html:

{% block test %}this is a test default from B{% endblock %}

C.html:

{% extends 'A.html' %}
{% block test %}this is the test block from C{% endblock %}

This results in the "test" block being the default from the B template, as opposed to getting overriden with the test block that's defined in C.

However, the following works:

A.html:

{% block test %}this is a test default from B{% endblock %}

C.html:

{% extends 'A.html' %}
{% block test %}this is the test block from C{% endblock %}

In this case the test block from C is correctly used.

The documentation states:

If an included template contains any template code — such as tags or variables — then it will get evaluated with the context of the template that’s including it.

If this were true I believe the top example should be valid.

Change History (12)

comment:1 by Russell Keith-Magee, 15 years ago

Triage Stage: UnreviewedDesign decision needed

Marking this DDN because I'm not sure what the right interpretation is here. I can certainly see your point, but I can also see why the current behavior is happening. There is a design issue to consider here -- and in addition to determining whether you are correct, we need to determine if we can make this change without breaking backwards compatibility.

comment:2 by Russell Keith-Magee, 15 years ago

#12064 is a related problem.

comment:3 by Russell Keith-Magee, 15 years ago

Component: Template systemDocumentation
Triage Stage: Design decision neededAccepted

After discussing with ubernostrum on IRC, we've come to the decision that the current implementation is correct, and that the documentation should be updated to better explain the situation.

The formal explanation is that {% include %} doesn't participate in block structure - blocks are evaluated, then includes, then the remainder of template nodes.

comment:4 by Gert Van Gool, 14 years ago

#6646 discusses the same problem.

comment:5 by Julien Phalip, 14 years ago

Easy pickings: unset
Severity: Normal
Type: Cleanup/optimization

Calling this a doc cleanup/improvement as per Russ's comment.

comment:6 by Aymeric Augustin, 13 years ago

UI/UX: unset

Change UI/UX from NULL to False.

comment:7 by conor, 10 years ago

Owner: changed from nobody to conor
Status: newassigned

I would like to try to fix this. I think the confusion has been mostly resolved in the newer documentation, as far as I can see here in the 'note'. I think it would be useful to add a version of russellm's clarification regarding blocks, as they are currently not mentioned. Would an example also be necessary?

comment:8 by conor, 10 years ago

Made pull request here.

comment:9 by conor, 10 years ago

Has patch: set

comment:10 by conor, 10 years ago

Made updated pull request with the wording suggested by evildmp, which I agree does a better job of explaining the process.

comment:11 by Tim Graham <timograham@…>, 10 years ago

Resolution: fixed
Status: assignedclosed

In 80b8d3bee035b56b0d9ac57dd732dffa3b2d5f3c:

Fixed #12008 -- Clarified relationship between template blocks and includes.

Thanks Daniele Procida for suggested wording.

comment:12 by Tim Graham <timograham@…>, 10 years ago

In b729ef0bda5009389da7e3a5498dc1f6233761d6:

[1.7.x] Fixed #12008 -- Clarified relationship between template blocks and includes.

Thanks Daniele Procida for suggested wording.

Backport of 80b8d3bee0 from master

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