Critical features missing from core forums?

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
webchick's picture

As a point of discussion, what would everyone say are the bare minimum features that core forums need to implement in order to be, if not a viable competitor to PHPBB and the like, at least be usable for most forums?

This is my list, all of which I intend to work on but would of course appreciate any help. :)

  • Fix signatures: actively working on this. See The signatures debacle
  • Private forums: I think that getting Forum access module in core would be a huge help. Not sure if I have the chops to pull this one off, but I'm going to try...
  • Forum moderators: The ability to assign roles or users as forum moderators. Forum access takes care of this, too.
  • Better theming: Forums by default look just like blogs or stories. We should make core's default output for forums similar to that of Flatforum.

Some things that specifically aren't on this list:

  • Smileys: Want 'em? Install the contrib module.
  • BBCode: What it? Install the contrib module.
  • User points: Want this? install a contrib module.

You get the idea. ;)

Remember: anything that gets into core has to satisfy the "90% case", as in "90% of all sites are going to want functionality X, so it makes sense to make core more complex in this way."

So what is your super-pared-down vision of what should go into Drupal core's forums?

Comments

The things I can think

ggilbert's picture

The things I can think of:

  1. If comments are being made in flat mode, you can't tell which children are going to be deleted when you delete a comment. It would be great if those children were reparented to the parent of the deleted node.
  2. Post ordering seems to change when a comment author updates that comment. This might make sense in a comments module, but in the case of a forum it throws off the flow of the conversation.

The way forums are made in Drupal

GoustiFruit's picture

The way forums are made in Drupal is more the way newsgroups work (threads).
The way most webforums work is different, they usually are "flat" and you post replies to the first message. Even webforums that allow threading are 99.9% of the time configured to display in flat mode.

For me:

  1. Comments should be treated as replies to the first post. So deleting one comment won't need reparenting children.

  2. So there should be no "reply" link on comments but only a global reply link. On comments there could be a "Quote" link if the Quote module is present.

  3. A "quick reply" textbox would be welcome :-)

What I was thinking though

ggilbert's picture

What I was thinking though is that an admin is able to allow the user to switch between flat and nested. If in flat mode you force the user to repy to the first post ( the node), then the user who has switched to nested mode will see comments appearing outside the normal flow. Which is why I was suggesting reparenting the comments. Like this:

0
1
2
  3
  4
5
6   

Would become the following when you deleted 2:

0
1
3
4
5
6   

This would hopefully preserve as must conversation flow as possible for the people using of nested mode, while providing the desired behavior in flat mode.

That's what I understood

GoustiFruit's picture

That's what I understood but I think that when you delete one "message", all children should be deleted too. I'm using the term message because I think that's the way it works in email clients and webmails. At least it should ;-) Because when you delete a message, replies to that message don't mean anything when reattached to a higher parent.

webchick's picture

That way you could retain hierarchical comments on blog entries if you wanted, but make forums "flat."

This is an option that I

Gman's picture

This is an option that I like. But don't we let the 'user' decide how to display the threads at time (depending on the configuration). But I guess we could override this for these particular content types.

I also agree that Flatforum type theming should be enabled for forums (or just take out the hard coded stuff from the forum module).

From comment #10030, since splitting/merging threads is a rather common moderator activity in forums.

I was talking with merlin briefly at the OSCMS and he would said a few things that I really agree with. 1) To see forums removed from the taxonomy system and structured a new/different way. 2) To see ANY node type available to forums (like polls, a CCK type or anything else).

Since polls are really something that is a basic element to all forums (without the need for special/sitewide permissions).

I am probably branching off into what I would like to see the forums module become, but this is a good place as any .:)

I don't think

merlinofchaos's picture

I don't think forum-container-nodes are viable for core.

Selectable node types in a forum, however, should be relatively easy to do.

http://drupal.org/node/8137

catch's picture
  1. http://drupal.org/node/81373 - Heine's already done the flatcomments module, would be good to have that as a core option.

  2. There's also an issue in the tracker about the comment timestamp thing - this only affects forums with a flat comments layout, so is related to 1. http://drupal.org/node/55277, and yeah, it's really irritating. flatcomments has been working for us for a while.

