comments in inverted order when converted from core

That's because it changes the updated time on them when it converts them. I could have sworn I had an issue in the queue about that but can't find it now... NC really need to leave the updated timestamp and node_comment_statistics alone when converting otherwise all the forum posts show up as unread after conversion.

Michelle

Do you use the view provided with the module ? What is the display mode of comments ?

@erica i dont particularly see any issue with setting the sort criteria, based on how this module appears to work in that it renders the comments using an actual view, this should totally be ok.

i can confirm that the default view does indeed lack a sort criteria setting which may render an output not matching the comment settings specified. i also found that simply adding a sort criteria made it act as i had it set prior to conversion. not sure if you can detect and set the views sort criteria via module based on the comment settings for essentially the sort criteria without views, but that likely wouldnt work very well for a cloned version of the nodecomments view (like the one that im using) or would it?

anyways just a confirmation and idea :)

I also put a "Node: Post date asc" on the nodecomment view, which seemed to fix everything.

I have some sort order issues, though different to those posted about above.

It seems that, on conversion, my comments did not remain as replies to the main post (i.e the 'flat comments existing' conversion seems to have been lost). The Node IDs created by nodecomment do not reflect the post date order (some older comments have higher Node IDs).

If i change comment settings on the forum topic content type to threaded list, comments to comments (they should be comments to the original post) are displayed indented and there is some semblance of order.

I am not sure of how to resolve this. Is it possible to convert node comments back to drupal comments? I could then retry the 'flat comment existing' conversion and 'node comment' conversion. Alternatively, is there a way to convert comments on comments to comments to the forum topic node?

This is on a live forum site, in beta (these issues were not noted until after the live site was converted — they were missed in the testing phase on a local install, which complicates this a little). Unfortunately, the thread I am working with is not publicly visible (I am testing modifications on a local install). The site is www.r3gs.net.

I would appreciate any suggestions or advice on how to resolve this.

I don't have an answer for you but I would caution against trying to convert back to comments. I tried it on my dev site because I need a test site with comments instead of nodecomments and it made such a mess that I ended up deleting everything and regenerating as comments.

Michelle

Thank you for the very prompt reply Michelle (and all the work you put into Advanced forum — the site referred to is using AF 6.x-2.0-alpha3).

I will see what I can achieve with comment mover on the local install (test site).

I've the same problem when converting existing Core-Comments to Nodecomments.
Is it the intention to set the changed date to "conversion time"?
After converting my Forum (DEV) to Nodecomments all replies are in the wrong order.
The first comment (some years old) of every forum is now the latest!

In fact the the timestamp at the new node and the one in "last_comment_timestamp" is set to the time when the comment gets converted to a node via batch.

I've tested the beta and dev snapshot and both are doing the same. (Drupal 6.19)

Sven

"Node: Post date asc" on the nodecomment view helped me too!

I needed to convert from SMF forums through PHPbb to Advanced Forum. I ran into the problem of the order of replies being reversed as to what they were set to in the content types. For my situation I solved the problem by changing two lines (203 and 209) in "nodecomment.convert.inc". At the end of the SQL command (not the ORDER BY) change the DESC to ASC. This was a quick guess so I do not know if it works in all situations.

This is one of consequences of using node_save(). Whether it was good idea to use that is debatable. I can see both pros and cons of this approach.
What we can do is just restore timestamps after calling node_save() or switch to using direct database queries, if it's better.

2.x is unlikely to get any support at this point. Closing all related issues.