1.8 seems to block form field rendering with Django 1.11. 1.7 works fine (though slow)

[eskhool]

Hi, On rendering a form field using a simple {{ my_form_name.my_field_name }} which works fine without debug toolbar makes the field disappear in 1.8. It works fine with 1.7 (both tested using Django 1.11) although 1.7 is very slow (2-3 seconds for page load)

[eskhool]

Have narrowed the issue down to the Templates Panel. Now investigating why and how can the panel influence the rendering itself (which shouldn't ever happen)

[eskhool]

@matthiask, since you were pretty active with release 1.8 and this issue seems to have started with 1.8, do you have any quick ideas what might be causing this?

[matthiask]

We had massive slowdowns with Django 1.11 that were reported in #910. I thought those were fixed but your report suggests that this isn't the case. Do you have a chance of profiling the panel to find out where the problem might be? No quick ideas unfortunately :-(

[eskhool]

@matthiask, I think I didn't make myself clear. The slowdowns are indeed fixed with DjDT 1.8 however the template rendering seems to be broken in places as the rendered page is missing content specifically with the Templates panel enabled. That shouldn't happen at all!

I am using a simple template variable from a form field which works fine without djdt1.8 but renders empty with the template panel enabled. It also renders fine when djdt1.8 is used without template panel enabled.

{{ my_form_name.my_field_name }}

[sspross]

we experienced the same problem and the problem was a field queryset, which is somehow evaluated by debug_toolbar.panels.templates.TemplatesPanel.

e.g.

class MyForm(forms.Form):
    user = forms.ModelChoiceField(queryset=User.objects.all())

[kezabelle]

I'm fairly certain the problem, at least as @sspross has shown it, is my doing, as part of #933, because pformat was so slow, we (I) moved to using force_text to evaluate the variable (which is intrinsically known to perhaps cause an SQL query) - forgetting that the __str__ for anything Form related is ... the HTML for the form. Probably using _saferepr is more correct, whilst still avoiding some of the inherent slowdown using pformat multiple times causes.

As for why it prevents the form attribute rendering subsequently (when really all I think we're doing is the equivalent of {{ form }}) ... not so sure on that one. If I had to guess, the underlying ModelChoiceIterator (or whatever) was consumed ... but even then I don't think that ought to prevent the BoundField from rendering the widget, it'd just be empty in the worst case scenario?

[timthelion]

I'm suffering from a problem with django-debug-toolbar version: 1.9.1 in which the required tag is being removed from form inputs, iff django-debug toolbar is enabled. Is my problem a duplicate of this bug, or should I be working on a minimum test case myself?

@petrdlouhy

[matthiask]

@timthelion What you're reporting sounds almost certainly like a different issue to me.