nunjucks: extends, defined block multiple time
file1.html
{% block test %}
file1
{% endblock %}
file2.html
{% extends "file1.html" %}
{% if true %}
{% block test %}
file2 block1
{% endblock %}
{% else %}
{% block test %}
file2 block2
{% endblock %}
{% endblock %}
expected: file2 block 1
actual: file2 block 2
the precompiled js-file for file2.html contains the function for the test-block twice with the same name so the last defined instance of the block get called regardless of what case the if falls into.
About this issue
- Original URL
- State: open
- Created 8 years ago
- Comments: 18 (6 by maintainers)
Commits related to this issue
- Throw an error if a block is defined multiple times. Refs #696. — committed to mozilla/nunjucks by carljm 8 years ago
- Throw an error if a block is defined multiple times. Refs #696. — committed to mozilla/nunjucks by carljm 8 years ago
- Merge branch '2.x' * 2.x: Bump version to 2.5.0-dev.2. Update version in Changelog, too. Release 2.4.1. Backport not escaping SafeString; it's a bug. Update changelog. Merge pull request ... — committed to mozilla/nunjucks by carljm 8 years ago
- [nj] commented out conditional block handling see https://github.com/mozilla/nunjucks/issues/696 — committed to LotusTM/Kotsu by mrhyde 8 years ago
this now throws but doesn’t implement
self, makes it impossible to render the same block two times (and used to work)Same problem, I used this to render a block twice, and now it breaks.
The bug allowed for same-file block inheritance (e.g. breaking apart a template into multiple blocks in the same file, each one executing in the same context of the file’s “master” block) which seemed like handy and intended behavior.
Sorry for the upgrade surprise, everyone. If I’d thought it through more carefully, I’d have delayed this fix to 3.0.
I still think the previous behavior was a bug. There’s no reasonable interpretation of multiple definitions of the same block that applies to all possible inheritance situations, and the prior behavior was accidental and arbitrary (“last one wins”), silently dropping one of the definitions in some cases. So IMO this change is going to be in 3.0 regardless, and you may want to start thinking about alternate approaches now. But I could consider a 2.5.1 release that reverts the change for now.