New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Widget no longer renders for blocks in Wagtail 6.1 #11935
Comments
Thanks for the report! I can confirm this issue. It's a regression in 9b74c83, particularly the change I pointed out in https://github.com/wagtail/wagtail/pull/11839/files#r1566809981. In short: your customisation here concatenates the rendered original As a workaround, you can change the way you render the template by moving the original textarea into your <div class="import-textarea-fileinput-container">
{% comment %}
"wagtailadmin/shared/attrs.html" is identical to "django/forms/widgets/attrs.html",
which is what the original Textarea widget uses
{% endcomment %}
<textarea name="{{ widget.name }}"{% include "wagtailadmin/shared/attrs.html" %}>
{% if widget.value %}{{ widget.value }}{% endif %}</textarea>
<input type="file"
hidden=""
id="{{ id }}-file-input"
{% if accept %}accept="{{ accept }}"{% endif %}
>
<label class="button" for="{{ id }}-file-input">{{ label }}</label>
<span class="help">{{ help }}</span>
<script>new ImportTextAreaWidget('{{ id }}')</script>
</div> Then update your widget code to: class ImportTextAreaWidget(AdminAutoHeightTextInput):
template_name = "widgets/import_textarea_widget.html"
def __init__(self, file_type_filter=None, attrs={}):
self.accept = file_type_filter
if not attrs.get("rows"):
attrs["rows"] = 5
super().__init__(attrs)
msg = {
"help": ("Use 'Choose File' or drag/drop to import data from file."),
"button_label": ("Choose file"),
}
def get_context(self, name, value, attrs):
context = super().get_context(name, value, attrs)
context.update(
{
"id": f'{attrs.get("id")}',
"label": self.msg["button_label"],
"help": self.msg["help"],
"accept": self.accept,
}
)
return context
def render(self, name, value, attrs, renderer=None):
return render_to_string(
self.template_name,
self.get_context(name, value, attrs),
) Unrelated note: after setting Since we've discussed before @gasman, do you think we should reinstate support for multiple top-level nodes as a bugfix? Or shall we label this as an enhancement? |
Great, thanks for the update and info. I'll hold off upgrading until the fix/change is included in the current release. I've got some other 3rd party Django widgets in use affected by this, I'd need a wrapper for each otherwise. Thanks also for the code suggestions above - much appreciated. |
Fixed in #11958 |
There seems to have been a change to widget loading in blocks not covered in the release notes. I have a block with custom widget that has loaded fine until Wagtail 6.1. Since upgrade, only the widget associated with the inherited Wagtail block type is rendered.
I've seen the note for initBlockWidget, but this isn't apparently relevant to this case.
I have a block that inherits
TextBlock
and overrides the widget (code working in 6.0.x):Steps to Reproduce
and widget
The
render()
method adds a file picker button and some other html then initialises a javascript class to enable the file reading capabilities.This has been in use since Wagtail 3.x.
Since upgrade from 6.0 to 6.1, the additional html is stripped out on the rendered form. The widget render method returns:
On the form, only the textarea is rendered (confirmed by manipulating the returned html - this comes from the custom widget):
The additional content in the
<div>
container has been stripped.The issue is not javascript related since none of the additional html in the render method is present in the rendered form (and no console errors).
Putting breakpoints in the
ImportTextBlock
field
method, and the widgetrender
method, I can see the code is being called as expected during page load.This issue only exists for blocks, the widget renders as expected for FieldPanels associated with a TextField.
Technical details
The text was updated successfully, but these errors were encountered: