I'm using a new test CSV field. The feed element mapper has no problem showing an example feed item from the csv file, so it sems to be connected.

My problem is that when I assign some columns to cck fields and I try to save the form, nothing gets saved!

The value are all resetted back to "No Mapping" and I really don't know what's going on.

I have no error on screen, or in the logs... If I still refresh the feed, I get the nodes created with the right titles, but I don't have any mapped data.

This seems like an issue with the mapper, it seems that it does not save the mappins I want to add!!

Thanks for any help you could provide!

Patchak

Comments

patchak’s picture

patchak commented

errr.. it's not a new CSV field, but a CSV file...

alex_b’s picture

alex_b commented
Status: Active » Postponed (maintainer needs more info)

1) Does this problem occur only with this feed or with any feed?

2) Go to _feedapi_mapper_store_mapping() and print $param, $mapping, $elements to screen - do the values seem to be correct?

3) If they are, can you verify that they are being written to the database? (db_query() code is in the same function - _feedapi_mapper_store_mapping())

patchak’s picture

patchak commented

Alex : thanks for the reply... turns out I can't use a file with the column names wrapped in double quotes. Removing all the quotes from the column names sem to actually solve the problem.

Patchak

jesss’s picture

jesss commented

I'm running into a similar issue. I have a very simple CSV file that has two columns: first_name and last_name. I'm trying to map those two columns to two CCK text fields: field_first_name and field_last_name. However, only the first element is mapped.

Alex, I made the modification to _feedapi_mapper_store_mapping() that you suggested, and here is the result.

Param: 254
Mapping:

Array
(
    [title] => 0
    [description] => 0
    [options->timestamp] => 0
    [options->guid] => 0
    [options->raw->first_name] => a:2:{i:0;s:7:"content";i:1;s:16:"field_first_name";}
    [options->raw->last_name
] => 
    [options->raw] => 0
    [options] => 0
)


Elements:

Array
(
    [title] => a:1:{i:0;s:5:"title";}
    [description] => a:1:{i:0;s:11:"description";}
    [options->timestamp] => a:2:{i:0;s:7:"options";i:1;s:9:"timestamp";}
    [options->guid] => a:2:{i:0;s:7:"options";i:1;s:4:"guid";}
    [options->raw->first_name] => a:3:{i:0;s:7:"options";i:1;s:3:"raw";i:2;s:10:"first_name";}
    [options->raw->last_name
] => a:3:{i:0;s:7:"options";i:1;s:3:"raw";i:2;s:10:"last_name
";}
    [options->raw] => a:2:{i:0;s:7:"options";i:1;s:3:"raw";}
    [options] => a:1:{i:0;s:7:"options";}
)

I'm thinking those weird line breaks in the middle of the last_name part of the mapping and element arrays are the most likely culprits, but I don't know where they're sneaking in. I've double- and triple-checked the CSV and don't see any strange characters or line breaks. It also doesn't matter which order the columns are in -- whichever column is second exhibits this behavior.

todddevice’s picture

todddevice commented

I was able to solve this by changing the line break encoding in the CSV file.

parser_csv.inc looks for ASCII character 10, or UNIX-style LF:

function _parser_csv_parse_csv($csv_string, $feed) {
  $lines = explode(chr(10), $csv_string);

The CSV in question was created in Windows, which encoded CR+LF line breaks. Hence the broken new line as the CR was preserved as part of the header.

Any additional check for the presence of CR+LF breaks in the parser_csv module is needed.

alex_b’s picture

alex_b commented

#5 suggests this is a parser issue. Does this problem persist in 6.x-dev which has an entirely different parser?