XF 2.2 Forum and thread types

1596357716555.webp
Forums contain threads and threads contain posts. It's been the essential framework of forums on the Internet since the public migrated from usenet to the web.

The structure is well known and well understood - though the origins of some of the terminology are lost in the mists of time. Who ever came up with the notion of your site being a forum, but these separate containers for related threads also being forums? 🤷🏼‍♂️

But back on topic, and we all know that visiting a forum (the second type) will usually show a list of threads ordered with the most recently updated near the top, and that clicking on any of those threads will show a page with the oldest post first and newer posts underneath and on subsequent pages.

Bending discussion forums to varying purposes

Over the years, forum administrators have been inventive and used the simple messages-in-named-containers structure of forums to build all sorts of content - let's look at the XenForo community as an example.

First, we have announcements and these "Have you seen" threads. These are quite focused on the initial post (or first few posts in some HYS threads), with these posts containing a lot of information... a bit like an article with subsequent comments.

Then we have the suggestions forums, where we ask people to up-vote the ideas they're interested in.

There are also support forums where people are looking for answers to questions or solutions to problems.

And of course there are also forums for general chat and discussions, which most closely fit the original notion of a discussion thread and where you can't really say the threads fit the same model as the other types.

Up until now, these forums and the threads within have all been displayed the same way.

But not any more

With XenForo 2.2, we are introducing the concept of Forum and thread types. This is a massive change with enormous ramifications for forums. Today, we're only really going to talk about the admin and user experience of the new systems, but in a few days we're going to follow up with a developer-focused HYS where we will talk about what's going on behind the scenes here, because we're really rather excited about the potential it unlocks.

There is a lot to talk about, but let's just dive into some examples...

tl;dr

We're prefer you to read all the details below, but if you just want the juicy bits:
To view this content we will need your consent to set third party cookies.
For more detailed information, see our cookies page.
 
Last edited by a moderator:
Especially since on top of no alerts, you can’t see a list of who upvoted/downvoted like you can reactions.
This is needed because even with 2.1 using with reactions, you often read positive posts about your suggestion but they did't give a like to the OP. In this case a gentle nudge explaining how it works can be helpful but you cann't do that if you don't know they didn't vote.

Same with voting. People often don't know about the voting as it isn't that obvious (yes I have a suggestion about that) and I have noticed a couple of suggestions where the reactions outnumbered the votes which shouldn't really be the case. If people like they should vote.

Or maybe there is an in between of liking but not linking enough to vote.
 
There is an in between reactions and votes. It is a step backwards to,
1) Not get alerts to votes.
2) Not be able to see who voted.

Seems like a half baked system just throw together.
 
There is now a framework to have different thread types and a framework to aid in the implementation of thread and/or post voting.
Yes, but only within the very narrow scope of Suggestions Thread types. That was 25% of the request.

The suggestion specifically asked to implement thread ratings for:
  1. Suggestion Threads (Implemented)
  2. Discussion Threads (Not Implemented)
  3. Articles (Not Implemented)
  4. everything else (Not Implemented)
75% was not implemented. That in my view is a very low level of implementation.
So that is worth a new suggestion but as it stands at the moment the original suggestion is implemented at a high level.
I don't see the point if its bound to be marked implemented without the core request being addressed. The suggestion has been posted multiple times before.

It would be nice if a better way could be found to address partially implemented suggestions. Its a little demotivating.
Its similar to the API suggestion which asked for Single Sign On and attracted an extreme number of votes. It was by far the most popular suggestion,. API got implemented (which was awesome), but a long discussion thread with a mass of votes got thrashcanned. Which lead to me reposting the suggestion for SSO and including caveats so that it includes member sync. Which is now again by far the most popular suggestion. (over 200 votes for a new suggestion)

There also have been suggestions which were all marked duplicates or merged. Then marked implemented. In hindsight the other threads could at least have been kept open. Its a recurring issue.

Could you please discuss internally if there is any way that you can improve the way similar suggestions and partially implemented suggestions are handled?
Also tagging @Gemma Eastwood here.
 
To the best of my knowledge, the guide on using the Suggestion forum has always stated very clearly:
Finally, please keep to one suggestion per thread. This allows us to more accurately gauge the response. Massive rollup threads don't help us know the specific ideas that people are interested in.
Nothing has changed. Making a monolithic suggestion that encompasses multiple ideas are never going to be fully implemented in the way that everyone envisaged.

But as you noted, in the situation where this has happened before, was there any reason to be "demotivated"? We implemented the core part of the suggestion and we - quite rightly - marked it as implemented and the other part was created as a new suggestion and it also received support.

So, to reply directly to one of your comments, that's the point of making a further suggestion, and I don't see an issue with that.

It also gives you the opportunity to rationalise and flesh out the ideas in more detail, especially now you've seen the context of our implementation.

This will, no doubt, be multiple suggestions - one for each new thread type - rather than, again, a single suggestion for all use cases.
 
Is possible to configure via permissions which users can open Article threads? Because i want the feature to be accessible only to certain user groups, kinda like prefixes can.
 
Assuming that you want an article forum then you would just change the permissions on that forum to prevent the ability to create a thread, as desired.

No i want a normal forum, and users can create "normal" threads and only "Helpers" can create Articles for example.
 
No, there aren't permissions over types within a general discussion forum.
Sad, i asked because prefixes can be bound to permissions, eventually this will be considered as a possible feature? I think having more flexibility isn't a bad thing. Thanks for the quick reply.
 
As posted by @Chris D in this thread:
We converted likes to upvotes
Can this be done for customer forums, too? Is this toggleable? Or a custom task? :) Will it be possible to convert "dislikes" to "downvotes", too?

And, for the record: I'd too like to see alert capabilities for up-/downvotes (and "X selected your post in thread Y as the solution"), and a list of who voted (ThemeHouse QA Forums got this).
 
Last edited:
Just to clarify:

The "Convert reactions to votes" process which is exclusively a Suggestion forum type feature does convert negative reactions to downvotes. Neutral reactions don't adjust the vote score in either direction.
 
The "Convert reactions to votes" process which is exclusively a Suggestion forum type feature does convert negative reactions to downvotes
Awesome, that's all that I need and hoped for :) Thanks!

Another question comes up, then: Will it remove the reactions once they're converted?
 
Back
Top Bottom