Tapirtype Blog

I’ve become convinced that those flashy blinking ads are designed to drive page hits. How? I just found myself reloading the New York Times web page five times in a row in the hope that I’d get an ad that wouldn’t compel me to hold my hand over the screen so I could read the actual content without being distracted.

(And yes, I know there’s software to fix that.)

I don’t think most ducks migrate, but this mallard has just about finished migrating tapirtype over to the new Joyent shared accelerator “Myrtle”.

Just a couple more things to test (this post included) and I’m going to declare it done and switch the DNS over.

Ok, I think I have the caching thing figured out. Seems that Smarty (which handles the dynamic publishing—and caching—for Movable Type) defaults to a one hour cache timeout. What Smarty does is write the time-stamp in a header on the cached file along with an expire time-stamp computed by adding an interval determined by the smarty variable $cache_lifetime which defaults to 3600 seconds (or one hour). When retrieving a page, smarty compares the expire time with the time the cached file was built and retrieves the cached file only when the cache has not yet expired.

Why it does this is another matter. One hour seems either far too long or far too short for the life of a cache. It especially makes no sense in the context of Movable Type which seems to clear the cache whenever there is a change to the database, such as saving an entry—whether or not the entry is published—or making a comment (although, not, for some reason, when comments are deleted). Incidentally, I haven’t yet figured out how Movable Type achieves this. I can’t seem to find where in the code it flushes the cache or checks the modification date on the database, however I have empirically determined that this is the behavior.

This caching behavior especially makes no sense for me, since this blog changes, at most, daily. Fortunately, the default cache lifetime can be changed by editing the smarty.class.php file (found at mt/php/extlib/smarty/libs/). At the top of the file, which defines the smarty class, a bunch of default values for variables are set, some of which are overridden by Movable Type when it creates an instance of the smarty object and uses it to display dynamic content, notably the $caching variable which defaults to 0 (off) is flipped on later if you have enabled caching enabled via publishing preferences.

Setting $cache_lifetime = -1 results in a cache that never expires until the Movable Type database is changed, the setting that makes sense (to me, anyway) assuming that the only way the content displayed for a given page will change is if a change is made through Movable Type. This does bring up an important caveat however (although one I haven’t verified), which is that if you have dynamic content on a page that changes based on input other than the Movable Type database, it may not work, or may take some extra effort to ensure that it works.

As I mentioned previously, I recently switched a good portion of Tapirtype Blog—everything other than the front page index and the entries themselves—to dynamic publishing. I’ve been collecting my impressions, although I’m generally waiting for the upcoming move on to Solaris at TextDrive, my hosting provider for any final judgments about performance.

I like the idea of it, but I’m still not sure on all the details of the execution. This is partly because Movable Type uses Smarty for it’s template system, so in order to understand what’s going on, I have to understand both what Movable Type is doing and what Smarty is doing. Note, this isn’t a criticism, I think Smarty is perfect for the job, and I’m glad they didn’t try to reinvent the wheel, making their own php template compiler. The biggest concern when switching to dynamic publishing is that the efficiency equation shifts. During static publishing, it makes sense to make trade offs that make build time just slightly longer for the sake of convenience, simplicity, or feature-fullness. Using dynamic publishing, however, this could lead to intolerable page load times, so caching becomes very important in order to make only the first load any slower.

Smarty has two levels of caching. First it complies the templates into php files on the first request. In theory this should eliminate any disadvantage of a template based system as compared to Wordpress style php “templates”. Second, as pages are requested the output is stored in a cache folder, so the second request for a given page should be able to simply echo that cache file with no computation necessary. Actually there’s a third level of caching, though I’m not sure whether it is a Smarty or a Movable Type feature, which is that the blog will instruct the web browser that the page has not changed since the last request, allowing the browser to fetch it from it’s own cache.

