Flatcomments

Introduction

Comment mover allows comments to be moved between entities, and to be repositioned within a comment thread, and conversion between entities and comments.

Flatcomments forces all comments to be posted directly under the parent entity, preventing comment threading.

These can sometimes be at odds with each other.

Behavior of Comment mover 2.x with Flatcomments

On Drupal 9+, Comment mover 2.x is designed to work with the Flatcomments module.

If Flatcomments is enabled, the Paste links will only be added to top level entities, ensuring that pasted comments will only be attached to the top level entity.

Also, if a pasted comment has child comments (typically, this would be because the comments were created before Flatcomments was installed), the child comments will all be pasted belonging to the parent entity.

This should prevent unexpected behavior that could have occurred with previous versions of the module.

Behavior of Comment mover 7.x-1.x and earlier with Flatcomments

Comment mover challenges

To new users, Comment Mover (CM) often seems to behave erratically. Grafted comments do not appear in their destination threads/topics where users expect. Work to improve usability of the module is underway, but CM’s current behavior is predictable and useful if you understand how it works.

A few key concepts

Given how Drupal forums work, how Flatcomments works and how Comment Mover works, a few concepts are important to understanding how to use these together.

Threading vs. threaded display

In Drupal forums, threading and threaded display are two different things. Threading occurs when comments are posted in reply to other comments. Threaded display occurs when the forum is configured to show replies to comments (children) below their parent comments (usually indented).

It is possible to set the forum display to flat and make all comments appear as though they are replies to the original post even though many of them are not. Threading may be occurring even though no threading is being displayed.

Since Drupal forum topics/threads may be threaded or flat, we will refer to them here as “forum topics” (or just “topics”) and the posts that begin them as “forum topic nodes” (or just “topic nodes”).

CIDs

Drupal assigns a comment ID number (CID) to every comment it creates. When threaded, comments are sorted by parent-child relationship then CID. When not threaded, they sort by CID.

Flatcomments

Flatcomments is another contributed module that makes all reply comments replies to the original post regardless of what reply link the user clicked. At present, it does not remove threading that has already occurred (does not convert existing comment replies into node replies). Flatcomments also doesn’t disable threading, per se. It simply changes the behavior of reply links so that “reply” always produces a reply to the original topic node.

Using Comment Mover and Flatcomments together

Since Comment Mover does not use the “reply” mechanism when it grafts, it is possible to create threading (intentionally or accidently) using CM even though Flatcomments module is enabled. Plus, if you have the forum display set to flat, the threading will not be visible. The results can be surprising if you graft a comment to another comment (creating a parent-child relationship), then later graft the parent comment to another location (unware that other comments are children to it).

Consequently, when using CM with Flatcomments, it’s best to avoid using the tool in a way that creates threading.
Two rules of thumb will help you do that. For the sake of simplicity, we’ll assume your forum has no threading (no comments that are replies to/children of other comments) or that you will only use CM on topics that have no threading. We’ll also assume sorting is set to oldest first.

1. Always graft to the node
Most unwanted threading can be avoided by always selecting the graft link on a the destination topic/thread node rather than any of the comments that may be in it.
A fairly simple CSS tweak can help here by hiding the graft link on all comments. The following works in Garland and my Zen Classic based theme. You will need to adjust the selector for your own situation (Firebug helps!).
ul.links .comment_mover_comment_graft {display: none;}

2. Always move comments individually
This may sound difficult, and may be uncessary in future releases of CM, but if you want to keep your forum free of threading-related confusion, it’s necessary.

Why? Rule of thumb one will prevent threading when you graft a commentless topic node or single comment. But it will not do that if you graft a topic node that has comments. The reason is that CM will turn the grafted node into a comment and turn its comments into children comments.

In other words, though it may appear otherwise...
Topic post A
     Comment 1 (CID 100)
     Comment 2 (CID 101)
becomes...
Destination topic
     Comment A (CID 102)
          Child comment 1 (CID 100)
          Child comment 2 (CID 101)

To make things even more interesting, CM retains the CIDs on the original comments, but must assign a new CID for Topic post A when it becomes Comment A. So, if your display is set to flat, the result looks like this:

Destination topic
Child comment 1 (CID 100)
Child comment 2 (CID 101)
Comment A (CID 102)

If you want the final result to sort sensibly but still keep your forum threading-free, that means you will have to move comments one by one.

How to make the result look like this...
Destination topic
Comment A
Child comment 1
Child comment 2

1. Create a new comment in the destination forum topic. Paste in the text from the original topic node.
2. Graft the original comments to the destination topic node, one by one, in the desired order (they will receive new CIDs in sequence and sort by them).
3. Do whatever cleanup you would like in the original topic.