#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: | 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 , 15 years ago
Triage Stage: | Unreviewed → Design decision needed |
---|
comment:3 by , 15 years ago
Component: | Template system → Documentation |
---|---|
Triage Stage: | Design decision needed → Accepted |
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:5 by , 14 years ago
Easy pickings: | unset |
---|---|
Severity: | → Normal |
Type: | → Cleanup/optimization |
Calling this a doc cleanup/improvement as per Russ's comment.
comment:7 by , 10 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
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:9 by , 10 years ago
Has patch: | set |
---|
comment:10 by , 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 , 10 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
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.