Code

Opened 6 years ago

Last modified 20 months ago

#6646 new Bug

included template blocks are not being overridden by parent template.

Reported by: anonymous Owned by:
Component: Template system Version: master
Severity: Normal Keywords: include, extends, block
Cc: michael@…, tom@…, mmitar@…, drackett@…, dueSouth, botondus@…, dev@…, flisky Triage Stage: Accepted
Has patch: yes Needs documentation: yes
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description (last modified by ramiro)

When including a template into a parent template, the child-template's blocks are not overridden by the parent.

For example:

base.html:

{% if is_satchmo %}
{% include "satchmo_base.html" %}
{% else %}
{% include "journal_base.html" %}
{% endif %}

journal_base.html contains the following block:

{% block content%}{% endblock %}

view_template.html extends base.html (with the context variable is_satchmo == False). view_template.html contains {% block content%}{% endblock %} which should filled with data from the view's context variable.

If I rename journal_base.html to base.html - everything works fine - but when I use the version of base.html that relies on the include tag, {% block content %} doesn't get overridden.

The documentation says that context vairables are available to included templates, so not being able to override blocks seems like a bug.

Attachments (2)

6646.diff (3.0 KB) - added by miracle2k 5 years ago.
includes tests
6646.2.diff (3.0 KB) - added by SmileyChris 5 years ago.

Download all attachments as: .zip

Change History (25)

comment:1 Changed 6 years ago by Collin Grady <cgrady@…>

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

Context variables have nothing to do with blocks - as far as I'm aware this is just how the template system works - included templates cannot be extended.

comment:2 Changed 6 years ago by edgarsj

  • Component changed from Template system to Documentation
  • Triage Stage changed from Unreviewed to Accepted

Probably documentation needs to clarify this.

comment:3 Changed 6 years ago by ramiro

  • Description modified (diff)

comment:4 Changed 6 years ago by miracle2k

  • Cc michael@… added

Changed 5 years ago by miracle2k

includes tests

comment:6 Changed 5 years ago by miracle2k

  • Has patch set

comment:7 Changed 5 years ago by cornbread

Why is this documentation? When can we see it in trunk?

comment:8 Changed 5 years ago by cgrady

it is documentation because it is not supposed to work - as such, it needs documented that this is the case, so that people don't think it's a bug

comment:9 Changed 5 years ago by walpatal

  • Owner changed from nobody to walpatal

I've been biten by this enough times to take a stab solving it.

Changed 5 years ago by SmileyChris

comment:10 Changed 5 years ago by SmileyChris

  • Component changed from Documentation to Template system
  • Needs documentation set

There's no reason this can't work (for static include blocks), so I'm switching the component back to "template system".

I've attached an updated patch which does it a bit safer than miracle2k's way (the way that Node.get_nodes_by_type() works, if nodelist attribute is there, it currently assumes it's a NodeList and not None so a nodelist property doesn't work)
We do need some documentation to say that dynamic include blocks won't be extended. Wanna write something up walpatal?

comment:11 Changed 5 years ago by mpaolini

a different but somewhat related feature is selective include tag #11832

comment:12 follow-up: Changed 4 years ago by Thomas Steinacher <tom@…>

  • Cc tom@… added

The patch is working for me. Any reason this is not in trunk yet?

comment:13 in reply to: ↑ 12 Changed 4 years ago by lukeplant

Replying to Thomas Steinacher <tom@eggdrop.ch>:

The patch is working for me. Any reason this is not in trunk yet?

Without docs for the point SmileyChris mentioned it won't go in. Also, I suspect that fixing #12064 would break this patch, because it effectively makes all include blocks 'dynamic' i.e. the actual template used is decided at render time, not compile time. If my suspicions are correct, then there are definitely some design decisions to be made.

comment:14 Changed 4 years ago by walpatal

  • Owner walpatal deleted

comment:15 Changed 4 years ago by mitar

  • Cc mmitar@… added

comment:16 Changed 4 years ago by chrisdrackett

  • Cc drackett@… added

comment:17 Changed 3 years ago by julien

  • Type set to Bug

comment:18 Changed 3 years ago by julien

  • Severity set to Normal

comment:19 Changed 3 years ago by dueSouth

  • Cc dueSouth added
  • Easy pickings unset
  • UI/UX unset

comment:20 Changed 3 years ago by bberes

  • Cc botondus@… added

comment:21 Changed 2 years ago by brillgen

  • Cc dev@… added

comment:22 Changed 2 years ago by flisky

  • Cc flisky added

comment:23 Changed 20 months ago by jezdez

  • Summary changed from included template blocks are not being overrided by parent template. to included template blocks are not being overridden by parent template.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as new
The owner will be changed from (none) to anonymous. Next status will be 'assigned'
as The resolution will be set. Next status will be 'closed'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.