UnboundLocalError: local variable 'data' referenced before assignment

[gforcada]

See traceback

https://www.freitag.de/autoren/XXX/@@edit/++widget++form.widgets.portrait/@@download/2014-07-05+%2865%29.JPG
Traceback (innermost last):
  Module ZServer.ZPublisher.Publish, line 144, in publish
  Module ZPublisher.mapply, line 85, in mapply
  Module ZServer.ZPublisher.Publish, line 44, in call_object
  Module plone.formwidget.namedfile.widget, line 409, in __call__
  Module plone.formwidget.namedfile.widget, line 72, in _make_namedfile
UnboundLocalError: local variable 'data' referenced before assignment

Our sentry server reports that the value variable is None, as the URL shows, it is on an edit form, so the widget does not have any image? 🤔 but as one can see on the code, before line 72 there is an if... elif clause that has no fallback value for value variable.

[Pernath]

What can we do to avoid or patch the bug without messing with the widget.py code? My team has been facing this issue while using NamedFileField inside subforms.

[Pernath]

What can we do to avoid or patch the bug without messing with the widget.py code? My team has been facing this issue while using NamedFileField inside subforms.

After a session of several hours of debugging, we found the culprit in this scenario. Turns out, the NamedFileWidget is only prepared to remember one file at a time in the loaded form, so in actuality, we were abusing Plone's subform capability with a field not intended to be used in it (that's our wild guess). Specially because said NamedFile field, was an attribute of an object subform that we chose as the value_type of a schema.List field.

We found a very problematic line in widget.py (291):

del upload_map[file_upload_id]

That cleaning of the temporary storage, wouldn't allow us to make multiple uploads of files for each element of the List field.

As a workaround, we made a custom widget class inheriting the NamedFileWidget and a slight modification to the extract method to avoid this deletion. After the successfull retrieval of the multiple NamedFile fields values, and the creation of the element of our problematic content type, we then proceeded to clean the multiple file upload ids, recollected during the widgets' update function calls.