Let’s take a look at a picture of Ripley:
Ripley
The HTML for that looks like this:
<div class="wpmt-photo-left"> <a href="/archives/2005/images/20050401-IntroducingRipley.jpg" title="Ripley"><img alt="Ripley" src="/archives/2005/images/20050401-IntroducingRipley-thumb.jpg" width="400" height="300" /> </a> <p>Ripley</p> </div>
(I’ve simplified the HTML in these examples slightly for readability, so they may not work as shown.)
That’s kind of messy, especially when I have to do that for every photo I want to post. I often get it wrong.
Even worse, if I want to do a blog-wide change to something about the photos, I have to edit every entry that has photos. (Unless the change only affects the CSS and not the HTML.)
So I wanted to try replacing those big HTML blocks with something simpler that abstracts away the HTML that implements it. I started by using Brad Choate’s MTMacro plugin for Movable Type. It’s well documented and easy to use, so within a few minutes I had boiled the text down to something like this:
<MTWpArtPhoto image="20050401-IntroducingRipley" title="Ripley" >
And it worked great. I’d type this little bit of code to replace the photo HTML in each blog entry—which made them a lot simpler—and the HTML sent to the browser was the same as before. The only difference is that I don’t have to maintain each one separately.
I’d changed about a half-dozen of them when I remembered I also had to change the templates for the various archives. After making the change, I clicked on an individual article link and got this message:
The requested page could not be found. Smarty error: [in mt:35 line 15]: syntax error: unrecognized tag 'MTMacroApply' (Smarty_Compiler.class.php, line 556)
Now archive templates are just like the main template, except that I have all the archives set up for dynamic rebuilding. When a visitor requests one of those pages, Movable Type builds it and serves it on the fly. I do this so I don’t have to rebuild all the blog pages whenever I make a template change. The main page, however, is static. That’s for efficiency, so it doesn’t have to be rebuilt every single time a visitor checks it.
I disabled dynamic content and rebuilt the entire web site, and sure enough, everything worked fine. So MTMacro doesn’t work in dynamic mode for some reason. Well, it hasn’t been maintained in a while, so perhaps it missed a Movable Type upgrade. Fine. I’ll build my own special-purpose Movable Type plugin to implement the MTWpArtPhoto tag.
It took about an hour of tinkering to figure out how plugins worked and to create a dummy plugin to test with. I tried it with dynamic pages and it didn’t work at all. The MTWpArtPhoto tag just got copied into the outgoing page. A little more research led me to the Process Tags plugin, which allows you to turn on tag processing in blog content. Try it again…another error message.
What the heck? It’s almost like plugins are broken in Movable Type with dynamic content. But that can’t be, because all those plugins are such big part of Movable Type…time to do some research.
Well, it turns out SixApart did break plugins in dynamic templates. Plugins that add new tags have to be built with PHP and/or something called SMARTY. I didn’t bother to look up what that is. It would be nice if SixApart had documented this.
Movable Type’s dynamic publishing mode supports plugins as well. The architecture is different, but should be familiar in some respects.
That’s it. That’s all they said about plugins. I don’t know about the rest of you, but it’s not immediately obvious to me that this means that dynamic publishing is implemented in a completely different way from static publishing and all the old plugins won’t work.
I wrote a simple dynamic plugin, and it doesn’t look too hard, but it only works for the dynamic pages, not the static main page. I’d have to jump through the hoops to make the main page dynamic too, and that will be a bit inefficient. If I want it to work both ways, I’ll have to implement both Perl and PHP versions of the tag. And I still haven’t tested if PHP plugins work from blog content…
I’m sure there’s some reason why the developers did it this way, but the result is frustrating as hell.
UPDATE: I decided to try to implement both versions of the MTWpArtPhoto tag after all. This required me to program in two languages I hardly ever use: Perl and PHP.
The first step was to figure out how to get the new PHP-based plugins to be processed in the blog content. With the Perl plugins, I used the Process Tags plugin from Adam Kalsey. It allows me to do this in the template:
<MTEntryBody process_tags="1">
That’s all it takes to get Movable Type to expand tags in the blog content on static pages. However, Kalsey hasn’t gotten around to implementing the “process_tags” attribute in PHP yet, so it doesn’t work on dynamic pages. I took a look at how the Perl version is implemented and decided to try to implement my own version.
It looks like this:
<?php function smarty_modifier_process_tags($body,$args) { global $mt; $ctx =& $mt->context(); if ($ctx->_compile_source('entry body', $body, $_var_compiled)) { ob_start(); $ctx->_eval('?>' . $_var_compiled); $_contents = ob_get_contents(); ob_end_clean(); return $_contents; } else { return '<p><strong>Error compiling blog entry' . 'with Process Tags.</strong></p>' . $body; } } ?> I based this on the implementation of the MTInclude tag, and there are parts of it I don’t understand that I just put in there because they were in MTInclude. In other words, this is cargo-cult programming. But it seems to work.
I’m now working my way back through all the older blog entries and modifying them to use the new photo tag.
Leave a Reply