• iqpp.plone.commenting (aka EasyCommenting)
• collective.disqus
• quintagroup.plonecomments (aka qPloneComments)
• collective.discussionplus
• plone.app.discussion

Hope this will kick off a discussion with the product authors / people using them and will help others to decide which package (not) to use.

Summary

I did not look really deep into all of these packages (installed and tested plonecomments and plone.app.discussion) so please feel free to comment and put me into the right direction.

collective.disqus looks promising and has great advantages in the area of social web.
on the other side comments are not as well integrated into plone (eg search) and it’s hard or even impossible? to implement custom notifications or other additional features within your application.

quintagroup.plonecomments is a very mature product with lots of configuration options and notification features.
Editing of comments is possible (maybe there should be a way to turn this evil? feature off).
Comments are compatible with standard plone comments (right?) so they might be migrateable to the new commenting system for plone 4.x (plone.app.discussion).

collective.discussionplus peps up plone’s standard discussion items with workflow while keeping them migrateable to plone.app.discussion later. it’s more leight-weight than plonecomments with the downside of no notifications and less configuration options.

plone.app.discussion is currently in alpha state but offers basic configuration options and a moderation view for batch managing comments. Its much more leightweight than standard plone comment types (plonecomments and collective.dicsussionplus are using). I don’t know how many people are contrubuting currently and i hope timo is still motivated after his plip did not make it into plone 4.0.

I’m not sure if it’s a good idea to use plone.app.discussion in alpha1 state on production servers (comment of the authors welcome). But it seems by using collective.discussionplus or quintagroup.plonecomments (not sure about that) one can migrate all comments with the migration script of plone.app.discussion as soon as there is a more stable release or it even is shipped with plone 4.x

This is just a quick overview, more details for each package follow below. There is a project on coactivate about commenting in plone, too. Founded in 2007 it currently seems to be not very active or completely up to date (eg products like disqus missing) but there are reviews of some other commenting products and a collection of commenting related usecases.

iqpp.plone.commenting

Seems unmaintained (has not been updated on pypi since october 2007), so i did not look into that further.

Martin mentioned in his blogpost on commenting that its comparable to PloneComments and he used it for a big deployment.

collective.disqus

homepage: http://plone.org/products/collective.disqus
demo: http://lichota.pl/blog/

Uses the webservice disqus.com/ so your comments are stored “somewhere in the cloud”.
There is an export for comments though, so you’re able to migrate back to plone comments with some coding.

Seems that you can only set one language in the account settings, so it might won’t work for multilingual sites.

Users can comment using their twitter, facebook, openid,… accounts and choose whether or not to get email notifications on new comments / replies. Comments can be posted on Social Networks with might generate more interest and therefore visits to your site.

Comments are centrally managed using disqus.com.

Since comments are not stored in your plonesite they are not searchable by default.

quintagroup.plonecomments

actively developed (latest release 4.1.1 nov, 2009) and already there for many years.

has it’s own api but pretends to internally use plone’s standard commenting types so migrating to plone.app.discussion might work.

captcha support via quintagroup.plonecaptchas (did not test that)

Configlet for configuring settings (eg activate moderation, or enable anonymous comments) and managing pending comments .

Users with role DiscussionManager can publish comments via publish button below the comments, and can access the configlet and review list (/prefs_recent_comments_form) too.

Notifications for new pending comments are only sent to one single address configured in the control panel.
After Managers have approved the comment users get a notification that their content has been commented and commenter that his comment got published. Commenters get notifications for replies to their comment too (these notifications can be turned on/off in configlet)

Logged in or respectively anonymous users can report spam comments. A configuration option enables an “abuse” button that opens a form users can submit with an optional comment why they consider this comment spam. An email is sent to the notification address.

collective.discussionplus

Martin’s interim solution to enable moderation of standard plone comments.

Uses DCWorkflow, adds indexes to catalog to search for comments of a certain author or the number of comments for a content item. Events are fired for comment creation and removal, so on can hook up email notifications on workflow transitions and/or these events.

In his blogpost on commenting in plone Martin outlined the reasons for not using EasyComment or PloneComments and writing discussionplus.

According to the readme it’s likely not to work with plone4.
However comments should be migrateable to plone.app.discussion since they’re standard plone comments.

plone.app.discussion

Google summer of code project outlined and mentored by martin and mainly developed by timo.

Aimed to be the new default commenting solution for plone 4.0 but the plip9288 has been rejected in october since the framework team considered it not finished enought.

project page: http://plone.org/products/plone.app.discussion/
tracker: http://www.pivotaltracker.com/projects/15135
online demo: http://gsoc.timostollenwerk.net/

For my research I used version 1.0a2 (rev31840) in the development buildout

Configlet to configure if anon comments are allowed, which captcha to use, whether or not to show the commenter’s image and a toggle to switch commenting off globally.

Moderation is configured in the types control panel by setting the workflow of the Comment type.

Captcha support via plone.formwidget.(re)captcha

Migration script for importing existing plone comments is in place (did not test it)

Moderating comments is done using a site action (@@moderate-comments)

Email notifications are not yet available, but planned for 2010 (according to the tracker)

Aclark recently worte a blogpost about supervisor and asked for a way to make buildout generate the supervisord.conf and a paster template that includes supervisor.

Wiggy just checked in ZopeSkel2.0 with supervisor added to the plone_hosting template.

