Another fun-and-games style problem I’ve come across when using plone.app.blob: sometimes migrations won’t work when converting a standard site’s files over to blobs.

That’s a pretty ambiguious description, but essentially, the error you might see will have a semi-normal traceback to start, and then garbage (contents of a file, presumably) – which, depending on the file size might hurt your browser.  The last part of the (normal) traceback reads thus:

File "/home/buildout/instance/eggs/plone.app.linkintegrity-1.0.11-py2.4.egg/ plone/app/linkintegrity/handlers.py", line 158, in referencedObjectRemoved raise LinkIntegrityNotificationException, obj LinkIntegrityNotificationException

Thankfully, this gives us an excellent pointer to a solution: disable link integrity checking on your site prior to migrating.

The fix/workaround

Head to the Plone Control Panel, and click onto Site.  Uncheck Enable link integrity checks and then run your blob migration.  When you’re done, you can return your site to normal. Or not.  Your choice.  Doens’t seem like there’s any harm with turning it back on once everything’s happy; just something to watch out when migrating content.

Alright, now for today’s problem:  why do two dates that look different when outputted actually end up being the same date?

Answer: I’m not sure, but I’m pretty sure it’s got something to do with the wacky support the above-mentioned 3 products have for timezones.

The background: Plone stores a DateTime object to record a user’s last login time.  It doesn’t really matter what’s purpose is, because Plone (this time) isn’t at fault.  The DateTime gets stored, no worries.  The problem arises when you try to put that value back into a DateTime object.  Now, I’d have thought it’d be as simple as doing this:

dt = DateTime(member.getProperty('login_time'))

And realistically, it is.  Except that printing/using that value – at least for me – results in a time that appears as UTC, but is reported as being in my timezone (aka a time that’s 10 hours behind since I’m GMT+10).

The fix: the time still knows its timezone correctly, so just give it a kick.

dt = DateTime(member.getProperty('login_time'))
dt = dt.toZone(dt.timezone())

Amazingly, doing a comparison (using cmp) between the original DateTime object and it’s ‘corrected’ version actually shows that they’re the same.  Uhuh.

So, you’ve got a website that you’ve made and you’ve used a Flash movie on it.  Okay, no worries.  Now, what if you tried to add a (non-form-element) drop-down menu or some AJAX-ed content into the site, and found the Flash movie actually acted as an overlay?

This problem doesn’t seem consistent.  Different OSs, browsers, and Flash versions don’t indicate consistency – that’s what I’ve seen anyway.  Nevertheless, the problem persists for some users and it’s down-right annoying.

The fix?  Make your Flash code look similar to this:

<object data="my-movie.swf" type="application/x-shockwave-flash" height="100" width="200">
<param name="movie" value="my-movie.swf" />
<param name="quality" value="high" />
<param name="embed" value="transparent" />
<param name="wmode" value="transparent" />
<param name="menu" value="false" />
<img src="alternate.jpg" alt="ARCS - Revolutionising Collaboration" height="100" width="200" />
</object>

That there should be entirely XHTML compliant (and completely cross-browser compatible) code for creating a Flash object on your page that’ll place nice with other content.

Oh dear. Products in Plone that don’t care to uninstall themselves at all when removed. One such product that comes to mind is ZipFileTransport. (more…)

Wow..I just keep hitting these problems. The latest issue is chronicled here: http://dev.plone4artists.org/pm/p/plone4artists/ticket/160

which essentially boils down to this problem when you try and edit a video subtyped File from p4a.plonevideo (or p4a.video or whatever it’s called now): (more…)