#179: Improved commenting infrastructure

Contents

1. Definitions
2. Motivation
3. Assumptions
4. Proposal
5. Implementation
6. Deliverables
7. Risks
8. Progress log
9. Participants

Proposed by

Kai Diefenbach

Seconded by

Wichert Akkerman

Proposal type

Architecture

Repository branch

buildout

State

being-discussed

Definitions

 

 

Motivation

The current discussion framework is very simple. Hence some third party developers (e.g. of blogging software) feel the need to write their own commenting framework. The result is inconsistent comments within a Plone site, apart from same work is done again and again.

The motivation is to provide easy to adjustable comments. Additionally to provide the optional possibility to re-use the existing framework for third party products (e.g., if a developer feel the need for independent options for his product)

There is also a list of features which are needed these days to make commenting work. We can use the commenting system of Wordpress as a guideline. Thus a commenting system should enable the following

 

• Moderation: It should be possible to enable moderation so that every comment has to be confirmed by a reviewer.
• Confirmation: It should be possible to enable a confirmation email to be sent to the commenter to confirm the comment.
• Captcha Support: Captchas or math questions should be supported and should be an option
• Spam Protection: Akismet and other means of identifying spam should be supported.
• Mass Editing Screens: Like in Wordpress views for handling all comments of a subtree are needed. With these you can moderate comments or check their spam state.
  
• Open Identification Support: OpenID is more and more widespread and it should be possible for user to leave a comment using their openid. But as OpenID is not the only standard the ways to identify yourself should be pluggable. Of course it should also be possible to configure the commenting system without any identification required.
• Configurable Commenting Forms: It should be possible to decide which fields do actually show up in the form. The only mandatory field should be the comment text itself (and maybe a name)
• Extensibility: It should be possible for components to extend the comment form and the comment handling/workflow. An example is a plugin which allows commenters to subscribe to further comments via email. This needs to extend the form with the checkbox and the comment handling to send out the emails (as well as some management views for handling subscriptions).
• Local Configuration: It should be possible to enable commenting for a certain subtree (e.g. a blog) and configure it further for just that subtree.
  

 

These are just a few examples of what should be possible. All these things are also not intended to be implemented by the commenting framework itself but hooks for adding components to handle these things should be provided.

 

Assumptions

 

Proposal

Provide a zope3ish commenting framework (forms, views, adpaters), which can be used by any content types. Turn this components on for Plone's default content types by default.

 

For this PLIP we want to implement a basic commenting system with the following features:

Step 1

 

• Implement a component which can handle comments on any AT based content object
• Implement a viewlet for displaying these comments
• Implement a viewlet for adding new comments (form)
• Comments can be nested
• Anonymous and logged in users can comment
• Provide a control panel for managing commenting settings with the following options:
• Enable commenting?
• Enable anonymous commenting?
• List of content types to enable commenting for
• List of content types to never enable commenting for

 

 

Step 2

 

• Provide hooks for captchas
• Provide hooks for spam protection a la akismet
• Provide hooks for moderation control
• Provide a way to provide management views for bulk comment handling (moderation and spam, possibly more)
  

 

 

 

 

 

 

Implementation

Two packages should be created:

 

plone.commenting

Provides the following interfaces:

 

• ICommentable: every object/class which can have comments should be marked with this marker interface.
• ICommentProvider: handles retrieving of comments (adapter for ICommentable)
• ICommentManager: handles adding and deleting of comments (adapter for ICommentable)
• IComment: interface for the comment, basically handles the schema.

 

This component stores the comments as annotations on the object. The annotation will be a comment root object which contains a BTree of comments and some lists for handling nesting and sequence.

 

plone.app.commenting

 

This adds the plone related components such as the form, the viewlets and so on.

 

Deliverables

at least two packages: plone.commenting and plone.app.commenting 

Risks

• Already existing comments have to be migrated without restrictions.
• Commenting goes through the whole System, so that there could be issues, that *I* can't judge yet.
• It migth get in the way of other commenting packages installed. Thus we have to look at these and make them work. We need to create a list of them.
  

Progress log

• Resuming actual work on this plip at the 2007 Napoli Post-Conference Sprint with Kai Diefenbach, Tom Lazar, Christian Scholz and Vidar Andersen after having held a BoF on the topic and additionally consulted folks like optilude, hannosch and witsch. We now have a pretty clear idea of how and what to do (yay!)
• implemented nested comments after the sprint (2007-10-17, tomster)
• We discussed things further at the Snow Sprint (Christian Scholz and Aleksi Korvenranta) and we implemented plone.app.localconf as a test for local configuration (2008-01-20 mrtopf)

Participants

 

Tom Lazar

Christian Scholz

Kai Diefenbach

Vidar Andersen

Aleksi Korvenranta