When a custom CCK node is send to Mollom which contains drop down lists, this results in a SAX parsing error because 0x0 was found in the content. After study of the log files here is an example of what is send to Mollom:

<div class="field field-type-text field-field-work-type">
  <div class="field-items">
    <div class="field-item">
      <div class="field-label-inline">
        Work type:&nbsp;
      </div>
      NULL
    </div>
  </div>
</div>

Where NULL is really the ASCII symbol 0x0, which leads to an error in the SAX parser. Note that the content was also HTML encoded.

This behavior is found for any drop down list, if multiple lists are present in the CCK node, multiple 0x0's are generated.

Comments

dries’s picture

dries commented

Odd. Here is the code in the Mollom module that I use to prepare the data:

  // Render the node so that all visible fields are prepared and
  // concatenated:
  $data = node_build_content((object)$form_state, FALSE, FALSE);
  $content = drupal_render($data->content);

Next, $content is encoded into an XML-RPC payload by xmlrpc.inc.

karens’s picture

karens commented

Is it OK if I move this back to the CCK issue queue to work on?

Looking at the CCK code this should never happen, so it's very odd. The preprocessor is checking for empty items before they get to the .tpl that creates this code, and if the item is empty it is not printed.

Do you have any examples of a field set up that produced this output that I can use to replicate the situation? (The type of field and widget and its allowed values list, etc).

karens’s picture

karens commented

One thing to rule out before going much further -- if that output was created in Drupal 6.2 using a copy of the content-field.tpl placed into a theme folder, it could be the core bug at http://drupal.org/node/241570. That bug causes the work done in the preprocessor to be lost, and it would probably produce output that looks like this. That bug is fixed in -dev and the fix will be in Drupal 6.3.

yched’s picture

yched commented

Just created a mollom account so that I can investigate :-)

dries’s picture

dries commented

KarenS, yched: thanks for the help. Much appreciated. I've started to look into #241570: Theme preprocess functions do not get retained when using patterns as well and left a quick follow-up comment to bridge both issues.

yched’s picture

yched commented

FWIW, I can't reproduce with latest CCK D6-dev, even when using a copy of content-field.tpl.php in the theme folder.
For a text field with options (or any other field type), I get the expected HTML.

<div class="field field-type-text field-field-options">
  <div class="field-label">field_options:&nbsp;</div>
  <div class="field-items">
    <div class="field-item">choice a</div>
    <div class="field-item">choice b</div>
  </div>
</div>
dave reid’s picture

dave reid
he/him
Primary language English
Location Nebraska USA
commented
Status: Active » Fixed

No follow-up in over a year and we'll be changing to field value concatentation instead of building and rendering the node. See #245682: Enable use of Mollom for any form and #412760: User interface brainstorming. Marking as fixed.

Status: Fixed » Closed (fixed)

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

dries’s picture

dries commented

See also #542524: Mollom was unavailable (error: 1000 - XMLRPC parse problem....