Okay. So, anyone out here who’s listening — particularly those overly-enthusiastic users — don’t try to recursively wget your Plone site (or other CMS, for that matter) whilst you’re logged in with an account that can make edits. It will lead to a very bad situation where your site administrator and technical team need to step in and fix your mistakes. For the uninitiated, a loose recursive wget (when logged in with some degree of Edit rights) will hit every link that’s on your pages, and I mean in the (X)HTML source. For a Plone site, this means hitting every “Edit” link, every “Revert to this version” link, and every other link that might be dangerous when clicked randomly. Oh, and if the account you’ve got has admin rights, well, it’s not getting any better and requires the Data.fs to be undone back to before it happened. Here’s how to do that easily.
Continue reading »
So you, like me, have hit a situation where you’ve got a time-sensitive application that won’t run? Maybe you’ve downloaded one of those apps (like a demo) that won’t run after a certain date and time because it’s “expired”. Or else, maybe some other arbitrary time constraint is keeping you from running a Linux (or even Windows) program. On Linux (Ubuntu for me), there’s faketime to the rescue – a very handy tool that does what it says on the box, changes the system time for given command.
Continue reading »
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 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.

User IDs show as comment authors in Plone 4.x after migration from plone.app.discussion
If you’ve migrated your site from earlier versions of Plone to the latest ones in the 4.x series, or else have started using plone.app.discussion earlier than that, you might have come across a situation where comments on your site show user IDs as authors rather than a user’s full name. If you see this anywhere, chances are your comment’s migration didn’t go according to plan, and that the Creator information didn’t get recorded correctly on the comment.
I’ve just written this on the Collective developer docs: http://readthedocs.org/docs/collective-docs/en/latest/misc/upgrade.html#fixing-creator-details-on-existing-comments
The script there should help by stepping through all comments on your site and fixing up the creator details as required. As mentioned in the comments beneath the script, the mileage you get may vary depending on the state of your comments. I found half my site’s comments were fine and half weren’t. Some of mine had no author name, email, or user ID in the relevant fields, and the script there checks for these (and the actual existence of a user after looking up what’s in the Creator property), so that should be enough to sanity-check so it won’t stomp over correct comments.
That said, if for some reason, you happened to have a user with ID david and full name of Administrator, also had a user with the ID of Administrator, and had a comment which had an incorrect Creator but did have the three fields of author_username, author_name, and author_email, then it won’t affect those comments and you might just have to manually fix them up.