Problem/Motivation
Currently, FeedsCommentProcessor.inc does not include a mapping target for the comment cid. I am in a situation that requires importing comments from another Drupal installation and preserving the comment thread structure. There is a mapping target for the comment parent (pid) but this is useless without also importing the comment cid.
I tried merely adding a mapper for cid, but that prevents any comments from being created because comment_save() assumes if the $comment object has the cid set that it is updating a record, not inserting one. It also does not populate the thread column in the comment table and loses the thread hierarchy structure.
Proposed resolution
This is not a perfect solution and is more of a work-around, proceed only if you know what you are doing.
I will attach my patch that adds a mapper for cid and thread. It also changes the entitySave() function to insert a comment record in the db table with the cid (in order to preserve the cid, as opposed to setting the cid based on the auto_increment).
Because the Drupal uses the auto_increment for the comment database table, I had set this auto_increment value to greater than any imported comments to avoid conflicts when comments are manually added after the import. I executed the following mysql statement: (replace 9999 with max + 1 of your imported comment cids)
ALTER TABLE `comment` AUTO_INCREMENT = 9999;
This requires your source has the thread data (column on the comments db table that is used to store the thread structure in van string format). In my case, I have a D6 site dumping the contents out with a view, in order to get the thread data I had to use the views_customfield module and used a customPHPfield to get this data:
<?php
$result = db_query("SELECT * FROM {comments} WHERE cid=%d", $data->cid);
$row = db_fetch_array($result);
print $row['thread']
?>
Remaining tasks
This is merely for discussion, it'd be a much more ambitious undertaking to try to preserve cid and thread structure without my work-around importing the thread data.
User interface changes
This adds mapping targets to the Comment Processor
| Comment | File | Size | Author |
|---|---|---|---|
| #13 | feeds_comment_processor-import-cid-1379286-13.patch | 7.27 KB | twistor |
| #11 | feeds_comment_processor-import_comment_cid_and_threading-1379286-11.patch | 1.75 KB | dooug |
Comments
Comment #1
dooug commentedComment #2
danepowell commentedI appreciate your work on this- I know that Feeds Node Processor (FNP) recently added the ability to set the Node ID: #1046916: Importing nodes with their original NID fails because of ambiguity in node_save() in FeedsNodeProcessor
Since FCP is copied almost verbatim from FNP, we should probably use the same strategy- can you please look at that issue and try to copy their technique if possible? (Maybe your patch already does this, I haven't checked)
Comment #3
dooug commentedThe FNP patch utilizes the
$node->is_newflag innode_save(). However,comment_save()is very different fromnode_save()in how it determines if it is a new node or not.If
$comment->cidis set, it will attempt to update an existing record. So, my strategy was to manually insert a comment record with thecidbefore thecomment_save()is called in order to preserve thecid. This is a work-around to avoid hacking the comment.module.Like I said above, I am not sure there is a "good" solution to this. As I see it, we'd either have to hack core comment.module or do some direct db inserts (as in my patch).
Comment #4
tgeller commentedThanks for your work on this!
I installed the patch and am afraid I couldn't get it to work in my situation, though. I'm importing a set of posts and comments from a non-Drupal site (LiveJournal). Each comment has (a) the post (node) it's associated with; (b) a unique ID, and (c) the parent ID (referring to the CID).
If only I could map the unique ID to CID, then the parent IDs still work and threading would come out just fine. Devel reports that the CIDs are coming in just fine (e.g. based on the imported data).
But when the import's done, either
1) the CIDs are high sequential numbers, or
2) the comments didn't actually get imported, despite FCP reporting that they did.
Any ideas?
Comment #5
tgeller commentedI might have found a quirk.
The first time I imported comments, threading worked. I then deleted them (via the Feeds Import page at /import) and re-imported: The threads were broken.
I'm still working on it, and will report back if I figure it out.
Comment #6
tgeller commentedNever mind: This is obvious. It works the first time because the CID happens to match my source's -- both start at 1 the first time I import. *sigh*
Comment #7
danepowell commentedThis issue will need to be solved in conjunction with #1298282: Allow updating of comments that weren't imported with feeds_comment_processor
Comment #7.0
danepowell commentedCorrected error in SQL statement that prevented it from running correctly.
Comment #8
raj45 commentedI just tested the patch, and it works just fine. Now all I need is to find a way of converting the threaded structure of Plone comments to Drupal thread format :-) (fx "02.00.00/")
Comment #9
dooug commentedComment #11
dooug commentedRe-rolled patch.
Comment #12
dooug commentedComment #13
twistor commentedComment #15
twistor commented