Plone 2.1 comment bug

I discovered an annoying bug with plone 2.1 where when you added comments to a piece of content, they seemed to disappear, without throwing an error. It turns out they were turning up in their parent container.

It only occurred intermittently, and seemingly randomly (aren’t they simply the best type of software bug?), but I eventually realised that it started occuring where a folder was set to Allow Discussion by default, and it was occuring where a content item hadn’t previously had any discussion, therefore it was inherting the discussion properties of its parent..

Anyway, I sheepishly showed my head in the plone users IRC channel and was advised to (guess what!) upgrade to 2.1.2 to fix the problem. Got out of there sharp quick before anyone asked me to contribute anything useful.

As per usual simply upgrading to the latest version isn’t always a possibility with a live site, particularly where there are several production sites running on the same zope instance and with no hugely convenient way to create an exact replica for a test run of a migration.

So I installed a fresh instance of 2.1.2 locally (gotta love that clicky button mac osx installer – that’s my type of software installation), checked that the bug was indeed fixed in 2.1.2 and then did some digging, stepped through the code a bit and found that CMFPlone/ had changed slightly. (I’m sure I could have checked some sort of changelog or SVN repository, but without someone to spell it out to me, finding out what/where/when how to do such a thing would probably take me longer than it would to knock up my own commenting system from scratch.

So I swapped the file, refreshed CMFPlone and …Doh!!! something bad…, swapped it back, refreshed and .. Doh!!.. still bad.. panic a bit, ask around if anyone else just happened to be doing something on that zope instance that might be causing the bad stuff, but no… so restarted the zope instance and it started working again, swapped the files again, restarted and lo and behold commenting fixed.

plone 2.1 list all folders set to display as photo album

since plone 2.1 uses folders set to display as photoalbums instead of the CMFPhotoAlbum approach, I needed a way to list photo albums from a portal_catalog query (well, a smart folder actually, but the same thing really)

here’s a solution:-

1. in the zmi go into portal_catalog -> indexes
2. add a new FieldIndex called “layout”
3. reindex the catalog

now you can use layout in portal_catalog queries so a query containing type = Folder, layout=atct_album_view will return a list of folders set to display as photo albums

Videocasting notes

screen casting set up with Godefroid and Nate

This is the first time I’ve attempted to use my mini dv-cam to get some footage of talks and interviews at the snowsprint to use for video casting. Along with Nate Aune of Jazkarta/Plone4Artists, I have been shoving camcorders in people faces, positioning tripods precariously on ledges and bars and trying to get some footage. I’ve already managed to damage my camera when it fell off a chair at least once.

For future reference, here are a few notes:-

Hard disk space

An hours footage works out at about 11gb of disk space when dumped onto my laptop. I usually only have about 10gb free to play with so a large external disk is a necessity (I left mine at home).

Remote control

As I write this, my dv cam is positioned up on a ledge waiting for a talk to start – I have a remote control at home, wouldn’t it be great if I had bought it so I don’t have to start climbing up on chairs to set it recording.

Editing time

Don’t underestimate how much you’ll need, even if you don’t take into account the time it takes to get the footage off the camera (real time) and compressing the end result.

Loads of spare tapes

If you haven’t got the time or disk space to offload the footage, a stack of blank tapes would be useful.


We need to share footage captured on both NTSC and PAL mini-dv cams – I’m hoping hi-quality quicktime exports in some intermediate format should be suitable for this.


Googling around it seems that the ideal format for a video podcast (i.e. suitable for iTunes and video iPods) is mpeg 4, 320 x 240 pixels, 30fps for good quality. AAC audio.


Snapzpro seems to be a good solution for mac osx, especially if you want the result to be in quicktime, so you can cut the footage in with video in iMovie – cheap alternative to camtasia (haven’t tried it yet, although camtasia does swf)

iSight microphone works well for screencasting apparently.

Vnc snooping or screencasting software on presenters machine would be good so a presentation can be filmed with a human element to it and screen footage edited in afterwards, rather than just videoing a projected screen.

Data transfer

firewire cable useful, especially between two macs – one in target mode. USB key also v.handy for transferring smaller files where firewalls or other factors are stopping network file sharing.


Never believe the “time remaining” progress bar in the export dialogue iMovie.

(I wonder how fast a macbook pro will be in comparison?)

Part of the value of Videocasts is their timeliness – it is easy to get bogged down in editing. Before another event like this it would be a good idea to prepare opening screens, title and credit format etc, maybe in an empty project that can be copied and used as a template so footage can be dropped in, trimmed, titles added and exported quickly.

Using powerbooks for transcoding/ compressing is viable, but slow

archived comments

very helpful…

I preferred to thank you for this good article. I by all odds liked every little bit of it…

Kugenie 2011-08-07 04:22:16


love your blog, ,Thanks again….

Pterker 2011-08-08 17:47:42