Since it’s added using zc.recipe.egg the supervisord.conf has to be created and modified manually and is not generated with bin/buildout.

This is what collective.recipe.supervisor does for you.

The following setup worked fine for me:

[varnish-build]
;find newer versions on http://varnish.projects.linpro.no/
recipe = plone.recipe.varnish:build
url = http://switch.dl.sourceforge.net/sourceforge/varnish/varnish-1.1.2.tar.gz

[varnish]
recipe = plone.recipe.varnish:instance
bind = *:6181
backends = 127.0.0.1:8180
cache-size = 512M
# foreground is needed for supervisor to control varnish correctly
mode = foreground

[supervisor]
#recipe = zc.recipe.egg
#eggs = supervisor
recipe = collective.recipe.supervisor

port = localhost:9001
user = admin
password = admin

programs =
    10 zope ${instance:location}/bin/runzope ${instance:location} true
    20 varnish  ${buildout:directory}/bin/varnish  true

Make sure you’re starting supervisor with root privileges.
Otherwhise varnish will be started but supervisor won’t recognice it’s running.

Now you just add supervisor to your default runlevels, instead of adding every service of your instance.:

cd /etc/init.d/
ln -s INSTANCE_HOME/bin/supervisord project-supervisord
ln -s INSTANCE_HOME/bin/supervisorctl project-supervisorctl
update-rc.d project-supervisord defaults

control the services using /etc/init.d/project-supervisorctl

shutdown supervisor and all started services: /etc/init.d/project-supervisorctl shutdown

However, drag an drop has the limitation that in a batched view (20 items per page), you can’t move the item on position 20 to 21. You can swith off batching in folder_contents view in recent versions, and there are also patches that enable drag&drop again (see plone3 user manual and issue 7202).

When handling a lot of items in a container, i can think of other useful options such as “move to top”, “move to bottom”, “move n items up/down” or even “sort alphabetically asc/desc”.

In 2006 i wrote a python script for making this (except of sorting) possible for a customer.
It has been ‘released’ in our public svn repository today and I hope this will make other people’s live easier, too:

https://svn.webmeisterei.com/repos/public/plone-tools/moveObjToPos/trunk/

I’m thinking of a more polished version as a small plone package (maybe even with i18n) and adding support for sorting items alphabetically.

Does anybody know if there are already products available that do the same thing?

Are there plans that plone will support a feature like “show items alphabetically sorted” or “ordered reversed” in a folder’s views?

If your folder does contain custom or third party content types that have a space ” ” in their meta_type (see portal_type/ ‘Product meta type’) you most probably ran into the same problem:

If you defined the meta_type of your content type in profiles/default/types/My_Type.xml like that:

<object name="My Type">
  ...
  <property name="content_meta_type">My Type</property>
  ...

objects of your type will have ‘MyType’ as meta_type:

>>> _ = folder.invokeFactory('My Type', 'mytype')
>>> folder.mytype.meta_type
'MyType'

Products.Archetypes.OrderedBaseFolder.moveObjectsByDelta only takes CMF-Types into account.

This is done by using only those ids returned by getCMFObjectsSubsetIds which lists all meta_types registered in portal_types and compares them to the meta_type of the objects contained in the folder.

Since these differ for meta types containing spaces you’ll experience very strange behaviour when reordering items in a folder containing some objects of type ‘My Type’.

Solution:

In case you’re responsible for the product, simply change the GS profile for the portal type from <property name="content_meta_type">My Type</property> to <property name="content_meta_type">MyType</property> and reinstall the product.

In case you’re using a third party product you’re out of luck.
This is why I filed a bug (https://dev.plone.org/plone/ticket/8161)

]]> http://archiv.webmeisterei.com/friessnegger/2008/05/26/meta_types-containing-spaces-break-folder_contents-sorting/feed/ 2 http://archiv.webmeisterei.com/friessnegger/2008/04/14/installedcfg-can-be-evil/ http://archiv.webmeisterei.com/friessnegger/2008/04/14/installedcfg-can-be-evil/#comments Mon, 14 Apr 2008 08:19:02 +0000 fRiSi http://www.webmeisterei.com/friessnegger/2008/04/14/installedcfg-can-be-evil/

In case you experience strange VersionConflicts on your buildout, this might save you some time:

Today i wanted to update a plone3.0 buildout to plone3.1-rc1,
since i needed static portlets in a project and plone.portlet.static does not work on plone3.0 (see http://plone.org/documentation/how-to/creating-static-text-portlets-in-plone-3.0)

I changed the version numbers in the plone recipe:

[plone]
#recipe = plone.recipe.plone>=3.0,<3.1dev
recipe = plone.recipe.plone >=3.1rc1, < 3.2dev

Changing the version number in a fresh buildout worked out fine, but when running bin/buildout on my existing project i got a version conflict:

VersionConflict:
(plone.recipe.plone 3.1-rc1 (.../plone.recipe.plone-3.1_rc1-py2.4.egg), Requirement.parse('plone.recipe.plone>=3.0,<3.1dev'))

The root of all evli was .installed.cfg in my case. This file contains the dependend eggs and their versions.
In a plone3.0 buildout you can find the following line in .installed.cfg:

recipe = plone.recipe.plone>=3.0,<3.1dev

Solution

delete .installed.cfg and run your buildout again.



Update: This is a bug and might be fixed soon.

]]> http://archiv.webmeisterei.com/friessnegger/2008/04/14/installedcfg-can-be-evil/feed/ 1