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
| Comment | File | Size | Author |
|---|---|---|---|
| #9 | mollom.form-submit.9.patch | 572 bytes | sun |
| #2 | mollom-DRUPAL-6--1.warning.2.patch | 770 bytes | sun |
Comments
Comment #1
katy5289 commentedI 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
Comment #2
sunThe 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.
Comment #3
sunNeed to double-check this patch against drupal_prepare_form() in D6
Comment #4
sunBetter 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.
Comment #5
dries commentedFor me it is clearer to write:
if (isset($form['#submit'])) { ...Comment #6
sunOnly 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.
Comment #7
neclimdulI 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.
Comment #8
sunThanks 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.
Comment #9
sunFor 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.
Comment #11
sunCreated 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.
Comment #12
sun#9: mollom.form-submit.9.patch queued for re-testing.
Comment #13
sunComment #14
neclimdulI've had tests randomly fail for mollom as well in the past couple days. Looks good to me though.
Comment #15
dries commentedThis can be committed. @sun: go for it! :)
Comment #16
sunThanks 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.