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

Comments

dooug’s picture

danepowell’s picture

I 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)

dooug’s picture

The FNP patch utilizes the $node->is_new flag in node_save(). However, comment_save() is very different from node_save() in how it determines if it is a new node or not.

If $comment->cid is set, it will attempt to update an existing record. So, my strategy was to manually insert a comment record with the cid before the comment_save() is called in order to preserve the cid. 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).

tgeller’s picture

Thanks 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?

tgeller’s picture

I 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.

tgeller’s picture

Never 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*

danepowell’s picture

danepowell’s picture

Issue summary: View changes

Corrected error in SQL statement that prevented it from running correctly.

raj45’s picture

I 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/")

dooug’s picture

Status: Active » Needs review

Status: Needs review » Needs work

The last submitted patch, 1: CommentProcessorCidThreading-1379286-1.patch, failed testing.

dooug’s picture

StatusFileSize
new1.75 KB

Re-rolled patch.

dooug’s picture

Status: Needs work » Needs review
twistor’s picture

  • twistor committed c18f4dd on 7.x-1.x
    Issue #1379286 by dooug, twistor: Import comment cid and thread...
twistor’s picture

Status: Needs review » Fixed

Status: Fixed » Closed (fixed)

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