Plan of attack for Drupal 6.x core forum module

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
You are viewing a wiki page. You are welcome to join the group and then edit it. Be bold!

This is the result of some brainstorming with merlinofchaos regarding core forum improvements for 6.x. I made it a wiki page so people can sign up for taking on things, post relevant issues where they exist, etc.

This is what looks like a do-able plan for 6.x. The stuff that would be cool, but might not be doable is listed under "nice to haves." There's some great stuff in there though, so if anyone wants to take a stab at it (particularly outline module), feel free!

Battle plan for 6.x core forums

  1. Signatures displayed on forum posts as well as forum replies
  2. Private forums: move the parts of forum_access module dealing with CRUD (create, read, update, delete) of forums themselves into core (which should be much easier than the moderator part -- see below). Needs to deal with comment CRUD on forums as well.
  3. Unique CSS IDs for forums, containers & forum table
  4. Link to latest post in 'Last post' in forums tableLink to latest post in 'Last post' in forums table
    • Assigned to: Gurpartap Singh
    • Status: patch (code needs review)
    • Relevant issue(s): http://drupal.org/node/147045
    • Dependencies: http://drupal.org/node/6162
  5. Ship with default sane theming for forums, drawing from Flatforum module.
  6. Dynamic signatures that display on view and can be updated throughout the site by editing your user profile
  7. Allow comment-type.tpl.php ... should be a simple 2-line patch
  8. Allow forum topics to be custom node types

Nice to haves

  • Forum moderators. This would involve taking the acl.module stuff out of forum_access module and re-purposing it. This could be a hefty task, so if someone's interested in working on it for 6.x, they should start sooner than later. ;)
    • Assigned to: ???
    • Status: Not started
    • Relevant issue(s): n/a
    • Dependencies: Forum access in core
  • Generic hierarchical structuring (outline module): for more info see http://drupal.org/node/128731 .. this would be a huge win for Drupal core as a whole, as it would allow a generic way to do the hierarchical structuring found in book.module. For forums, it means we could add polls, reviews, or any other kind of node type to a forum.
    • Assigned to: ???
    • Status: Not started
    • Relevant issue(s): n/a
    • Dependencies: None?
  • Allow moving/re-joining comments. Move functionality of comment_mover.module into core.
    • Assigned to: anyone willing to contribute to comment_mover
    • Status: Move to Core not started; beta code improvements in progress (2007/4/6)
    • Relevant issue(s): comment_mover is still beta quality. Needs to be refactored, slimmed down, and stable before it could be moved to core.
    • Dependencies: None
  • Count forum posts per Author, and expose to forum theme. Flatforum module tracks post counts through a separate table for quick lookups.
    • Assigned to: ???
    • Status: Not started
    • Relevant issue(s): n/a
    • Dependencies: None?

Nice to haves but not likely core

* subscriptions.module. this functionality belongs in core but subscriptions.module is a subpoptimal starting point.
* quote.module
* commentrss. what we really want is a unified feed between forum nodes and their replies. you actually get that with nodeforum (not yet released) and comments as node.

AttachmentSize
Forums | Drupal_111180700686481.png6.89 KB

Comments

Comment mover

Heine's picture

In my not so humble opinion, comment_mover requires a lot of work to go into core. Refactoring and slimming down come to mind first.

GUI magic

Gábor Hojtsy's picture

Sure, as well as some GUI magic, hopefully with jQuery stuff, so moving comments gets easier then ever. (Maybe stuff the jQuery addon into contrib).

Other options

jlambert's picture

Ok, so what about adding a "subscribe to this thread" link, which would enable a user to control from their profile:

1) the option to have emails sent on forum replies
2) the option to have forum replies stuffed into an RSS feed (an "amalgamator" for all threads)