But the difficulty with caching is that any caching system is only as good as it’s ability to tell when it needs to recompute the content. Preferably, the system would be smart enough to understand which pieces of the content have updated and which are still the same, but at the bluntest it must flush the entire cache every time any change is made. And here’s where things have been falling down for me. In a given session, I can sit at the blog, load a bunch of pages, and see that after the first load, the loads get much quicker. However, inevitably, the next day, with no changes made the the blog, I’d find the caches recomputing. With no changes published to the blog, I can’t see why this would be the case. The only thing I could think of was the fact that several trackback requests had come in and were marked as junk, resulting in no changes to the published blog. It would be quite silly if that was causing the cache to reset, but just to test, I’ve disabled trackbacks now. As much as I like the idea of trackbacks, they’ve never really worked out, anyway, and since adding a captcha to anonymous comments, they are my only current source of spam (although none ever get published due to the insistence that the trackback request come from the same IP address to which it points).

Hey, I just noticed that I missed this blog’s birthday.

Sad blog. I’ll have to send it flowers.

I just discovered something odd… MT used to use SmartyPants to translate typography elements (such as quotes and em dashes) when using Textile 2 text formatting (as well, of course, as when using Markdown).

For a moment I thought it had stopped when I saw –– in one of my old entries instead of the — that they should have been translated into. But it’s stranger. Turns out all my static pages, get the Textile right, but don’t use SmartyPants (or any other html entities translator). However, my dynamic pages get it right.

Ummm… Hopefully someone will get on that real soon now, so as to not force me to learn about Movable Type text formatters and take matters into my own hands.

Also, MT seems to think I’m in Mountain time in spite of my best efforts to convince it that I’m in Pacific. Or maybe it stopped respecting daylight savings… Interestingly this only applies to the date applied to entries. The “Last auto-save” message tells me the correct time. shrug

Update (typography fixed): I fixed the typography problem by manually turning SmartyPants on in all of my static templates, adding smarty_pants="1" to the tags that write out content that might have typography elements in them (MTEntryTitle, MTEntryBody, and MTEntryMore). This should have the side benefit of ensuring that all entries get the best possible typography translation no matter the text formatter used. Also of note is that SmartyPants is smart enough to not process within html comments or php code blocks so it won’t break javascript or php code in entries which is important for my galleries.

Still no idea what the time shifted-by-one-hour time-stamp thing is all about, though.

Subtitled: woot, no spam!

So spam was getting kind of silly. Akismet was not catching, well, anything.

Enter the new MT4 options.

I’ve upgraded to MT 4.0.

I thought I’d been smart by trying it locally before upgrading online, but it turned out to be a bit more difficult that I thought it would be. To be fair that’s mostly because I took the opportunity to make a couple of changes. MT 4 has Textile and Markdown built in, including as dynamic php scripts. I know you could install them that way before, but I didn’t want to go to the trouble and that provided a block to using dynamic publishing. So now I’ve enabled dynamic publishing for most indexes and archives other than the entries themselves. I can’t have the entries themselves published dynamically for now because I use php inside entries to publish my photo galleries and that won’t work in dynamic publishing.

I’ve also switched from MTKeyValue to CustomFields. Custom fields isn’t compatible with dynamic publishing either, but it is a bit slicker and I’m working around that for now because I’m only using it to publish the recent photos feature which I publish as a static file that is php-included.

I also started using MTFastsearch and even got it working along side dynamic caching, using mod_rewrite to redirect requests to fastsearch directly to a custom mtview.php script which has the caching disabled. In the process I found out that I don’t entirely understand what is going on with the .htaccess created by dynamic publishing. Many things that I thought should work would not (for instance I had to put the rewrite I just mentioned up at the top right after turning rewrite on), and some things wouldn’t work at all. I seem to have everything but the redirect form the .org site working now.

I also disabled fastcgi for the moment. It seemed to work out of the box, however the memory requirements seem to be even worse than before and I was getting the strange out of memory errors very frequently. The CGI performance doesn’t seem to be too bad right now and we’ll see how things are after the eventual TextDrive transition to Solaris.

