#27956: Template error raised in an {% extends %} parent template shows
incorrect
source location on debug page
---------------------------------+------------------------------------
Reporter: Ling-Xiao Yang | Owner: nobody
Type: Bug | Status: new
Component: Template system | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
---------------------------------+------------------------------------
Old description:
> Hello,
>
> It seems that this problem only concerns Django 1.9 and 1.10. The problem
> has been fixed in the newest 1.11b1, but I am not sure if it has been
> backported to older versions.
>
> How to verify:
> 1. Start a new Django project, create two template html files, and make
> sure that template A uses `{% include %} tag to include the content of
> template B.
> 2. Make an error inside template B. For example, in the screenshots
> below, I am passing in a model `Question` and using `{{
> Question.objects.all }}` in template B (inner.html) to trigger an error.
> 3. Complete a view function that renders template A, and add a url route
> for it. Try access this route with DEBUG=True.
> 4. You will see the debug interface. In the section "Error during
> template rendering," you will see the error line being highlighted. The
> position and line number will be correct, but the error will be pointed
> to template A, while it should be pointed to template B where it actually
> happens.
>
> Expected behavior:
> I attached two screenshots, showing the expected behavior (using Django
> 1.11b1 and 1.8.11) and the actual behavior (using Django 1.10.6).
>
> Note:
> I discovered this problem while investigating the issue 902 of Django
> debug toolbar (on GitHub).
> It is acceptable to invalidate this ticket if the fix has been ported to
> the branch Django 1.10.x, or it is mentioned elsewhere in the
> documentation.
New description:
Please see comment:2 for updated description. Below is the original
description.
================================================
Hello,
It seems that this problem only concerns Django 1.9 and 1.10. The problem
has been fixed in the newest 1.11b1, but I am not sure if it has been
backported to older versions.
How to verify:
1. Start a new Django project, create two template html files, and make
sure that template A uses `{% include %} tag to include the content of
template B.
2. Make an error inside template B. For example, in the screenshots below,
I am passing in a model `Question` and using `{{ Question.objects.all }}`
in template B (inner.html) to trigger an error.
3. Complete a view function that renders template A, and add a url route
for it. Try access this route with DEBUG=True.
4. You will see the debug interface. In the section "Error during template
rendering," you will see the error line being highlighted. The position
and line number will be correct, but the error will be pointed to template
A, while it should be pointed to template B where it actually happens.
Expected behavior:
I attached two screenshots, showing the expected behavior (using Django
1.11b1 and 1.8.11) and the actual behavior (using Django 1.10.6).
Note:
I discovered this problem while investigating the issue 902 of Django
debug toolbar (on GitHub).
It is acceptable to invalidate this ticket if the fix has been ported to
the branch Django 1.10.x, or it is mentioned elsewhere in the
documentation.
--
Comment (by Ling-Xiao Yang):
Hello there,
Do we have a reason to have the both `_render()` and `render()` methods?
In django.template, `_render()` is not used anywhere else.
Code reference:
{{{
~/django$ grep -r "\._render(" . -A 2 -B 2
./django/forms/widgets.py- """Render the widget as an HTML
string."""
./django/forms/widgets.py- context = self.get_context(name, value,
attrs)
./django/forms/widgets.py: return self._render(self.template_name,
context, renderer)
./django/forms/widgets.py-
./django/forms/widgets.py- def _render(self, template_name, context,
renderer=None):
--
./django/forms/boundfield.py- def tag(self, wrap_label=False):
./django/forms/boundfield.py- context = {'widget': self.data,
'wrap_label': wrap_label}
./django/forms/boundfield.py: return
self.parent_widget._render(self.template_name, context, self.renderer)
./django/forms/boundfield.py-
./django/forms/boundfield.py- @property
--
./django/template/loader_tags.py- # Call Template._render
explicitly so the parser context stays
./django/template/loader_tags.py- # the same.
./django/template/loader_tags.py: return
compiled_parent._render(context)
./django/template/loader_tags.py-
./django/template/loader_tags.py-
--
./django/template/base.py- with
context.bind_template(self):
./django/template/base.py- context.template_name =
self.name
./django/template/base.py: return self._render(context)
./django/template/base.py- else:
./django/template/base.py: return self._render(context)
./django/template/base.py-
./django/template/base.py- def compile_nodelist(self):
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/27956#comment:5>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/070.971f7fb8060753d5084d42530ecea42b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
