Merging Threads Technical Issue

[Cfleet1]

My bad it looks like it was because i was using a VPN.

[Cfleet1]

We are fine just moving the posts. Of course now i have another issue. lol When creating a new account i get this...


"Sorry, the registration has been disabled by administrator"


Ill just create a new thread for it in a little bit.

[Carrfixr]

I have my moderating promotion set at 4 posts. So if a new user makes one post with some pics they are moved up.

[Carrfixr]

And pictures add to a post count. So one reply with 4 pictures increases that single post by 5

[In Omnibus]

I copied a thread yesterday to another forum. The user had 6 post counts. Then I deleted the copied thread after his item sold, and the post count went to one. He had one post after it was copied so that is why it went back to that. I had to artificially go in and change it back to six, since the original posting is still up

I know there are people who will disagree on this but I'd like to be able to hide post counts. People get way too hung up on how many posts they have and not nearly hung up enough on whether or not their posts are of any value to the community.

[Wayne Luke]

This would actually be a different issue in that copying a topic isn't increasing the user's posts. It isn't related to the structure of merged threads.

[Carrfixr]

I copied a thread yesterday to another forum. The user had 6 post counts. Then I deleted the copied thread after his item sold, and the post count went to one. He had one post after it was copied so that is why it went back to that. I had to artificially go in and change it back to six, since the original posting is still up

[Wayne Luke]

We're willing to change how things work if customers can articulate and agree on a new methodology. There is an open issue on this already. We simply don't have a better solution at this time.

[Carrfixr]

Okay I see.. That stops them from being duplicated, good tip. The reply's that turn into comments still get deleted, and then i'll move one reply at a time so they are not comments

[Wayne Luke]

Don't select the replies/comments to copy. Just select the parent and they will move with it. When you select them, you're telling the system to copy the parent and all the "replies" to it, plus all these selected "replies"

[Carrfixr]

Another hiccup is when copying a thread to another the replies that turn into comments double. Yes two of each. After copying we have to go back in and delete all the doubles that showed. Another reason to copy one at a time

[Carrfixr]

We merge threads for reasons not listed above. Important info gets grouped into technical threads in a sub forum. With each new addition into a group there is a link to the original thread, and a new heading made on the post . The users original thread is still intact and not touched, so nobody gets mad. Yes there are search and related topics available but this helps us immensely. Example:
Someone is looking for interior install info. We have a sub forum under Body related things and a tech thread for interiors. There may be 10 different threads merged into that interior thread. As mentioned with each new merging a title and link is provided.
This works for us and the folks love it. Since it is an option to use in VB5 it should work properly...
btw. I usually use the copy vs the merge. Copy still brings the threads together

If you want to prevent them from turning into comments just COPY each post one at a time

[In Omnibus]

Merging topics really is bad mojo all around and I would discourage it but some people still use it.

This is where I agree with both you and Mark. I would rather delete a duplicate topic and make the user post in the existing discussion than spend time and energy merging topics and having users argue that their topic wasn't the same as the one into which it was merged. But if there are functions and features in the software someone will use them.

[Wayne Luke]

Posts are mutable. They will be Topic Starters, Replies, and Comments depending on where they currently sit in the hierarchy. Three different views of exactly the same thing depending on the parent.

If a reply remains a reply, then its comments will remain comments. If a reply becomes a topic, its comments will always become replies. If a topic becomes a reply to another post, its replies become comments. worse, any comments to those replies will not be shown. The system will not show infinite layers in discussions. It was worse in vBulletin 4.X. Everything became a reply of the starter post in the topic it was merged into. Even if the reply had a time stamp earlier than the Starter. Though there were no comments to worry about.

Merging topics really is bad mojo all around and I would discourage it but some people still use it.

[In Omnibus]

In the database, there is no difference between a topic starter, reply, or comment. You will find no indication of these "levels" in the node table. Just their content type and their immediate parent. The only difference is who their immediate parent is. That determines how they are displayed. The system actually keeps track of all generations of nodes in the closure table including their ancestry and the depth below Home (node id: 1) they are.

When you merge two topics, you're changing the parent(s) of one or more of the merged posts. Likewise, if you split topics then you're changing the parent of the posts that get split out. If you split out a post with a dozen comments on it, those comments will be displayed as Replies. If you split a single comment to become a topic, it will become a topic with all the features of a topic starter.

When moving nodes they haven't changed. They just have new parents. It is a fairly complicated content management system used in thousands of different ways.

So, if I understand this correctly, a topic is a parent, a reply is a child of the topic, and a comment is a child of the reply. So, a comment should still be the child of the reply to which it was posted in every case. This makes perfect logical sense and yet still doesn't prevent replies from becoming comments.

Maybe there could be a field to manually enter the parent node ID in cases where oddities occur. Maybe the vast majority of customers keep comments enabled, in which case it's not a priority.