Checking CCK nodes with drop down lists lead to SAX 0x0 parsing error
Benjamin Schrauwen - July 2, 2008 - 09:09
| Project: | Mollom |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Jump to:
Description
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:
</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.
#1
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.#2
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).
#3
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.
#4
Just created a mollom account so that I can investigate :-)
#5
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.
#6
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: </div>
<div class="field-items">
<div class="field-item">choice a</div>
<div class="field-item">choice b</div>
</div>
</div>