Getting comments to work in a Plone 3 to 4.1.5 upgrade

published Jul 02, 2012 01:55   by admin ( last modified Nov 09, 2012 11:56 )

 

Summary

The upgrade machinery from Plone 3 to Plone 4.1.5 does not upgrade the comments, you need to do that manually.

Furthermore, folderish content types may find their commenting disabled. Read on for how to fix this.

 

I upgraded a customer's web site from Plone 3 to Plone 4, and even though commenting seemed to work fine, while commenting it did not show the same context as on Plone 3. Starting up two stock Plone sites, one with Plone 3 and one with Plone 4 showed that you should indeed see context.

What had happened was that the commenting part of the site had not been upgraded, and this left the commenting system in a usable but limited state. The Plone upgrade machinery, which for the most part in my experience does a good job, had missed out on upgrading the commenting part. See this bug report:

https://dev.plone.org/ticket/12184

It also lists the remedy:

In portal_setup / Import select Plone Discussions from profile-dropdown. Click "Import all steps" at the bottom

Once you've done that, you need to visit the Discussions configlet, enable commenting on the site and update all comments to the new system:

 

If you have folderish content types, that may not be enough. The new commenting system will not allow comments on folderish content, from conversation.py in plone.app.discussion.browser:

# Always return False if object is a folder
        if (IFolderish.providedBy(context) and
            not INonStructuralFolder.providedBy(context)):
            return False

Hmmm... There are two ways around this, either make sure that your content types have the interface INonStructuralFolder, or make a copy of conversation.py and simply delete the above if clause in the copy. I wasn't sure what knock-on effects the INonStructuralFolder interface might start in relationship to how the types are being used, so I made a copy of conversation.py, and stuck it in my custom skin product:

<!-- Conversation view -->
    <browser:page
        name="conversation_view"
        for="Products.CMFCore.interfaces.IContentish"
        layer="..interfaces.IThemeSpecific"
        class=".conversation.ConversationView"
        permission="zope2.View"
        />

The layer declaration there seems to overpower the layer declaration of the original conversation_view stanza:

<!-- Conversation view -->
    <browser:page
        name="conversation_view"
        for="Products.CMFCore.interfaces.IContentish"
        layer="..interfaces.IDiscussionLayer"
        class=".conversation.ConversationView"
        permission="zope2.View"
        />

One could also have used an overrides.zcml instead of using a layer to override.