Would be great to have options in comment mover like:
* split the selected comments (with multiple select checkboxes)
* split all comments after the selected one

  • but they'd only work with a truly flat comment structure, so fixing those bugs would be a prerequisite to any functionality like that.

I think you've got a good

Toe's picture

I think you've got a good list of the most critical, need ASAP features there. The only one I think I'd add is thread splitting/merging, currently requiring the comment mover module. I'd also add a couple must-fix bugs, like this oldie.

For the long term (ie after the critical stuff is taken care of), I think a better way of stating the question would be, "What features should be in the core forum module, and what should be in other modules, core or otherwise?"

For example, polls in forums. Do you call this a feature for the poll module or the forum module? And of course there's also the forum module's relationship to the comments module. I still wonder if we even really need a separate forum module. Could we move most of the forum features to the comments module, and have the forum itself be a theme + Views preset? I mean, do we really need a distinct forum node type, or can we just use a generic story node and use a poll (or any other) node as needed? The forum and topic lists are really just a fancy way of showing what's in a vocabulary, and isn't that what Views is supposed to specialize in?

There's also some features that to me are so small that it seems silly to require that they be a whole separate module. For example, 'dotted' topic icons (a visual indication in the topic list of threads that you've posted in). It's a usability enhancement that most forums have, but it's such a small feature that needing another module for it seems like overkill. It might also be worth looking to see if there's any contrib modules that could be merged together with each other (as opposed to merged into core).

It would be interesting...

webchick's picture

...if someone took Dries's idea of turning book.module into 'outline' module and ran with it (see http://buytaert.net/suggestions-for-drupal-core). This would make it so that forums indeed were just a type of outline with special theming. We can't do this:

Could we move most of the forum features to the comments module, and have the forum itself be a theme + Views preset?

...because Views isn't part of core (and probably won't ever be in its current state, although Dries has said that he is supportive of having some kind of 'query building' functionality in core).

But making outlines generic would allow us to place polls, or 'job listings' or, or 'reviews' or anything else we wanted to in a forum (or in a book, or in a menu, or....)

But making outlines generic

Toe's picture

But making outlines generic would allow us to place polls, or 'job listings' or, or 'reviews' or anything else we wanted to in a forum (or in a book, or in a menu, or....)

Well, hop to it then! ;-)

lol I have my hands full. ;)

webchick's picture

Baby steps. :P I want to solve some of the fundamental stuff first, and then branch out.

But if someone wants to take a stab at this, Peter Wolanin has done a great job writing up a spec here: http://drupal.org/node/128731 .. none of our SoC applicants applied for it, so it's up for grabs.

Two Forum Access Enhancements for Core

BenK's picture

Hey there webchick,

It was fun meeting you briefly at the OSCMS Summit! I agree that getting some form of Forum Access in core would be huge. However, the current state of the Forum Access module is missing a couple key features for core:

  • The ability to separate "view" permissions from "post" permissions for a given forum.

For instance, once you use Forum Access to grant a user the ability to view a forum, that user also has the right to post comments in that forum (even if you would like the specific forum to be read-only).

  • The ability to approve comments before posting for certain forums, but not for other ones.

If you have a particular forum that you would like more control over (say it's a more sensitive subject), Forum Access does not allow you to require that comments to the specific forum must first be approved by a moderator before it is posted.

By the way, I remember reading a few weeks back that Earl was looking for a co-maintainer for the Forum Access module. I know you probably have a ton of work at the moment, but you seem like the perfect person for this!

Differences between comments and forum topic

ggilbert's picture

I'm not sure this is really a 90% feature, but one remaining issue I have is that the first post in a forum is a node, while all of the responses are comments. It's an extremely clever reuse of technology to simplify the module, but it seems to complicate things a bit. The interface for editing the first post is a bit different from editing replies. By default the first post appears at the top of each page of the thread. From the point of view of extending my site, I've noticed that it can be a pain to add on custom features because the first post is stored differently from all of the others.

Would it make sense to remove the body text from the Forum topic node and store the first post as a comment on the node just like all of the other posts?

By the way, does anyone know

GoustiFruit's picture

By the way, does anyone know how to remove the "reply to" link in the forum comments ? I want to keep the admin links (edit, remove) but remove the "reply to" because I don't want to allow replying to comments but only to the main post (master node).

Since you can't edit/remove

Gman's picture

Since you can't edit/remove links through the API, you have to do it at the theme level. Instead of just printing the $links variable, pass it to a trimming function like

print comment_trim_links($links);

Then have a function like this in your template.php file.

function comment_trim_links($links) { // These links are not desired
  $new = explode('<li',$links);
  foreach ($new as $key => $value) {
    if (stristr($value,'reply')) {
      unset($new[$key]);
    }
  }
  $final = implode('<li',$new);
  return $final;
}

At least this is the way that I did it. The 'contact author' module also places links on every comment, which our project manager objected to.

huh?

webchick's picture

hook_link_alter, my friend. :)

