mollom shows me some php errors when i enter in the admin (/admin/settings/mollom):
warning: Invalid argument supplied for foreach() in mollom.module on line 2337.

and a php error when i try to create a node of a content type i created with cck fields:
warning: array_unshift(): The first argument should be an array in mollom.module on line 663
the last one generate an error when i save the node... page refresh and i've to fill a captcha to save the node correctly

Comments

katy5289’s picture

I recently upgraded to Acquia Drupal 1.2.33 which has Mollom 6.x-1.15. When I go to the custom registration page, I get this warning error message: warning: array_unshift(): The first argument should be an array in mollom.module on line 663

I rolled back to a previous version (Mollom 6.x-1.14) and the error message went away. This seems to be a conflict with Content Profile 6.x-1.0

sun’s picture

Version: 6.x-1.15 » 6.x-1.x-dev
Priority: Critical » Normal
Status: Active » Needs review
StatusFileSize
new770 bytes

The first reported PHP warning is discussed in #804466: Orphan forms of other modules cause errors on administration page, but so far, cannot be cleanly reproduced -- please share your site details over there.

The second reported PHP warning in both the OP and #1 should be fixed with attached patch.

sun’s picture

Need to double-check this patch against drupal_prepare_form() in D6

sun’s picture

Title: Some php errors... » PHP warning if protected form has no #submit handlers defined
Status: Needs review » Reviewed & tested by the community

Better title. This is ready to fly for both D6 and D7 - core does not set #validate or #submit by default, which is something that should be additionally fixed in core.

A form without any #submit handler is an extreme edge-case, so I don't want to write tests for this. The added line of code can be understood as clean/solid programming anyway.

dries’s picture

Status: Reviewed & tested by the community » Needs work
+++ mollom.module	29 Jan 2011 23:00:52 -0000
@@ -671,6 +671,7 @@ function mollom_form_alter(&$form, &$for
+      $form += array('#submit' => array());
       array_unshift($form['#submit'], 'mollom_form_pre_submit');

For me it is clearer to write:

if (isset($form['#submit'])) { ...

sun’s picture

Status: Needs work » Needs review

Only conditionally prepending our submit handler would mean that it wouldn't be invoked when another submit handler is added to the form later.

TBH, I've no idea what or which module is building a form without specifying a submit handler (and also without an automatically detected FORMID_submit() handler by Form API). I can only guess that the module defining the form constructor is later trying to inject the actual submit handler through hook_form_alter()...

Anyway, the purpose of the submit handler being added in our code is to clean up the submitted form values before they are processed by any other form submit handler. Therefore, our handler should be added unconditionally, regardless of how other modules intend to submit their forms.

In turn, I think this patch is still RTBC.

neclimdul’s picture

I thought you needed to set the default submit handler when mangling #submit in D6 but looking at drupal_prepare_form again, #submit should be set before form_alter is called if the function exists.

I have to agree though that it seems weird that there isn't /something/ there. I wonder if a module is calling drupal_alter('form') in some weird workaround and causing this. cck's content_add_more_js looks to be a candidate for this.

sun’s picture

Thanks for the pointer, @neclimdul! However, content_add_more_js() cannot be the cause, since 1) it acts on the already prepared form retrieved from the form cache (i.e., #submit + hook_form_alter() are already done), and 2) if it was related to CCK, then we'd already have 300+ comments on this issue ;-)

Spent the past hours to double-check whether I'm able to reproduce this bug with Content Profile module, as @katy5289 mentioned. However, also no luck with that.

sun’s picture

Status: Needs review » Reviewed & tested by the community
StatusFileSize
new572 bytes

For some reason, this particular line already existed in mollom.module some time ago, but got removed for any reason. Just noticed that when I updated an older version of Mollom module on another site. git's pickaxe tool didn't yield the commit that removed it.

In any case, the explanation in #6 is hopefully sufficient to bring it back.

#674692: Node module integration tests might have led to a conflict, so attaching a safety re-roll.

Status: Reviewed & tested by the community » Needs work

The last submitted patch, mollom.form-submit.9.patch, failed testing.

sun’s picture

Created a Drupal core issue to fix the cause: #1162022: Make #validate and #submit keys reliable in drupal_prepare_form()

The test failures are unrelated to this patch. Looks like the backend might have some issues with testing mode. Will investigate tomorrow.

sun’s picture

Status: Needs work » Needs review

#9: mollom.form-submit.9.patch queued for re-testing.

sun’s picture

Status: Needs review » Reviewed & tested by the community
neclimdul’s picture

I've had tests randomly fail for mollom as well in the past couple days. Looks good to me though.

dries’s picture

This can be committed. @sun: go for it! :)

sun’s picture

Status: Reviewed & tested by the community » Fixed

Thanks for reporting, reviewing, and testing! Committed to all branches.

A new development snapshot will be available within the next 12 hours. This improvement will be available in the next official release.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

  • Commit 7455354 on master, fai6, 8.x-2.x, fbajs, actions by sun:
    Issue #1029852 by sun: Fixed PHP warning if protected form has no #...

  • Commit 7455354 on master, fai6, 8.x-2.x, fbajs, actions by sun:
    Issue #1029852 by sun: Fixed PHP warning if protected form has no #...