Widget templates not refreshing

[davidtoulmin]

When running the manage.py runserver command on my local machine, custom widget templates are not getting updated on change.

If I make a change to a .py file, runserver tracks the changes, restarts, and the changes are reflected in functionality, this is as expected. If I make a change to a .html template file, runserver does not need to restart, but if I refresh a page that's using that template, my changes are reflected on page load, this is also as expected. If I have a custom .html template for a form field widget, make changes to this file, and there's a {% include 'my_app/forms/widgets/my_custom_widget.html' %} in another template, if I refresh that page the changes are reflected on page load, this is ALSO expected.

But, if I have a custom widget template, e.g 'my_app/forms/widgets/my_custom_widget.html', that for instance looks like:

<span>
  <input type="email" name="MyCustomEmail" id="id_MyCustomEmail" value="{{ widget.value }}">
</span>

and then in 'my_app/forms.py' I have either:

class MyCustomWidget(forms.EmailInput):
    template_name = "my_app/forms/widgets/my_custom_widget.html"


class MyModelForm(forms.ModelForm):
    class Meta:
        model = MyModel
        fields = ['my_form_field']

    my_form_field = forms.EmailField(widget=MyCustomWidget)

OR

class MyModelForm(forms.ModelForm):
    class Meta:
        model = MyModel
        fields = ['my_form_field']

    my_form_field = forms.EmailField()
    my_form_field.widget.template = "my_app/forms/widgets/my_custom_widget.html"

And load a page that uses that form, it loads correctly, with my custom widget showing correctly.

The unexpected behaviour comes in if I change that template ('my_app/forms/widgets/my_custom_widget.html'), eg.

<span>
  <input type="email" name="MyCustomEmail" id="id_MyCustomEmail" value="{{ widget.value }}">
  <p>Add a paragraph that should appear on the page</p>
</span>

and reload the page from before. I would expect that <p> element to appear on the page, as with any other change to a template file, any change should be reflected on page refresh, but it isn't. On page refresh the <p> isn't there. A hard refresh (e.g. ctrl+shft+r) doesn't show the p, navigating to a different page that uses that form, or loading the same form for a different instance of MyModel doesn't show the p.

The <p> element only shows up if I manually stop manage.py runserver and restart it. Then the changes are reflected on all forms using that widget, but if I make another change to the widget template the change isn't reflected again until another refresh.

I have replicated this across multiple widgets (including non EmailInput based widgets), widget templates, forms, form fields. I've replicated this across multiple colleagues' computers (both of my linux machines, and my colleagues' Mac machines). And I seem to have narrowed it down to a change between 4.0.10 and 4.1.0. In 4.0.10 (and all other 4.0 versions I've tested) a change to a widget template is instantly reflected in the browser upon page refresh (as I would expect). For version >=4.1.0 (including the current 4.2.7), this strange behaviour where template changes aren't reflected on page reload occurs, with the only change being updating the version of Django.

I've read through the release notes for 4.1 and the only thing that seems like it might be relevant is the "cached template loader" as I don't have OPTIONS['loaders'] set, but I don't see why that would only be caching templates in this one very specific circumstance, and why that would be affecting a manage.py runserver local environment.

Any help would be much appreciated. Let me know if I can provide any further information.

Thanks,
David

[David Sanders]

Duplicate of #34692

[David Sanders]

Hi David,

Thanks for the report this is fixed in the upcoming 5.0 release 👍

[davidtoulmin]

Replying to David Sanders:

Hi David,

Thanks for the report this is fixed in the upcoming 5.0 release 👍

Great, thanks for letting me know. I was going mad trying to work out if this was somehow my fault. It took me a day to track down why this was happening, especially as it was initially only happening on one dev's machine (as they were the only one who had updated to Django 4). Sorry for creating a duplicate, I had a look at the bug log, but couldn't find anything that was obviously (to me) about this.

Thanks,
David