Webform with file upload fatal error/WSOD when used with mollom: Cannot unset string offsets in ... form.inc on line 2146

I can confirm that this is happening in 7x-1.1. Running PHP 5.3. I am investigating further.

Yes, This is happening for me too.

Yes, just confirmed that this is happening for me as well. 7.x-1.1 and 7.x-2.0. PHP 5.3 and 5.2.

mollom_form_get_values calls form_state_values_clean and it seems to have trouble on line 2144 (7.x-2.0) trying to unset the button for the file upload.

This patch is a temporary fix to allow webform submissions which include file uploads to work with the mollom module. Per http://drupal.org/node/1515158, Webform sets the fid via ajax and core's form_state_values_clean() cannot unset related fields. This code modifies core's form_state_values_clean() to skip file upload related field submitted via Webforms. The fixed version of the function is _mollom_form_state_values_clean().

This fix allows our forms to submit, while maintaining mollom processing. This doesn't feel like the best solution for this issue, but seems to work so far. Please let me know any improvements or suggestions for this patch.

I tried applying this patch using the patch command and it failed:

$ patch -p0 --dry-run < mollom-webform-file-upload-WSOD-1515158-4.patch
patching file a/mollom.module
Hunk #1 succeeded at 966 (offset -34 lines).
Hunk #2 FAILED at 1091.
1 out of 2 hunks FAILED -- saving rejects to file a/mollom.module.rej

I then patched the second hunk manually, and the patch seems to work.

It seems to me that the onus is on webform to fix this, since it is webform that is causing the structure of the values array to be different than what form_state_values_clean() would normally expect. The error does not happen with a regular node form with a file upload field that is checked by mollom.

Here's a suggestion of a way around this in webform module's file component. It is not ideal in that it uses a validate hook to remove the upload button from the $form_state['buttons'] array, which is a bit of an abuse of a validate hook, not to mention the fact that I don't know what possible side effects this removal might have. But I don't see where/how else we can get in and prevent the incompatible structure of $form_state (i.e. where the values array no longer corresponds properly to the buttons array) from causing this fatal error.

Hmm, not sure about this. I'll need to think about it. I'm trying to reduce the amount of 3rd-party integrations in Webform where possible, especially weird work-arounds like this.

The patch in #4 was to Mollom specifically, not webform, and it spells mollum instead of mollom.

Re #7, I wouldn't reject #6 for being a third-party integration. The only mention of mollom is in a comment, there's no module_exists() call. If you want it changed, then you should reject it for not being the best solution to the issue.

The only mention of mollom is in a comment, there's no module_exists() call.

Right exactly. It's a *very* loosely related bit of code that fixes a problem specifically for one module. It's difficult to understand what the code is actually accomplishing, considering it's intended to fix a very specific problem. If we can fix this in a way that doesn't require some kind of data "cleanup" that would be preferable for me.

Is there any way we can prevent mollom from skipping validation on the upload of files? Even though it doesn't cause a problem on the node form, mollom doesn't have any reason to be executing its validation in either place.

The core definition of the managed_file element already sets #validate to an empty array(), how's mollom getting its validations in here when the managed_file element is telling everything not to do validations?

http://api.drupal.org/api/drupal/modules%21file%21file.module/function/f...

Oh, reading the issue some more, this problem doesn't happen on file upload but on submission of the form. I'll need to look into this more. Sorry for the confusion.

@quicksketch: I had a similar (seemed related) issue between a Webform with a file upload field and http://drupal.org/project/hidden_captcha. I need to get more info on that to be more helpful though.

Mollom team: After doing some work in the Webform queue recently and thinking about this problem, it struck me: Why doesn't mollom just put their #validate or #submit handler at the beginning of the list instead of the end? Then it won't be affected by Webform (or other modules) modifying their submission data. If I'm still not understanding the issue quite properly I apologize, I still haven't dug into the mollom code to get a full grasp on the problem.

I get the same problem with the Webform/Mollom/image upload combo, but only with anonymous users. When I am logged in it works fine.

It seems the error occurs at line 2160 my includes/form.inc file (D7.14). The code is

    if(isset($values[$last_parent]))
    {
	    unset($values[$last_parent]); <----- line with error
    }

For some reason $values is a string (and holds a number) and PHP (5.2.13) returns true on the isset($values[$last_parent]) check, even when $values is a string. unset is not so forgiving.

A quick fix - which might also catch other problems - is to check whether $values is an array before unset:

    if(isset($values[$last_parent]))
    {
	if(is_array($values))
	{
	    unset($values[$last_parent]);
   	}
   }

This works for now. Perhaps it can be elaborated to include a $values = "" when $values is a string.

NOTE: On the next kernel update the form.inc is likely to be overwritten.

The patch in #6 fixes the fatal, but as a side-effect the uploaded file doesn't appear to actually get saved.

#14: That would make FAPI fatal less, but doesn't hide that the error is elsewhere. Of course, the real problem is that FAPI's design makes errors such as this very easy to introduce and hard to track down. Also, I have no idea what kernel update you're talking about...

Correction. The files ARE saved, they're just not displayed properly on the submission pages. I don't know if that's part of this bug or not, but here's an updated patch (rolled against 3.17, technically, but should be fine) that addresses that problem, too.

I don't know that this is the ideal solution, but it's a solution that Works For Me(tm).

Getting this exact same error on Webform 7.x-4.0-alpha3

Applied #16 and it fixed the issue for me.

This however introduced a bunch of other bugs, e.g Warning: htmlspecialchars() expects parameter 1 to be string, array given in check_plain() (line 1572 of /var/www/drupal/tpow/releases/20120626-1/includes/bootstrap.inc). on viewing a submission, and when editing a submission various values were not filled out correctly

This is a bug in Drupal core, and I'd recommend to close this as duplicate:

#1090198: managed_file form item in system settings form causes error in form_state_values_clean()
#635046: form_state_values_clean() is polluting form values (followup)

I applied #16 and it works, but the file cannot be found when you look in the submitted results. I analysed a bit, and I think ignoring the last section of the patch will fix this. I hope this works also for you guys.

function _webform_display_file($component, $value, $format = 'html') {
$fid = isset($value[0]) ? $value[0] : NULL;
+ $fid = isset($value['fid']) ? $value['fid'] : NULL;
return array(
'#title' => $component['name'],
'#value' => $fid ? webform_get_file($fid) : NULL,

#16 worked for me.

I can confirm Zaka's observation in #21.

Sounds like this patch needs work based on #19 and onwards.

This is an old issue, and I'm not even sure if there is still and issue. Version 7.x-3.x is receiving critical bug fixes only. If there is still an issue with 7.x-4.x, please re-open with new info.