The 2 options for the Fallback strategy are "Block all submissions" and "Leave all forms unprotected".
In the admin-settings, this is defined as
$form['server']['mollom_fallback'] = array(
'#type' => 'radios',
'#title' => t('Fallback strategy'),
'#default_value' => variable_get('mollom_fallback', MOLLOM_STATUS_BLOCK), // we default to treating everything as inappropriate
'#options' => array(
MOLLOM_STATUS_BLOCK => t('Block all submissions on the protected forms until the server problems are resolved'),
MOLLOM_STATUS_ACCEPT => t('Leave all forms unprotected and accept all submissions')
...
but the defined variables are
define('MOLLOM_FALLBACK_BLOCK' , 0);
define('MOLLOM_FALLBACK_ACCEPT', 1);
MOLLOM_STATUS_BLOCK <> MOLLOM_FALLBACK_BLOCK
MOLLOM_STATUS_ACCEPT <> MOLLOM_FALLBACK_ACCEPT
The patch in attachment (next post) renames both constant variables in the admin settings form to MOLLOM_FALLBACK_BLOCK and MOLLOM_FALLBACK_ACCEPT
Remark: Since this patch does not delete the already saved variable 'mollom_fallback', the user needs to resubmit the admin settings form in order to save the mollom_fallback variable correctly.
In {variables} you will find:
mollom_fallback s:20:"MOLLOM_STATUS_ACCEPT";
(or "MOLLOM_STATUS_BLOCK")
After submitting the admin form, this will become:
mollom_fallback s:1:"1";
(or "0")
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | 248869_mollom_fallbackstrategy.patch | 1.44 KB | Jo Wouters |
Comments
Comment #1
Jo Wouters commentedPatch attached
Comment #2
dries commentedGreat, thanks Jo. I'm going to (try and) write a test for this bug in the train tomorrow, and then I'll commit it with the bugfix. Good catch.
Comment #3
Jo Wouters commentedHow are we going to force the user to resubmit the admin settings form ?
Or should we write a mollom_update_N() to convert the incurrectly stored variable to the new one ?
Comment #4
dries commentedI've committed your patch to DRUPAL-5. The problem doesn't seem to exist in DRUPAL-6. I don't think it is necessary to provide an update function. The default behavior should protect them. I'll add a note to the release notes when I roll a new version.
Comment #5
dries commentedI've also added a first set of tests to the drupal.org CVS repository that test this behavior in Drupal 6: see http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/mollom/?pat.... There are two tests that validate the fallback behavior on Drupal 6.
(For now, I'm writing tests for Drupal 6 only.)
Comment #6
dries commentedThis was fixed as per the comment above.
Comment #7
Anonymous (not verified) commentedAutomatically closed -- issue fixed for two weeks with no activity.