Optionally, it would also be able to:

  • subscribe to posts from a particular user
  • subscribe to posts from a particular "forum" (obviously, this isn't hard)
  • block read for particular users, aka, "I don't want to hear that anymore..."
  • expire threads after a period of time, to keep spam down
  • combine threads, or make sticky
  • notify by keyword when someone posts
  • associate keyworks with a post for aggregator (expensive)

I think those would be useful, in some manner.

I don't know if Drupal mail has been fixed yet, but backgrounding email sending (queue) for forum communities will be important.

Those are all really good.

merlinofchaos's picture

Those are all really good. Some problems:

Some of those are bigger than forum; getting them into core requires a lot of thought. (Comment emails, subscribe to forums/posts).

It may be possible to do a light weight subscribe to forum in core; it may not. One has to be careful there.

Email is a bag of worms that will be difficult to get into core at this time, I think.

agree

jlambert's picture

I agree. The real issue around putting this stuff in core is actually a little complicated. Like, for example, lets say I want to use external forum software (yes, I prefer everything integrated, just saying). vBulletin, SMF, phpBB, Invision (we're writing support for it right now), and other php-based forum software would require an API to integrate, wouldn't it? Putting it in core would make sense, but the important question is, "Could we then integrate non-Drupal forums with this using API?"

That's a VERY worthwhile discussion angle on this one. Right now we're working on IPB (Invision Power Board) to integrate it into Drupal, and I intend to maintain it, so I want to make sure 6.0 has hooks for integration 'cause I think that would help the community take advantage of the integration (KISS).

If it goes in core, then it should be re-usable. I'd be happy to work with you now to implement the IPB module with this in mind, 'cause it might help. See you on IRC. ;-)

Email sucks. Notification is powerfully important however. For busy forums sites, one should be able to configure drupal for external smtp, so this might be overcome. At least the scaffolding would be important, even if it's not in core. I don't know how many times I have missed replies to stuff I've posted this year, but it's more than my hands and feet combined.

Well, worth discussing.

Jonathan

until then

moshe weitzman's picture

until these go into core, see commentrss.module and subscriptions.module

agree as well

jlambert's picture

I agree Moshe, but I would like to be able to integrate an external system on top of it, which would tend to preclude a "mashup of modules" in terms of support. IMHO, the 'forum api' component of this redesign is actually just as important as the changes themselves. Could be wrong. Just raising the issue for discussing.

Maybe providing an install profile for external support of "forums stuff" is the way to go. IMHO, subscriptions module should absolutely be in core (know the issues, just saying).

See comments below. ;-) Cheers!!!

I tend to agree aswell - end

daniel.hunt's picture

I tend to agree aswell - end users don't want to install a crap load of modules "just" to get their forum to work like a real web-forum.
I actually don't like the idea of an install profile that will install multiple modules - the forum should just be a forum module, everything else should be in core regardless. There's no reason why subscription and email notification shouldn't be in core in my opinion.

This project will no doubt be of great benefit to drupal and its users, don't get me wrong, but I do have a few opinions on the direction that it's going I'm afraid

There's no reason why

merlinofchaos's picture

There's no reason why subscription and email notification shouldn't be in core in my opinion.

Because we have to take baby steps. We have to do one thing at a time. We've got a huge plan, and pretty much this entire thread seems to consist of people whining about what's NOT on the plan. It's making me cranky.

Point taken - apologies

daniel.hunt's picture

Point taken - apologies

Accordion (JQuery)

Wim Leers's picture

Easy to implement, greatly improves usability. See http://jquery.bassistance.de/accordion/ for a demo. It relies on JQuery, but it does require JQuery 1.1 I think, which shouldn't be a problem since JQuery 1.1 will be included in D6?
I'll volunteer to do this.

How exactly will that

Steven Jones's picture

How exactly will that 'greatly improve'...'usability'?

I'll admit it's pretty cool,

keizo's picture

I'll admit it's pretty cool, but I too don't see how it improves usability. Could be a good add-on module. Not for core though.

Considering the demo broke

ggilbert's picture

Considering the demo broke horribly in Firefox, it might not be ready for prime time.

Works fine in 2.0 here...

Toe's picture

Works fine in Firefox 2.0 here.

Containers that contain many forums

Wim Leers's picture

Suppose you have a container that contains 15 forums, another one that contains 5, another one that contains 3. Or even more contains and/or forums. Then, if this accordion feature would be included, you could easily browse them, not having to scroll all the way down to find the right one.
But considering the several negative reactions towards this - which I find rather strange, but that's probably just me - I guess it should not be included.

There is no reason that the

merlinofchaos's picture

There is no reason that the accordion stuff couldn't be done as a module, possibly requiring a theming layer component. It's not something that every forum must have, though, so it's one of those kind of spiffy addons. I think that's where the negative reaction comes from.

I tried to implement this

Wim Leers's picture

I tried to implement this for my own use just now, but it turned out that this plugin has some HTML requirements: it needs a "header element", no problem here, but the collapsable part, i.e. the content, must sit inside this header element (i.e. child elements). But Drupal renders forums and forum containers at the same level: tr's in the tbody. So that just won't work.

Of course you could write your own Accordion stuff, but that's out of scope for me, higher priorities first then.

Restrict discussion on this topic, please

merlinofchaos's picture

I'd like to restrict the comments on this topic to relevant items.

Nice to haves are just that...adding to this plan is dangerous. We've outlined what we believe is actually feasible to get into core based upon what we know about core and the process of getting patches into core. This topic shouldn't be used to ask for more items, unless you have a good understanding of how those items can be fit into the process of getting something into core.

