Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Support included blocks override #84

merged 1 commit into from May 19, 2013


None yet
7 participants

paradoxxxzero commented Jan 5, 2012

This commit fix inheritance with included blocks.
Consider these templates:


I am A
{% include 'I.jinja2' %}


Who are you ?
{% block whoami %}
    I am I
{% endblock %}


{% extends 'A.jinja2' %}
{% block whoami %}
    I am B
{% endblock %}

As of now, rendering B.jinja2 would output:

I am A
Who are you ?
I am I

This patch allow B to override I block, the output will be instead:

I am A
Who are you ?
I am B

mitsuhiko commented Jan 8, 2012

This changes behavior and was never intended to be supported. However since the whole scoping is something I want to overhaul I will decide in neither way right now and try to find a solution that is compatible with the current behavior and would support blocks be defined in included templates.


SimonSapin commented Jan 9, 2012

How is the proposed patch not compatible with the current behavior?

equake commented Nov 16, 2012

I would love to be able to override blocks like this.
In my case, i have a base template that is extended by a lot of templates.
Sometimes those templates have to include "components" (for example: an slideshow).
This include need to add some <script> tag in the page header to work properly. It would be nice if it could override/extends the "scripts" block defined in the base template.
Is there any alternative way to accomplish this with jinja?

@mitsuhiko mitsuhiko merged commit 33aee12 into pallets:master May 19, 2013


mitsuhiko commented May 19, 2013

I merged this now. I don't see how this breaks anything currently.

lakshmivyas added a commit to hyde/j2includebug that referenced this pull request Jun 10, 2013

Jinja2 2.7 breaks include statements by allowing block overrides.
This provides a basic jinja2 static template that demonstrates the
breaking behavior introduced by pallets/jinja#84.

@mitsuhiko - This change breaks a few websites that use hyde. Here is a simple demo:

Pushing parent blocks along with other context variables is surprising IMO. I'd like to propose:

{% include "xxx" with context and blocks %}

or something similar instead if its not too late.


Here is (hopefully) a better statement of the bug:

Given a container C and an include I, this patch really includes container C with the include I injected at the top of the extension hierarchy of C. As long as I and C have completely different set of blocks this is okay. However, when there is an overlap between the blocks of I and C, the results will likely be surprising(bad).

I think its safer to completely pull this change out and reintroduce it only if a block resolution order can be provided alongside.

To add to this, this update seem to break my site badly (unless I'm doing something else wrong of course...)

I have three template files, A, B and Base.

{% block content %}{% endblock}

{% extends Base %}
{% block content %}
lorem ipsum {% include B %}
{% endblock}

{% block content %}
dolor sit
{% enblock %}

This throws me in maximum recursion, as (if I understand it correctly), in A.content we include B.content which was defined in A.content and so on? I had the same structure which was not an issue before, I presume before this update the block content in the included template was simply ignored?

I can include without context but that will break other things, e.g. not being able to pass my model objects down to the included templates.

@akhilputhiry akhilputhiry referenced this pull request in mkdocs/mkdocs Mar 6, 2017


Block override doesnt work #1142

Will this feature be revived? Would be very happy to see this. The lack of this feature is the only issue I have had so far with Jinja2.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment