Ticket #9288 (closed PLIP: fixed)
Improved commenting infrastructure
Reported by: | timo | Owned by: | timo |
---|---|---|---|
Priority: | minor | Milestone: | 4.1 |
Component: | General | Version: | |
Keywords: | Cc: | plip-advisories@…, dukebody, grahamperrin@…, timo@… |
Description (last modified by timo) (diff)
A proposal for an improved commenting infrastructure for Plone.
PLIP implementation: http://svn.plone.org/svn/plone/buildouts/plone-coredev/branches/4.1/plips/plip9288-improved-commenting-infrastructure.txt
Contents
- Motivation
- Proposal
- Implementation
- Deliverables
- Risks
- Progress Log
- Participants
Motivation
The current Plone discussion framework is very basic and lacks functionality that is common in many Content Management Systems and blogs these days. Hence, third party developers feel the need to write their own commenting framework (e.g. qPloneComments and iqpp.plone.commenting). This leads to two major drawbacks. First, the comments are inconsistent within a single Plone site and second, the same administrative works has do be done twice.
The motivation for this PLIP is to provide an easy to use and adjustable comment system using the existing services of Plone. Additionally to provide the possibility to re-use the commenting framework for third party products (e.g., if a developers feels the need for independent options for their product).
In addition to the main goal, there are requirements for a state-of-the-art comment system. The Wordpress system may be used as an example and gives guidelines for a new system:
- Moderation: It should be possible to enable moderation so that every comment has to be reviewed before publishing.
- E-Mail notification: 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, e.g. "1+1 = 2"
- 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 useful to moderate comments or check their spam state.
- Configurable Commenting Forms: It should be possible to decide which fields do actually show up in the form.
- Extensibility: It should be possible for components to extend the comment form and the comment handling/workflow. An example is a plug-in which allows commenters to subscribe to further comments via email.
Proposal
As part of the Google Summer of Code 2009, Timo Stollenwerk (with Martin Aspeli as mentor) is developing a new commenting package. Martin set up the basic commenting infrastructure and made the basic design decisions for a zope3ish commenting framework (forms, views, adapters) which can be used by any content type.
Implementation
The plone.app.discussion package already has been created with the following architectural principles:
- Discussion items have a portal_type
- Discussion items are cataloged
- Discussion items are subject to workflow and permissions
- Discussion items are light weight objects
- Optimise for retrieval speed
- Settings are stored in plone.registry
- Forms are constructed using extensible z3c.form forms
- Discussion items are stored in a BTree container
- Discussion items are accessed using a dict-like interface
- Discussion items are retrieved in reverse creation date order
- Discussion items do not need readable ids
- Discussion items send events
Deliverables
The basic commenting infrastructure is already in place. On August 24th, when Google Summer of Code ends, the plone.app.discussion package will be in a state that it can replace the current Plone commenting system. This doesn't necessarily mean that the system will be feature complete, but that the package will provide the basic features for a state-of-the-art commenting system This means, it is well tested and well documented, and migration of existing comments is possible.
Risks
- Already existing comments have to be migrated without restrictions.
- There might arise conflicts with other, already installed commenting packages. Thus we have to look at these and make them work.
Progress log
We set up a story-based project planning tool, to manage the project and to track the progress: http://www.pivotaltracker.com/projects/15135
- GSoC started (2009-04-23)
- Basic commenting infrastructure is in place (2009-05-13)
- First alpha release 1.0a1 (2009-06-07)
- 1.0b1 released (2009-12-08)
- 1.0b5 released (2010-07-16)
- 1.0b12 released (2010-11-04)
Participants
- Timo Stollenwerk
- Martin Aspeli
- Jon Stahl
- David Glick
- Lennart Regebro
Change History
comment:6 Changed 7 years ago by pupq
As silly as it may seem, the most common requested feature about comments is (I'm almost embarassed to say this, but ...) "where are the icons for the different smiley faces".
I'll leave it up to you all to decide whether that's something we should implement. ;)
comment:7 Changed 7 years ago by regebro
- Cc regebro added
Yes, this should hopefully be done by 4.0 release, and then included. +1
comment:8 Changed 7 years ago by erikrose
- Owner timo deleted
Clearing Owner field of 4.0 PLIPs so we can use it to mean "implementor". (Many of these owners were automatically assigned from choosing a Component that had a default owner.)
comment:12 Changed 7 years ago by MatthewWilkes
FWT Vote: +1
comment:13 Changed 7 years ago by rossp
- Owner set to timo
- Status changed from assigned to new
The owner was intentional here
comment:14 Changed 7 years ago by rossp
FWT vote +1. I'm not sure this belongs in Plone core but since Plone core currently includes commenting and we don't have #8810 yet, I think improving commenting would be great.
comment:15 Changed 7 years ago by davisagli
FWT vote: +1
comment:16 Changed 7 years ago by raphael
FWT vote: +1 (since we ship with a poor commenting solution since ages; otherwise I'd say this is the perfect add-on)
comment:17 Changed 7 years ago by calvinhp
FWT Vote: +1 much needed and the current implementation makes Plone look low end compared to other similar CMSes.
comment:18 Changed 7 years ago by esteele
Approved by FWT vote.
comment:24 Changed 7 years ago by timo
comment:25 Changed 7 years ago by ldr
comment:26 Changed 7 years ago by cjohansen
No accessibility issues created by new code compared with baseline. Code tested with FAE ( http://fae.cita.uiuc.edu/).
comment:27 Changed 7 years ago by esteele
Your PLIP has passed the Framework team's initial review. Feel free to discuss any suggested changes either here in the PLIP ticket or on the mailing lists. Final deadline for this PLIP is set for September 30.
comment:28 Changed 6 years ago by timo
comment:29 Changed 6 years ago by timo
ready to merge.
Two issues left:
- Clear and rebuild the catalog looses all the comments.
- Comment objects are not indexed (only Plone 4, Plone 3.3 works fine).
comment:30 Changed 6 years ago by ldr
Looking at it again today:
- @@moderate-comments shows no comments to moderate (I assume this is the indexing bug).
- I think it should use the green tabs instead of the fieldsets.
- whichever way it needs to tal:define="dummy python:request.set('disable_border', 1)" (for green tabs generate your own markup for them, for an example see the users and groups control panel)
- Two "Login to add comments buttons show up" (the second should probably only show if a comment is displayed)
- Anonymous commenting bypasses moderation.
comment:32 Changed 6 years ago by timo
comment:33 Changed 6 years ago by rossp
This PLIP is on esteele's "updated reviews (or the reviewers have indicated that their opinion has not changed)" list but I can't see any update. Additionally, the one review is very much incomplete as the reviewer notes. As such, I don't think this PLIP has been adequately reviewed.
FWT vote: -1 for merging
comment:34 Changed 6 years ago by alecm
The indexing issue seems pretty serious and the review doesn't cover many of the critical issues. I think we unfortunately need to postpone this one. -0
comment:35 Changed 6 years ago by timo
comment:36 Changed 6 years ago by esteele
- Status changed from assigned to closed
- Resolution set to wontfix
This PLIP has been rejected for merging into Plone 4.0
The final vote was: Alec Mitchell 0 David Glick 0 Erik Rose - Laurence Rowe +.5 Matthew Wilkes - Ross Patterson -1
The Framework Team felt that the product was not finished enough to be merged at this time. I'd encourage you to continue to pursue your work as an add-on product and please resubmit this PLIP for a 4.x branch if you feel it appropriate. Thank you for your hard work.
comment:37 Changed 6 years ago by esteele
- Status changed from closed to reopened
- Resolution wontfix deleted
- Milestone changed from 4.0 to 4.x
comment:38 Changed 6 years ago by ldr
- Milestone changed from 4.x to 4.1
It is now being used on a couple of sites in production by Jarn. Only problems seem to be related to plone.z3cform / z3c.form patterns changing.
comment:41 Changed 6 years ago by esteele
Your PLIP has been accepted for consideration for Plone 4.1.
Framework Team voting on this PLIP was: Alec +1 Craig +1 Elizabeth +1 Laurence +1 Martijn +1 Matthew +1 Rob +1 Ross +1
The initial implementation deadline for your PLIP is October 1st, 2010. The Framework Team would certainly appreciate you finishing beforehand so that they may begin evaluating it as soon as possible. Announce its readiness here once your implementation is ready for review.
comment:42 Changed 6 years ago by timo
comment:45 Changed 5 years ago by rossp
Tests from Hudson for your enjoyment: https://hudson.plone.org/job/PlonePLIP%20-%20Tests/7/
comment:46 Changed 5 years ago by timo
Hudson tests with test history, pylint, and zptlint: http://hudson.zmag.de/hudson/
comment:47 Changed 5 years ago by rossp
Sorry, I should have been clear, this is hudson running bin/xmlalltests in plone-coredev with your PLIP's buildout profile applied. Note that some tests fail under your PLIP than the baseline here:
https://hudson.plone.org/job/Plone4.1%20%E2%80%93%C2%A0Tests/29/
Those additional failures need addressing.
comment:48 follow-up: ↓ 50 Changed 5 years ago by eleddy
comment:49 follow-up: ↓ 56 Changed 5 years ago by cah190
comment:50 in reply to: ↑ 48 ; follow-up: ↓ 51 Changed 5 years ago by timo
Replying to eleddy:
(In [46009]) review improved commenting ifrastructure. refs #9288
- In catalog.py, there is a TODO on the effective date. Are comments going to have an effective date or... why would this be implemented?
Effective date is set to creation date now. We might use this in the future.
- In the control panel, this is listed as an add on configuration but should go under a core plone configuration
- When editing in the control panel view, submission redirects to site setup page instead of back to the same form. This is at worst annoying but the standard for editing these forms is to redisplay the form itself.
- In the configuration panel, the "Comment text transform" field needs a description. What is intelligent text? When I select that how come the comment form still says plain text formatting?
- In the configuration panel, email notification fields should be disabled if a mail host has not been configured. Also, who is the moderator? How is this email address set?
- Note that this needs to be installed currently. I'd like to see a configuration where this is already done by default before the other reviews
These issues have been fixed in the trunk.
- There is something funky with the perms. I have no idea whats up. I can't add a comment with "Authenticated" permissions. When not logged in, the content type says "login to add comments". So I log in and then I still can't add comments. When I click allow anonymous comments, I can add comments but I can't add them when I am authenticated as a basic user with "Authenticated" permissions.
pad currently also checks for the 'Member' role. I'm not sure if the "Authenticated" permission should be sufficient to add comments. Though, I agree that this is an issue we have to work out. Right now, logged-in users without the "Member" role should at least see a message that tells them why they can't post a comment. Allowing authenticated users to post comments is also a valid option.
- Moderating comments by changing the workflow is gross. I think it's work the extra effort here to add a moderate comments checkbox to the add on configuration.
- In the discussion settings, globally enabling comments is insanely confusing. I don't even understand what it does. I think that this should either do what it says - "Globally enable comments" - or remove it.
- Removing a comment at the top level of a thread removes all comments underneath. This isn't ok and I think will lead to some frustration. I'm not sure how this reworks the commenting threads and display et al. I have seen in practice that deleting a potentially offensive comment just replaces the content of the comment with a message that says "This comment has been deleted by the moderator." This keeps the flow of conversation going and doesn't make people mad when their potentially relevant comment is deleted.
- The delete button to the far right of the comment is insanely confusing. I think this could use some UI review
I forwarded these issues to the UI mailinglist for discussion. I'm happy to change the UI after this discussion, if necessary.
comment:51 in reply to: ↑ 50 ; follow-up: ↓ 52 Changed 5 years ago by eleddy
Replying to timo: Nice work! I am super gung ho about authenticated being able to comment. In default installs you will rarely see authenticated users who aren't members and in custom environments using the member role is unlikely. Curious what others think.
Thanks!
comment:52 in reply to: ↑ 51 ; follow-up: ↓ 53 Changed 5 years ago by timo
Replying to eleddy:
Replying to timo: Nice work! I am super gung ho about authenticated being able to comment. In default installs you will rarely see authenticated users who aren't members and in custom environments using the member role is unlikely. Curious what others think.
Thanks!
I checked the implementation and added some tests and documentation. plone.app.discussion basically checks for the 'Reply to item' permission to decide when to show the comment form. By default, this permission is granted to the "Member", "Reviewer" and "Manager" role but not to "Authenticated". If integrators want to allow discussion for "Authenticated" they can just add this permission to the role. Though, I agree that this could cause confusion when the user is authenticated and discussion is enabled.
comment:53 in reply to: ↑ 52 ; follow-up: ↓ 54 Changed 5 years ago by rossp
Replying to timo:
Replying to eleddy:
Replying to timo: Nice work! I am super gung ho about authenticated being able to comment. In default installs you will rarely see authenticated users who aren't members and in custom environments using the member role is unlikely. Curious what others think.
Thanks!
I checked the implementation and added some tests and documentation. plone.app.discussion basically checks for the 'Reply to item' permission to decide when to show the comment form. By default, this permission is granted to the "Member", "Reviewer" and "Manager" role but not to "Authenticated". If integrators want to allow discussion for "Authenticated" they can just add this permission to the role. Though, I agree that this could cause confusion when the user is authenticated and discussion is enabled.
I think current behavior in the existing Plone commenting implementation is that Authenticated can add comments, such as is necessary for OpenID login (OpenID users don't have the Member role). If this is correct, then I think changing this behavior by not assigning "Reply to item" to Authenticated is incorrect. I think unless there's a really compelling reason, current behavior should be maintained.
comment:54 in reply to: ↑ 53 Changed 5 years ago by timo
Replying to rossp:
I think current behavior in the existing Plone commenting implementation is that Authenticated can add comments, such as is necessary for OpenID login (OpenID users don't have the Member role). If this is correct, then I think changing this behavior by not assigning "Reply to item" to Authenticated is incorrect. I think unless there's a really compelling reason, current behavior should be maintained.
Ok, I will assign "Authenticated" the "Reply to item" permission then.
comment:55 Changed 5 years ago by timo
comment:56 in reply to: ↑ 49 Changed 5 years ago by timo
Replying to cah190:
- The plone.app.discussion egg depends on a uuid egg that does not
appear to be used directly anywhere.
pad uses plone.app.uuid (which depends on plone.uuid) to generate unique ids in Plone. There is just no need to call the code directly. There is a separate PLIP for the uuid package.
- The plone.app.discussion egg also depends on
collective.autopermission; is this necessary?
This is necessary for Plone 3, it can be removed once pad is merged into Plone 4.x.
- I received one error running plone.app.discussion tests: importing a
Duplicate profile ID for Products.CMFUid:default. I am not sure this is plone.app.discussion's fault, but may need to be looked at if we decide to merge. Otherwise all plone.app.discussion tests pass and have reasonable coverage.
I don't think this is related to pad.
- Installing plone.app.discusion results in a deprecation warning "An
icon for the 'controlpanel/discussion' action is being added to the action icons tool. The action icons tool has been deprecated and will be removed in Plone 5. You should register action icons directly on the action now, using the 'icon_expr' setting."
Fixed.
- Replying to comments appears to be impossible when JavaScript is
disabled. Only new top-level comments can be left.
This was a concious design decision. We move the comment form around instead of loading it with AJAX-calls on request. I think it is sufficient if the basic functionality works if Javascript is disabled.
- Users who are only Authenticated (i.e. not having the Member role)
cannot leave comments, even if they log in using the "log in to leave comments" button.
Fixed.
- Deleting a comment also deletes all replies. I expected a placeholder
or empty space with the replies being preserved. Perhaps we need a way to blank out a comment that preserves replies?
This is the default behavior of the old commenting system. Though, I agree that a placeholder would be a nice feature (that can be implemented in the future).
- Allowing anonymous comments is only available as a global toggle for a
site. I can see people wanting to enable it per type or even per object as the commenting functionality is controlled.
I know, I have tons of feature request waiting to be implemented. :)
- Changing workflow on the comments to enable moderation is a bit
strange. It seems like the configlet should be able to do this.
Done.
- The "Globally enable comments" setting in the configlet is somewhat
confusing. Perhaps it would make sense to reverse the checkbox and make it a global killswitch instead? Or even just get rid of the global toggle entirely.
This has been discussed on the fw/ui mailinglist. Commenting should be disabled by default. Though, I agree that this setting is confusing when using pad as an add-on product.
- The moderation seems reasonable, though it's strange to allow Managers
to reply to unmoderated comments, which can then be deleted, taking out the replies in the process.
So you want to disallow Managers to reply to unmoderated comments?
- There should be a way to whitelist users/roles/groups so their
comments do not require approval. Only requiring moderation for anonymous comments is a typical workflow.
New feature. Beyond the scope of the plip.
- The viewlet for the commenting UI does not appear in
@@manage-viewlets, which is unexpected.
It does. It just does not appear on the portal root (because it is not registered for portal root).
- Why is the Moderate Comments user action always visible, even when
moderation is disabled?
Fixed
- catalog.py has a Todo item in the effective method.
Fixed.
- conversation.py has an XXX item about removing child comments that
should be addressed.
I have to ask Lennart Regebro about this. He added this XXX.
- browser/comments.py has an XXX comment that should probably be a BBB
comment instead.
Fixed.
I do not like seeing the "Moderate Comments" so highly visible in the user actions when moderation is disabled by default and requires changing workflows to enable. It seems like the configlet should be able to change moderation settings, perhaps by having a three-state control that allows moderation to be disabled, enabled with standard workflow, or enabled with custom workflow. When disabling or enabling with standard workflow the configlet should change the workflow for comments automatically. The enabled options should make the moderation action visible. And the enabled with custom workflow options should probably activate some helpful text in the configlet suggesting the workflow be set manually.
This has been fixed. Please take a look at the current implementation and let me know what you think.
comment:57 Changed 5 years ago by timo
comment:58 Changed 5 years ago by timo
comment:59 Changed 5 years ago by timo
The plip9288 is currently broken because of a change in plone.app.registry: http://dev.plone.org/plone/changeset/46273/plone.app.registry
comment:60 follow-up: ↓ 61 Changed 5 years ago by timo
The buildout is fixed. Plip9288 is ready for the next review.
One test still fails with "KeyError, 'Duplicate profile ID: Products.CMFUid:default". Though, I don't think this is a plone.app.discussion error.
@eleddy, @cah190: would you consider to take a second look?
comment:61 in reply to: ↑ 60 Changed 5 years ago by davisagli
Replying to timo:
The buildout is fixed. Plip9288 is ready for the next review.
One test still fails with "KeyError, 'Duplicate profile ID: Products.CMFUid:default". Though, I don't think this is a plone.app.discussion error.
I made a fix in plone.testing this morning which should fix this error. Can you please confirm?
comment:62 follow-up: ↓ 63 Changed 5 years ago by nd51
For commenting in Plone to be truly useful, an essential feature is that moderating of comments needs to be able to be done by something like the page owner, or, everyone that has manage rights on that page.
The situation where a single site administrator is the comment moderator would only work on sites with a small userbase. If you have many 1000s users, then obviously you need those users to be able to moderate comments made on their pages without the sys admin or site owner being involved.
This also suggests that an option needs to be available to have emails sent automatically to either the owner of the page, or all people with manage rights on that page (or perhaps some other way of people declaring an interest in comments on that page).
We have funding to fix to do this and could fund a polished release of plone.app.discussion if it contained the above feature and was 3.x-compatible.
We have attempted to get this done via Matous Hora of Fry-IT. Apparently Matous spoke to Timo at the Plone conference, who was not keen on adding such a feature into the plone.app.discussion. We're not sure why that was.
We are firmly of the opinion that Plone desperately needs "Wordpress-quality" commenting, and that that includes moderation by individual users other than the site admin, and we do have funding to get this done. We are not keen however on doing this via patches on top of patches and plugins on top of plugins. We think it should be a core feature of Plone.
Any takers /comments on doing this? Cheers, Nick Davis, University of Leicester
comment:63 in reply to: ↑ 62 Changed 5 years ago by timo
Replying to nd51:
We are firmly of the opinion that Plone desperately needs "Wordpress-quality" commenting, and that that includes moderation by individual users other than the site admin, and we do have funding to get this done. We are not keen however on doing this via patches on top of patches and plugins on top of plugins. We think it should be a core feature of Plone.
I agree that this use case is important and that plone.app.discussion has to support this at some point. Though, right now I focus on getting p.a.discussion into Plone 4.x (and to make a 1.0 release). I think this was basically what I told Matous at the Ploneconf.
I'm happy to assist any efforts to add this feature to p.a.discussion as a core feature. Feel free to contact me directly (contact@…).
comment:64 Changed 5 years ago by nd51
Timo , thanks for the reply and we will contact you directly about this. :)
comment:65 Changed 5 years ago by esteele
- Status changed from reopened to closed
- Resolution set to fixed
Merged