Most of what we have on this list as part of the actual Plan are items that Dries has specifically said he would be interested in it. Now, it's not a complete list, but we also are considering the realistic timeframes involved. Some of this will take significant time (not just in coding, but in tweaking a patch until it can be applied). This thread should largely be about how to implement this plan. It's a good place for questions, clarification and stuff like that. If it gets sidetracked on "ooh ooh we need this feature TOO" discussions, we'll lose track of what this thread is for -- for that, please start a new one.

Seems like a good place to

catch's picture

There's a couple of fairly large issues with how the forum and comment modules work that make 1. large forums 2. flat forums a bit tricky. If default theming is going to go more flat/forum-like according to the OP, then these will be even more of an issue.

http://drupal.org/node/6162 "new" links from tracker and forum indexes not working on long threads is a big sticking point on busy forums. This is stuck on the user setting options.

http://drupal.org/node/81373 One thing affecting comment mover, and a sane comment editing process, is that even with "flat expanded", comment hierarchy is still stored in the database.

http://drupal.org/node/131428 it'd be a nice usability imrpovement for comment submit to redirect back to the comment instead of the node, I don't know how feasible this is in core. That issue ended up being a request for comment permalinks as well (i.e. example.com/comment/1234) due to moderation not allowing for a clean redirect, and because there's currently no bulletproof way to link to a comment given user settings affecting the paging.

i want to help

x2l2's picture

what i do to collaborate in development?
the problem is that my english is bad ^_^U sorry

To collaborate with

merlinofchaos's picture

To collaborate with development, identify an area you'd like to work on; mark it here (this is a wiki so you can edit) that you are working on it, and put a DATE so that we can see if someone says they are working on it and then doesn't.

Then post regular updates to your progress here, and/or post a patch against core that we can review, tweak and push into the spotlight.

If you need help/advice on the code, post what you've got here.

I would like to help with

Gman's picture

I would like to help with #3: Private forums, but I am not yet confident enough I have the time to place my name in the above. I did edit the section slightly to include the trouble I mentioned on a forum_access issue, http://drupal.org/node/123152.

A 'normal' forum feature is to allow 'view' access to the forum and threads, but not posting, while allowing posting in other forums they have 'create' access to. To do this the user must have 'post comments' access to post in the 'allowed' forums.

But, since to make a comment to a node you only need 'view' access to the node (which we have to do to allow viewing theads and forum_access controls this nicely), and 'post comments' (which you have to do to allow a user to post anything). This means that any thread they can view, they can also post to (not what is wanted).

This is a Drupal limitation since you can't intercept user_access() calls.

To keep things moving, we should just not give out a 'view but not post' permission, because we can't really lock it down.

Just wondering if

catch's picture

Just wondering if permissions around comments against particular forum posts could be extended to include things like comments against other node types nodes. That could allow for things like - only buddylist buddies allowed to comment whilst all can view etc. on profile nodes, maybe things like having bloggers control comments on their blog (and only their blog) in the blog module or an extension. Could add a lot of weight though I guess as well.

Hi friends, I didn't

tounano@drupal.org's picture

Hi friends,

I didn't understood from the whole thread. Will this features go into core?

Thanks.

What goes into core is

Toe's picture

What goes into core is exactly whatever people submit and have approved for core. :)

Not sure how one contributes...

Nightwatch-gdo's picture

I already do not install core forums and have a simple custom module that allows for any node type associated to one of our forum vocabularies to be posted in our forums on http://darklight.co.za You're very right webchick, the members love it! Also added "mark read" for all, per term and per topic.

Would also love to spend some time to make, maybe a view field, that links to the right page for new posts in threads. I'd love to contribute, but I'm just not sure how ;-)

Would also love to spend

catch's picture

Would also love to spend some time to make, maybe a view field, that links to the right page for new posts in threads. I'd love to contribute, but I'm just not sure how ;-)

This issue deals with the new posts paging: http://drupal.org/node/6162

new posts links in views are currently in an include using the same logic as forums/tracker modules. A view field seperate to that would be a good workaround until there's a full solution.

If you're up for sharing the "mark as read" code that'd be great - that's something that'd be really handy as contrib module, plenty of chatter in the forums about it.

The best way to contribute is to post on issues for the relevant projects on drupal.org - reporting bugs and uploading/reviewing patches.

There's also a pair of mark as

ggilbert's picture

There's also a pair of mark as read options that are at least in working order

http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/sanduhrs/foru...
and
http://wtanaka.com/drupal/markasread

I'm using the first along with a rethemed forum_display on a forum at the moment.

Views New Page Link

Nightwatch-gdo's picture

Thank you for pointing me to where views fields are done, catch@drupal.org.

Found it in \modules\views\modules\views_comment.inc as follows on line 235:

<?php
/*
* Format a field as a number of comments, plus the number of unread comments.
*/
function views_handler_comments_with_new($fieldinfo, $fielddata, $value, $data) {
 
$comments = intval($value);
  if (
$comments && $new = comment_num_new($data->nid)) {
   
$comments .= '<br />';
   
$comments .= l(t('@num new', array('@num' => $new)), "node/$data->nid", NULL, NULL, 'new');
  }
  return
$comments;
}
?>

Which I changed to:

<?php
/*
* Format a field as a number of comments, plus the number of unread comments.
*/
function views_handler_comments_with_new($fieldinfo, $fielddata, $value, $data) {
 
$comments = intval($value);
  if (
$comments && $new = comment_num_new($data->nid)) {
   
   
$new_ord = comment_num_all($data->nid) - $new;
   
$per_page = _comment_get_display_setting('comments_per_page');
   
$page = ($new_ord > $per_page) ? 'page=' . floor($new_ord / $per_page) : NULL;
   
   
$comments .= '<br />';
   
$comments .= l(t('@num new', array('@num' => $new)), "node/$data->nid", NULL, $page, 'new');
  }
  return
$comments;
}
?>

I'm pretty new to all this, but it seems to work and it seems to draw info from cached data. What to do from here? Should I go figure out how to make patches and add this as a patch to views? If so, a pointer to where one may figure out patching on windows would be great.

Submitting as patch to views

catch's picture

Submitting as patch to views issue tracker is the best way for the code to get checked out and maybe committed.

I followed these instructions (by the author of this very wiki page) for making patches on windows and it was pretty straightforward.

Persistent Forum "Header"

COI's picture

This may seem simple, but one of the most jarring things about Drupal Forums is the fact that it jumps out of the hierarchy as you drill down. When you get to the actual post, it looks like any other node and the reader loses the context of the thread.

Threaded display (comment_page) + User Points

druvision's picture

Two more nice modules you can add into a standard forum configuration are:

Amnon
-
Professional: Drupal Search | Drupal Israel | Web Hosting Strategies
Personal: Hitech Dolphin: Regain Simple Joy :)

Halca's picture

Although it's a good idea to speculate here what kinds of features are required, the best form of attack is one where a design or plan is formulated to deal with a particular task. In this case, we already know why drupal's forum is inadequate; it provides less features and familiarity than other forum software. Hence, we must look to see what familiar features there are between forum softwares (IPB and phpBB) and include those in our release.

Although the list now does list features we require, it may end up being problematic later on when we have to add in further features and functionality, so why not just look up these features now, and then we have no need for further abstraction.

I think the most important things for this current design should be the following:
* Establishing common features, and how it is possible to link them in with pre-existing elements and structures already visible in drupal's code.
* Providing a single module package (including all sub-modules and requirements) so that any people requiring this for a production-style environment are able to deploy it as quickly as possible.
* Providing automated conversion utilities that allow migration from major forum software; phpBB, vBulletin, Invision Power Board, and even to show off provide conversion for relatively new or old software like vanilla or YabbSE and a popular asian board, Discuz! .

Find attached the following links;

Vanilla

Nortix's picture

You should take a look at this (brandnew) board: http://www.getvanilla.com/

I like it. :D

Sure

Halca's picture

Yeah, i've seen it -- not bad.

RSS Feed

Brilwing's picture

I have migrated a phpBB forum to Drupal and made also a phpbb like theme ( see http://liveforspeed.at/forum )
But what I missed most was a RSS-Feed that contains the node and also comments. Today I have wrote a custom_feed module that creates a rss feed of a certain node type and includes also the comments.

Here is the code (for drupal 5.3) : https://openbakery.org/svn/repos/trunk/drupal/modules/custom_feed/

Nice looking Forum

mennonot's picture

I'm impressed with how similar it looks to standard forum software.

Will you be sharing the theme or writing a description the process you used to create a forum that looks so similar to phpBB?

I use the zen theme as basis

Brilwing's picture

I use the zen theme as basis for my site. I have patch the forum style to the original zen theme: http://openbakery.org/download/zen.zip

Quick suggestion on your

rszrama's picture

Quick suggestion on your forum thread/comment template... you might check to see if a user is logged in before displaying the PM button. This way anonymous users won't even be bothered with it.

How about moving threads

psicomante's picture

How about moving threads permission? Like a separate permission, not part of editing message...

--
Psicomante - italian translator and developer
il Blog di Psicomante
Drupal Italia

--
Psicomante - italian translator and developer
il Blog di Psicomante
Drupal Italia

Any news on these?

drupalbee's picture

I'm looking for a solution of getting the forums to have a status. This is one of very few places I have seen anything posted. I see most of these are a bit older, so I was hoping it may have been updated by now. I'm very new, so I may not be looking down the correct path for it. I need the admin or creator of the forum topic to be able to make the forum active when they create it, but be able to change its status to "closed", "resolved", etc. Any information, help or direction would be greatly appreciated.
Thanks in advance!