Using knotes shared weblogs to handle Plone portal comments
16-January-2005
permalink comments (2) forum (2) email thisThe release of a fully productised and robust core knotes has fallen a bit behind schedule recently because we've been very busy making use of it in some of the community portals we maintain, and in adapting it to new purposes. One very interesting use we've been trying out is as a framework for portal comments. Our users have always hated the default Plone talkback mechanism: 'Discussion Item' entries do not allow rich text, active links, attachments, or post-submission editing, and they tend very much to get orphaned. On the other hand, the idea of posting a comment is very easy and intuitive for most users, there is an affordance to do so right in the pages, and it provides a simple means for user to post their own writing in a prominent place (without understanding workflow, etc :o). We briefly tried using CMFBoard as a portal_discussion handler last year, but its treatment of the issue was profoundly misconceived, not to mention buggy and veeeery slow, and was disastrous in real sites. So we've made do so far with either turning off discussion_allowed, or with the robust but feature-poor default portal_discussion. Last week, we started experimenting with replacing add-a-comment with shared weblogging, and demonstrated this to some of the key editorial people in our main sites. For the first demos, all we were doing was displaying trackback details for pages instead of comments; as luck would have it, an interesting weblog post had been made about an article in the NGRF site, and the editors were blown away when they saw external commentary summarised in their page.
So we decided to go ahead with a very quick and dirty takeover of portal_discussion. We've done this in two new sites, and one site that already had extensive comments (we wrote a little script to make new weblog posts and replies to them from existing comments).
How to set up knotes for portal comments ( the quick & dirty way )
- 1 - make a new weblog to hold the comments
- - This one is easy. Just add-item:WebLog wherever you can make Plone content. Of course, you'll probably want this somewhere prominent in the site content hierarchy, and prominently linked-to, perhaps from site_actions.
- 2 - give all site members contributor privileges to that weblog
- This is a bit tricky at the moment. It is very easy to give contributor permissions to a group or a set of members using the local role form (Weblog Contributor role), but giving all members the required permissions is a bit harder. We have implemented something similar for the moderation interface for discussions in knotes, but not yet for blog entries. You have to go into the ZMI for the weblog you want to allow all members to post to (not for the entire portal!), open the Security tab, and manually tick the 'member' column checkbox for the following permissions:
- Add Portal Content
- Add KNBlog
- Add KNLink
- Add KNExFile
- 3 - turn off the display of the 'Reply' content-action
- We always hated this pesky content_action anyway, since it forces a box around content for logged in members who can only choose between the view and reply tabs. If you are going to replace talkback with blog-this-page by changing the viewThreadsAtBottom.pt template, you have to get rid of the competing action from default talkback machinery. In the ZMI for a portal, just open portal_discussion, then actions, and untick the 'visible' checkbox for the reply action. See the screenshot:
- 4 - customise the viewThreadsAtBottom template.
- The viewThreadsAtBottom.pt template is what is called in page rendering by Plone to display the comments and add-comment etc content. A very crude, but working, replacement template is attached to this post: that template displays trackbacks instead of comments, and has as its form action for Add-a-comment the creation and editing of a new blog_entry, with initial link details filled in with the details of the page it is called from. A list of weblogs in the site which the member can contribute to is also provided; the comment will be posted into the chosen blog.
- 5 - import any existing comments
- We have written a little python script to convert comments into weblog entries, and a little page template to call it from. The script takes as an argument the weblog to post into, which you enter from the form field in the rendered template. Run the convert_comments template FROM THE DOMAIN NAME OF YOUR SITE (eg
www.my.domain.edu/convert_comments), and it will create weblog entries for all top-level comments (tracking back to the pages the comments were about), and making replies (as Discussion, not blog entries) to those new entries from any comments-on-comments threads. It will add entries in the members SQL table where needed. We've tried this in a production site, and it certainly seemed to work. It may take some time to run if you have many hundreds of existing comments - try it in a copy first! - 6 - remove any aggregations you may have made of comments, for instance portlets
You probably do not have to worry about this, but if you have been displaying information about recent comments, or adding comments-on-items to listings, you'll have to take those out or change them to get their information from the trackback machinery instead of the talkback machinery (ie grabbing trackback entries from knotes' SQL methods instead of comments from portal catalogue :o) It is very easy, using CMFSin, to include a recent_comments portlet from the RSS for the weblog you use for comments. It is your choice whether to use the RSS with-discussion or without (knotes provides both options for syndication of blogs). Use the RSS rather than the atom feeds for CMFSin.
Ta-Da! In these simple steps, you've got a whizzy weblog behind your portal comments machinery. This makes it a lot easier to see comments as a whole, to post items which are not specific to a particular page, and to give a sense of community and activity. As a very useful side-effect, your site's pages will display any trackbacks they may receive from other sites, which can add a real sense of being part of a wider community of communities.
You can see this in action at the National Guidance Research Forum site. NB - this links to the NGRF Community Comments weblog instead of the NGRF top of site; I did not want to pollute the top-of-site trackbacks with links to technical posts like this (and knotes does not display top-of-weblog trackbacks yet :o)... please do not send trackback pings from technical blog entries to the NGRF top of site.
2 Replies (comments)
1 Update! The moderation form can be used to give all members add-entry rights
It is no longer necessary to use the ZMI security tab to set a weblog upso that all logged in members of the site can add entries.
The blog_moderate_form allows complex and powerful permissions scenarios to be set up through the knotes/Plone interface. We will be including a link to this form (acting in context of entries folder) very soon... as sooon as all the scenarios we can think of work well.
It is still - as of this writing - necessary to go into the ZMI to turn off display of the 'reply' content action tab, though.
2 hmmm... trackback comments and renamed TB target... how can we fix?
not so much an issue for us now, but a problem with the trackback method of comments-association
what if someone renames the thing being commented on? (ie changes its id) - not all that uncommon
if its one of our own objects we could add something to manage after paste (assuming a rename is a cut/paste)
is it possible to do something like that globally?
or to add a manage after paste to the objects as they receive trackbacks ( we *do* grab the objects as we process - except for plan to allow pseudo objects to receive trackbacks for category discussion :o)
bit of a thorny one for later, but we should document a plan for it
Linking and trackbacks
When linking to this weblog entry, please use the 'permalink', which is http://www.knownet.com/Members/mmalloch/blog/entries/2306356579

