eZ Comments vs. comments via eZ content model

The eZ Comments extension is a very simple and easy to use solution if you want to setup an article commenting system quickly. But in my experience it's a bad idea to use it if you need any advanced commenting functionalities. So read further if you want to find about it...

In my experience as an eZP developer I have implemented many sites with the article commenting feature. Only one of them was implemented using the eZ Comments extension, and soon after that I abandoned this approach and went back to implementing the comments system using the eZP's content model (objects of class “Comment” as children of articles).

Actually, my experience with both solutions taught me that the main problem of eZ Comments extension is that it doesn't use the eZP content model. Several usability and conceptual problems come out of this fact:

• you can only delete on comment at the time – so imagine you have to delete 50 comments for one article
• it only supports plain text comments, there's no rich text editing, no attaching files or similar functionality
• you cannot have “threaded” comments (comments on comments)
• you cannot create a fine grained roles and policies system for comments
• you cannot “like” a comment or vote for it
• users cannot report a inappropriate comment
• you cannot have a list of all the comments of the site in one place

On the other hand... First, all of these features can be implemented using the Comment class for comments. Second, there are no features of eZ Comments extension that cannot be implemented using the standard eZP content model and functionalities.

Furthermore, one feature that is pointed out as most important in eZ Comments is:

“using separate table for storing comments to improve performance”

Which sounds like a very good idea but actually it isn't. Here are some counter arguments...

1) Does it really?

The statement that putting comments in a separate table gives a valuable performance improvement doesn't really stand. Anyone that have analyzed eZP fetches deeply (I mean like on the level of MySQL EXPLAIN query) and on real usage examples will know that when fetching only objects of Article class the performance is not really much degraded by the number of comment objects on your site. The article/comment ratio is usually evenly distributed over the node tree (you won't have a category with only 10 articles and 1000 comments) with a constant order of magnitude, which is usually very low. It won't make much difference if you perform an sql query on 1000 indexed objects or 2000.

Also, there are several techniques that can allow you to have a lot of content without loosing much of performance in fecthes. For example, I have a (high traffic) site with more than 200.000 objects performing complex fetches, and their performance is pretty much the same as if there were only 2.000 objects. On the site the comments are implemented using the “Comment” class and it does not degrade performance at all.

It's all about understanding your site and using eZP wisely.

2) Comments are not content?

Who when and why made the decision that comments are not content?

As far as I'm concerned, comments are content because I want to be able to do with them most of the tasks I want to do with other content:

• be able to search for text through comments (think of eZFind)
• be able to move them, hide/show, delete and restore them from thrash
• fetch comments based on different criteria
• sort the fetched comments based on different criteria
• attach edit handlers and workflows to the comment publishing event
• import/export comments using the same functions/extensions I use for other content
• insert link to a specific comment or embed a comment in a text of an article

By putting comments in a separate database table you loose all this capabilities and also any other future functionality that will be implemented in eZP and it's content model.

To conclude...

My opinion is that the approach of implementing the comments system without using the powerful eZ content model was a bad decision and very wrong. It looks like reinventing the wheel in a shape of triangle...

The only true advantage that I found in eZ Comments it's that comes with ready made templates and allows you to setup the commenting system very quickly. But that can all be done reagardless of the implementation, right?

My suggestion would be to rewrite completely the eZ Comments extension and implement it using the eZ content model and existing eZP capabilities. And wrap it nice with all the shiny and easy to use features that already has, so that retains the same usability.

There it is. Now after I've written about comments, I'm ready to hear some comments...