All in all, so far, so good. I’ll have to spend some time investigating some of the new features. I got the updated authentication options working (with some difficulty involving the __trans business) except for the option to register directly with the blog, for instance.

Update: One more dynamic publishing snag. It seems that when I delete a comment via the admin interface, the change won’t be reflected on dynamically published pages. It is reflected on static pages, so the actual comment disappears from the entry. But the indexes still publish the cached version with the comment total unchanged. The work around seems to be to jog MT to clear the cache by turning caching off and then back on after deleting a comment. I haven’t tested this with deleting other content, but the process of actually making a comment on the page seems to work just fine.

I was recently trawling through our site logs when I noticed that an IP address registered to Google had been doing an awful lot of searches on this blog lately, which made me think: “Hey, I haven’t googled myself lately. Maybe this site’s gone up in page rank.”

And sure enough, I came to a most startling revelation. Not only is this blog the top result when searching for tapirtype blog (and believe me, this was not always the case), but by at least this one measure, I now appear to be the most prominent Michael Boyle in the blogosphere.

I’m as shocked as you are. All I can really say is: “Listen up, all you other millions of Michael Boyles out there. Men, get cracking. I mean, I don’t update nearly often enough to qualify as the representative Michael Boyle blog.”

I’ve been meaning to collect my impressions of the different blogging systems I’ve tried for a while now, but I’ve never seemed to get around to it. But today via Daring Fireball I noticed a little post from Joe Trotter that neatly sums up my conclusions and the reason why I’ve stuck with Movable Type. So now’s as good a time as any to quickly throw in my two cents.

I wouldn’t go so far as to say that “I hate Wordpress,” and Gruber’s response is correct, we shouldn’t confuse templates with blogging systems. You could undoubtedly make just about any site in just about any of the top blogging systems currently in use. But just because you can do something doesn’t mean that your experience doing it will be pleasant. The key observation is in Trotter’s final paragraph:

I think the problem is that Wordpress themes (and to a greater extent the entire system) are so designed that modifications stick out like a sore thumb - the themes never strike a good balance between flexibility and aesthetics. I’m thinking more and more to switch to Movable Type. The cachet of Wordpress just doesn’t appeal to me anymore.

Of course if you are a skilled Wordpress template designer you can make beautiful completely original or tastefully modified templates, but it isn’t what Wordpress is good at. What’s made Wordpress so popular — and what has, in part, made Movable Type less popular in contrast — is that Wordpress makes it very easy to do single click design changes. Whether or not this was inevitable, that (among other things) has made it conversely more complicated to implement templates yourself and encourages (though it doesn’t demand) even original templates to conform to a certain “Wordpress way of thinking.”

In order to make a new Wordpress template you have to know way more about how Wordpress itself works than you have to know about Movable Type. If you want to do anything beyond the standard you will quickly find yourself thinking about the mechanics of the database queries going on in the background, and if I wanted to think about that, I’d write my blogging software myself. In contrast, Making a Movable Type template is, simply, making a website. Not much different from designing a static page.

Therefore, I’d heartily recommend Wordpress over Movable Type to anyone who just wants to choose an existing template, maybe change a couple of colors and pictures, and get blogging. But anyone interested in the ease of customizing the design would be better served by Movable Type. People talk about how they love Wordpress in contrast to Movable Type because they always feel like they’re fighting with Movable Type. But while the vanilla install was easy, designing my own templates in Wordpress felt like as big or bigger of a battle.

I think that explains a lot. Wordpress may have a somewhat slicker application, but if the design is what you care about, Moveable Type is an easier, more elegant, sandbox to play in. I’m sure that has something to do with why people who are primarily interested in design often choose Movable Type (or Textpattern or ExpressionEngine), even as the rest of the world is moving over to the plug and play “good enough out of the box” simplicity of Wordpress.

PS And yes, I know that my own blog looks fairly “Movable Typeish” as it has evolved from the standard templates.