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 »
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.