Mollom loses CCK form field data after submit.

morningtime - August 11, 2009 - 10:30
Project:Mollom
Version:6.x-1.9
Component:Code
Category:bug report
Priority:critical
Assigned:morningtime
Status:fixed
Description

An authenticated user updates a node with custom CCK fields. After submit, Mollom checks the post, but now for every CCK field I get the message:

An illegal choice has been detected. Please contact the site administrator.

Looking at the edit form now, I see that all CCK field have lost their values! E.g. a dropdown with 0, 5, 10, 15, 20, is now [] empty! Logically, the node form cannot be submitted if all data is lost. The error only occurs for CCK fields. Node body & title are not lost.

Temporary solution: disable Mollom checking for registered users.

But I have a complicated situation, I'll try to describe a clear as possible:

- User is Authenticated, with new user role: "Authenticated Plus"
- CCK fields have permissions set to each field with CCK permissions, i.e. some fields cannot be edited by user with role "Authenticated Plus"
- The node in question is created by the admin
- The user was grated Update Access through the Node Access module: http://drupal.org/project/nodeaccess

All of the above works, except when Mollom Permission "post with no checking" is ticked off for this role (checking posts with Mollom is on), then all CCK field data is lost after submit, and edit page shows the above error message for each CCK field. And like I said, the edit form now shows empty selects for each CCK select field. All data in-out for CCK is lost.

Additional info: Mollom logs to dblog and shows CCK field data as follows (this is a snippet, I have hudnreds of CCK field, this is 1:)

<div class="field field-type-text field-field-spelling-check">  <div class="field-label">Spelling Checker: &nbsp;</div>  <div class="field-items">  </div> </div>

As you can see, the div field-items is empty here already. This means that this CCK content is never even submitted to Mollom?

So there is even the possibility, Mollom is not the fault. But I really don't know where to look or how to test this...

#1

morningtime - August 11, 2009 - 10:36

By the way, Mollom recognized the post as Ham. So that should be alright.

#2

morningtime - August 11, 2009 - 11:51

I found out more:

- I can create a new node with all those CCK fields through mollom
- Then, I can NOT edit & save through Mollom: all CCK data is unavailable in function mollom_validate_analysis ($form_state still holds the CCK field names, e.g. field_logo, but does not hold their values).

Digging further...

#3

morningtime - August 11, 2009 - 15:22

I can now confirm, this only happens to CCK fields INSIDE a CCK Field Group. Removing the groups, error message dissappears. Still dont know whether this is Mollom or CCK. Could use help.

#4

morningtime - August 11, 2009 - 15:39
Assigned to:Anonymous» morningtime
Status:active» closed

Ahh ok guys, it was the fieldgroup.module from CCK after all. Gonna fix it over there.

#5

morningtime - August 11, 2009 - 16:29
Status:closed» needs work

Problem identified!

It's the order of the modules. Fieldgroup.module and Mollom are simple incompatible.

Mollom's weight in System Table = 0, Fielgroup's is 9. But Mollom must come after Fieldgroup to work! I set Mollom's weigh to 10, and voila! Everything working, now you can post fieldgroup fields through Mollom without the error from first message.

POSSIBLE PATCH - the experts need to decide on this.

CHANGE in mollom.install

/**
* Implementation of hook_install().
*/
function mollom_install() {
  drupal_install_schema('mollom');
}

TO

/**
* Implementation of hook_install().
*/
function mollom_install() {
  drupal_load('module', 'content');
  db_query("UPDATE {system} SET weight = 10 WHERE name = 'mollom'");
  drupal_install_schema('mollom');
}

#6

morningtime - August 13, 2009 - 13:48
Status:needs work» needs review

#7

Dries - August 15, 2009 - 17:58

Changing the weight could work, but the real question is why the weight matters and if Mollom still works as expected.

#8

Dave Reid - January 4, 2010 - 18:30

I can't duplicate this using the latest code.

#9

sun - January 4, 2010 - 21:46
Status:needs review» fixed

Exactly - this was one of the reasons why I had to rewrite the module's Form API integration (form validation functions were called during form processing).

 
 

Drupal is a registered trademark of Dries Buytaert.