(Thank you

GoustiFruit's picture

(Thank you gman@drupal.org)

I must admit that I don't understand a thing to that hook_link_alter function !? :-\

And all those little problems accumulating, making me spend hours and hours on trying to understand every single line of every single file I meet, make me feel less and less confident with Drupal. Not that I was any confident at the beginning (a few weeks ago), but I thought it would be a lot easier to accomodate... :-(
Hum, will keep on looking for alternatives

Hook_link_alter???

Gman's picture

I thought it only altered the links that come with the node, not the links that are attached to comments. Or else I am just not using it right. The generic hook_link can only add links, since it is not passing the $links by reference.

Please do show me a better way, since I think my above code is hackish.

OT hook_link_alter works fine

Heine's picture

hook_link_alter works fine on comment links as you can see in comment_render:

<?php
 
foreach (module_implements('link_alter') as $module) {
?>

In addition, $comment->links holds a keyed array. The reply link has the key 'comment_add'. (edit: maybe not, need to look this up).

The above applies to Drupal 5 btw.

I finally figured this out,

Gman's picture

I finally figured this out, though it is not a good find. That piece of code is there only when a single comment is being rendered, not when a thread of comments is being rendered. Thus a threaded set of comment links can NOT be altered via hook_link_alter.

Probably should bring up an issue against the comments.module since my hack above is just that, a hack.

"unless I totally screwed this up"

Sorry for hijacking a thread, but it does have some focus on forums, since fine tune control of the links that appear on each post is highly desirable.

EDIT: Found an issue for this already, http://drupal.org/node/112514. Should be reviewed.

flat comments

It's better than nothing,

GoustiFruit's picture

It's better than nothing, but as mentioned somewhere (could find the page back), when you click on "reply to", you get the comment where you clicked as a reference instead of the first post/node.

I'm still trying to understand how hook_link_alter works, so if someone can give me some help, I would greatly appreciate ! Just need to remove the "reply to" link from the comments in my forums, as there is a global "reply text zone" below...

Thanks !

One nice option would be to

catch's picture

One nice option would be to have different theming for top level and nested forums in the forums index. At the moment the only difference I can detect is a hard coded 30px indent in forum.module.

This would allow for much cleaner presentation on sites with lots of forums (like mine, the main forums index is an absolute monster), and then for theme trickery like hiding subforums on the index etc.

All of that could be wiped out if it's moved to a general container thing from the refactored book module, so wait and see I guess!

I've just posted a new patch

catch's picture

I've just posted a new patch (against 5.1, HEAD to follow) for the "comments don't work if not on first page" issue here: http://drupal.org/node/6162#comment-226273

I'm no coder, but I think if something similar doesn't get in, it'd be worth looking at refactoring comment options as a contrib module which handles the extra logic, and also does "comment settings per node type" so you could have (properly) flat comments for forums and threaded for comments etc.

Fine grain permissions.

majortom's picture

I would really like much finer grain permissions.

Viewing:
Allow a user to see a list of forum groups.
Allow a user to see a list of forums within a group.
Allow a user to see the topic headings in a forum.
Allow a user to see a particular thread (this is optional but would be nice).
Allow access to specific items within a post or thread (e.g. poster user name, poster IP address, poster IP address country,
poster's online/offline status).

Posting/Reporting:
Allow a user to post a new topic.
Allow a user to post a reply to an existing topic.
Allow a user to include a picture in a post.
Allow a user to append a file to a post (may be the same as above).
Allow a user to include a link in post.
Allow a user to edit the topic in a post of his own.
Allow a user to edit his own post.
Allow a user to report a post.

Moderated posting:
All of the above options, but require that they be moderated before finally appearing.

Moderator/Administrator:
Allow a moderator to create a new forum group.
Allow a moderator to create a new forum.
Allow a moderator to create a new sub-forum.
Allow a moderator to merge threads.
Allow a moderator to move or delete threads.
Allow a moderator to edit/delete specific posts.
Allow a moderator to edit thread topics.
Allow a moderator to approve a submitted post.
Allow a moderator to approve an edited post.
Allow a moderator to approve a topic change.

Here is an example.

Forums:

Administration:
    Hardware:
    Network:
    Software:
    Security:

Home Theatre:
    News:
    Expert Help:
    HD Projectors:
        LCD:
        DLP:
            Topic: My new DLP projector rocks!
        Member Deals:

Adult:
    Reviews:
    Discussions:

So for example:

Only system administrators can see a list of the Administration forum group.
All system administrators can view posts in Hardware, Software and Network Forums.
Hardware administrators can post in their own forum.
Only security administrators can view posts in their forum.

Only users over 18 can even see that the Adult forum group exists.
Only registered users that have specifically requested it, may be able to see posts in either the Adult: Reviews or Discussion forums.

Only moderators may post in Home Theatre: News:
Any one may create a topic in Home Theatre: Expert support: but only those in the expert group can post replies.

Anonymous users may read posts in the all Home Theatre forums except Home Theatre: Member Deals: where they can see topics only (none of the actual posts).

The others are, I hope self explanatory. :-)

/carmi

For anyone interested, the

catch's picture

For anyone interested, the three year issue about #new links not working on paged threads has just been fixed. This is a massive, massive improvement for using the drupal core forum/comment/tracker modules.

...

Michelle's picture

/me does the happy dance. :)

Michelle

Multiple-Hierarchy & Multiple-Select

kipkoan's picture

Hey all. New user here. I'm in the process of migrating from Joomla to Drupal. The taxonomies are what really impressed me. Which leads me to my question...

My (very limited) understanding of the Drupal Forums is that they use the taxonomy system to implement "forums" (or sub-forums; e.g. containers for topics/posts). This is awesome, if I'm understanding this correctly. My first thought was: very cool, so I should be able to do something that I had long hoped would become available in forum software: posts tagged to be in 1 or more "forums", rather than have a strict single-forum-only requirement.

If you've ever been to a major forum site, with lots of categories/sub-forums, you soon realize that it can be very confusing to organize discrete categories in which topics should belong. Once a lot of categories/sub-forums are created, it soon becomes common that a single post/topic could belong in various categories. Why can't a single topic belong to multiple categories? I think it would make it much more effective for communication.

However... it doesn't appear that you can do this with the current Drupal Forums, right? It appears to be a single-hierarchy-only hard-coded? So, I'd like to see if this has been discussed before, or how difficult would it be to add this capability in a future release (7.0 perhaps)?

Why not use Views to

ericatkins's picture

Why not use Views to construct a forum view that puts your tagged posts in subcategories?

--
Sojourn Church - the Hushed Casket

It looks like that's

kipkoan's picture

It looks like that's basically what the Forum Module is doing. So, why reinvent the wheel... why not allow multiple-hierarchy for Forum topics? Or at least make it an option? I know it's not the norm for forums, but I think it would catch on.

No...

Michelle's picture

Forum module doesn't use views.

I have a post elsewhere in this group that discusses replacing it with views. It was called something like "forum deprecated?"

Michelle


See my Drupal articles and tutorials or come check out life in the Coulee Region.

Forum module doesn't use

kipkoan's picture

Forum module doesn't use views.

It's not using the Views module, but isn't it basically doing the same thing -- where an individual forum is a view to the taxonomy term (category) defining that forum?