I’ve run into a slight problem with the Staticize caching plug-in I was using to speed up WordPress on this site. It seems that $post->post_date isn’t correctly calculated on cached entries, even when you put them “outside” the cached page, and this screws up the time display on individual entries.

Here’s the details. On my permalinks pages, I display a relative publication time, e.g., “Posted 3 days 27 minutes ago”, using the Dunstan’s Time Since plug-in from Binary Bonsai. This works fine when the Staticize plug-in is disabled, and it works fine when Staticize is enabled, but only the first time the page is displayed, i.e., when it’s not served out of the cache. However, upon reloading, the page is served from cache, and the relative time displayed changes to the time since midnight.

Now, since this relative time will change, minute by minute, it has to be outside the cache, or it won’t update. Staticize has an easy way to accomplish this using simple tags. In my index.php page for WordPress, to display the relative time I have:

Posted <!--mclude timesince.php--><?php require('timesince.php'); ?><!--/mclude--> ago

The timesince.php file is also pretty simple, just a quick calculation to emit the relative time:

<?php $entry_datetime = abs(strtotime($post->post_date) - (60*60*8)); echo time_since($entry_datetime); ?>

This technique tells the Staticize plug-in to process the include file every time, not just the first time. In theory, this would allow the relative timestamp to be calculated each time the page is served, and thus always be correct.

But I think that when Staticize is enabled, and determines that a page is in the cache, $post isn’t fully set for that page, and so the value of $post->post_date is meaningless, or it actually has no value at all, and so the functions above just calculate from the current date.

At any rate, for now the site doesn’t need caching to keep up, so I’ve turned off Staticize until I can decide if I care more about displaying the time since or about being ready for a traffic spike.

I spent a couple of hours yesterday working on a few last lingering details for this site. The main changes I wanted to make were to upgrade to the latest version of WordPress (a minor security update), make sure I was using the latest version of the Kubrick template (I was), and most importantly, fix the problems I was having with the Kubrick comments form, which is a lot cleaner and nicer than the standard WordPress version.

It turned out the issue was a couple of the PHP “open” tags — the text tokens that are used to signal that what follows is PHP code, not HTML code. The Kubrick template (at least as of version 1.2.6) uses the standard “full” tags almost everywhere, but there were a few instances where the developer used the short versions. Since I have short tags disabled on my server, it was causing a parse error, the end result of which was that the comments form could not be displayed. Fixed.

Now that I’ve got comments working, I switched to allowing comments on postings by default, and letting them post without moderation first. We’ll see how that goes.

Because, the weblog world is dealing with a plague of comment spam these days, from “search engine optimization” scumbags who are trying to promote their (or their clients’) websites. So I’ve also installed and enabled a number of comment spam plug-ins. We’ll see how that goes, too, though I’m somewhat pessimistic, for a slew of reasons. Probably I’ll have to turn moderation back on at some point…

And I installed a new caching plug-in, which should theoretically improve the performance of this site. Not really a problem with the volume of visitors I’m getting today, but you never know, and having the plug-in active will hopefully prevent unpleasant surprises.