No one likes to play with comment.module, it's long neglected, manages to just about keep up with its basic tasks OK (making it not so broken as to invite a flood of patches), but singularly fails when you want to do anything clever with it due to fairly fundamental architecutural issues (making it a pain to write patches for). But core standards are improving, and it can only limp along for so long.
The long term, pie in the sky (but equally unpopular in some quarters) solution to this has been making comments into nodes - there's a nodecomment module for Drupal 5 and 6, used on some high profile sites, which aims to be a drop-in replacement for the core comment module for this purpose.
The primary argument against doing this in core has been performance. Since September I've put a lot of work into speeding up node_load(), and it's now equivalent to comments even when displaying large numbers of nodes. With node_load() caching and some other pending optimisations, nodes might even get faster (at least on straight loads) in Drupal 7. Of course loading isn't the only problem, a write heavy site with MyISAM tables is going to have trouble if all the reads and writes hit the node table, as opposed to both the comment table and the node table, but nothing stops people building sites using only nodes which are write heavy anyway.
The other argument against comments as nodes is that 'comments aren't content' - i.e. they're attached to content, but not first class items in their own right. For example, you don't want comments showing up as individual items in search results - you want the node and its comments searched as currently happens in core. The flipside to this is if I'm searching for some text which appears in comment 2000 of a 4000 long thread, when I search, I'll be taken to the first page in the thread, on which that comment doesn't appear. We can solve the basic indexing problem by excluding 'comments' from the search index in their own right, but appending them to the indexed markup for parent nodes same as now, so there's ways around this, but they require more than just a straight conversion.
There's been some discussion back and forth around these issues, both in #drupal on irc and in the issue queue. Here's a quick summary of the possible approaches, and an overview of the current state of things:
1. Leave things as they are
comment module has a very clunky API (look at comment_render() if you want an example). Some modules support this API - like fivestar, comment upload etc. - but those modules have to do everything twice, once for nodes, once for comments. The general consensus of discussions so far is against making comments a 'fieldable' item, since this would require most of the complexity of nodes to work properly, and have all of the performance penalties.
2. Comments as nodes
Converting comments to nodes would be a large undertaking - we'd need to rewrite comment.module from scratch. It'd mean we have a much more robust API for comments (not that the node api is that great either, but it's slowly being improved). Comments would be fieldable, but while comments vs. nodes come out about even for loading in benchmarks, we'd have to handle the fact of Drupal.org having over 1 million nodes overnight, and the additional weight on inserts and table size.
3. Forum posts as nodes
Forums are one area where the original post is on an equal footing to the replies to it, and most forum software - phpbb, vbulletin etc. gives moderators easy and powerful tools to split forked discussions into new threads, merge similar discussions together etc. etc. - something which comment mover tries to do in contrib - but dynamically changing a piece of content from a node to a comment isn't much fun - we don't even support node type changes in core yet.
4. Both
chx has written up a post describing a small non-fieldable item API - as a generic storage method for lightweight items. This would be ultra-lightweight comments - no fields, no hook_comment(), with link changes handled in the theme layer or somewhere similar. In addition, we'd support nodes as comments in core as an alternative - possibly allowing for combinations of both on the same site. So the blog runs non-fieldable items, but the video clip responses section runs nodes as comments due to field support. This would allow for both extremes to be catered for, but it's got some interesting issues to solve both from an architectural perspective and a UI perspective - at least if we don't want both systems mutually exclusive.
So, anything apart from shipping with a hamstrung and broken module in Drupal 7 is going to require a fair bit of refactoring, and at the moment there's no patches tackling any of these issues directly. But with fields in core looming very close, now seems like a good time to thrash this out.
Comments
Both
I vote for both. I'd, also, like to have my cake and eat it too.
Matt Farina
www.innovatingtomorrow.net
www.geeksandgod.com
www.superaveragepodcast.com
www.mattfarina.com
Both...
... does sound very nice indeed!
Do both - as nodes and as
Do both - as nodes and as lightweight.
For external or virtual content drupal needs a way to attach comments, ratings
and other stuff on it without going always the big way by creating nodes for it.
External or virtual content are not drupal nodes content by nature.
Means, we can't normally edit, alter or delete such content.
We present and show the content - but we don't "own" it normally.
Because that alot of the node core functions already would not work on such a content.
So, its fine to add to that kind of pages a lightweight comment, called
not by a nid but by a $tag which can be defined more free. Like the URL
or keywords or something.
This kind of comments are in Zikula and other CMS bound to pages in the
theme as "late binded hooks". Hooks means here something different as the
drupal core hooks, just want point it out. For drupal you would for example
load it in a tpl.php like load_theme_hook('comment', $tag). Just as example.
That these lightweight comments can't be commented for example as node
comments (or the current ones) or not rated - thats ok. IF you want that
functionality then you have to do more work and include the content itself as
node or use node comments.
The problem with the current comment and "hookable stuff" like ratings is not
that something is wrong with them (as my point as user) - its just they are
physically bound to the nodes in every case.
A leightweight comment system (or better, a leightweight hook system/API)
would give the needed freedom how to design a site.
And a site build out of external content is something we will see more often
in the future because its often described as then next big thing (well, no
idea is really the next big thing...).
Forum posts as nodes
I have phpbb2 running and try since months to get a decision if changing / migrating to drupal.
But cause the forum is the heart of th website / community i think i can t change.
Advanced forum module is the best i can find to bring drupal similar.
This module i think shows the way for the future, cause the most people come to drupal cause it declared as a cms for building communities.
And very often a forum is the heart of a community.
I don t want to know how many people checked out drupal and decide not to change from an existent forum cause it s not fun...
I think the forum is too important for a cms what get visitors cause its known as an communities cms.
If the forum.module or similar will be similar make possible like a simple redy to go forum software drupal will reach the future now.
If the forum will be neglated more and more its more and more less interressting to use for communities.
regards from Leipzig,germany
manfred
www.edelsteine.de
www.heilsteine.info
Seperate module.
I say we need to make the comments module more lightweight, and create 2 new modules: a "Responses" module, and a "Fields comments" module
Forum would use Responses. (comment nodes)
News items would use comments. (simple comments)
Issues queue would use Fields comments. (node-like behaviour, but not nodes)
the only thing you would need to set on your content type creation, is which comment type you would need.
Doing anything two ways is a
Doing anything two ways is a good way to do a mediocre job at both. Pick one way and do it well.
The problem of one way is
The problem of one way is this: As a node/node related comment, any comment can only
handle a node - its physically bound to a node which defines the way.
We need a comment system which can handle non node content -
for example to include external content delivered by google or someone else over a API.
In fact we define here 2 different uses and so 2 different way- the question is:
Want we use 2 parted comments system or one system, usable different (where
the next question is: How we bring both together?).
There is btw another point i miss here: Copyright and licences.
There is a chance external API content is allowed to show - but not allowed to save.
The current external content is pretty save to use - google maps, amazon stuff and such.
They have an interest to be spread. But i am pretty sure there will be others
in the future. Connecting content and/or use recources not resident physically
on your own server is one of the big moves in the internet. And drupal is weak
here.
Technically, when we grap external content, move parts as "anchor" to a node to
make the core aware about it and open the door for the internal workflow, are we
not saving then parts of a content we don't own? Please think about it in a
wide, not only technical directed way.
As far my experience is with copyright holder and that APIs - the chance is given.
So, a leightweight API which you can be hooked to non node content is more as only
a technical question, IMHO.
What are the issues with threaded comments?
Sorry, this was off topic, as a noob I didn't know how best to respond to the post on the main page - I've moved this to a new discussion.
Both would probably satisfy
Both would probably satisfy everyone, and there wouldn't be more work, as both the lightweight form and the node form will be created anyway.
Working together and creating a flexible solution is probably important, and it would be very nice to be able to switch between lightcomments and nodecomments per content type or for any other type of similar data.
This is the Forum Improvement group so
I think the focus needs to be on what is the best solution for forums. In my opinion that is to have all "forum posts" as first class entities (nodes).
Can anyone explain the basic difference between the data structures used in phpbb, vbullettin etc and drupal? I'm wondering if the biggest challenge is that the basic architecture of drupal - everything is a node - is at odds with the "default" architecture for forum based systems.
cheers
James
Both for me...
I've been in situations where I would like both, so I'd say give people the choice if possible.
Also, I don't necessarily agree that comments aren't content. Surely comments are just small pieces of secondary content, albeit contributed by a user community and not directly by primary site authors, but a good use-case example of this is when you search for something in google. The entire site is indexed by google, comments and all, so when it finds something matching your search term in a comment, it returns this to you.
If you're interested in what the comment says, you will be considering this as content, will you not? And everyone knows that google is always right, so this must be true!
I've also worked with different CMSs in the past which count comments as nodes and had no problem with this approach, provided they are clearly market as a distinctive "comment" node type. (The other CMS I used didn't make this distinction for some reason, which made extensibility an almost impossibility, I had to extend the database schema first and then start working on functionality so I could easily query what was a comment without looping through and finding descendants of a content item etc.)
Markhankins.co.uk - Where the extra bit goes when my brain is full-up!
Nodes
Nodes for forum use at least. Its torture not having fields on forum replys.
.
This discussion is about Drupal 7, so lack of fields is irrelevant. There are other advantages, though, so using nodes for comments isn't totally moot despite comment fieldability.
Michelle
bummed there is no nodecomment (or equiv) for d7
i have to say i am disappointed i cannot find something equivalent to nodecomment for d7. i am porting over a site from a custom (ancient) system to drupal and really find it hard to believe comments are still so weak in d7, given that they were so weak way back in d5 when i started drupal. i do not get the resistance to making comments nodes?
i need to be able to have users attach things to comments, rate them, tag them (taxonomy), and so forth. sounds a lot like stuff already being done to nodes! and yet, here i am having to wonder if drupal can pull this off with comments.
i am hoping someone can tell me i am wrong -- as i am new to d7 (only experience with d5 & d6)....
thanks!
-jon
I am happy to tell you that you are wrong!
Comments are entity's in Drupal 7, just as nodes are entity's. This means you can do similar things to comments that you can do to nodes such as attaching fields. To answer some of your specific issues:
Jon Antoine
Antoine Solutions