MovableType monthly archive problems
I just moved my MT blog to a new server, and found that the monthly archive page does some weird stuff. </MTMonthHeader> appearing in the rendered page's source was a sign that one of the plugins (MTDateHeaders to be specific) is not working. Of course, no errors during rebuilding.
I rememberd a similar issue with AWStats, where after all it turned out that one of the plugins were missing a perl module. Some googling showed that this module uses Date::Calc, and I didn't have it on the new box! Until now, at least...
But no help, this module still doesn't work. And - maybe it's just me, but - I cannot find the original plugin to download and check what else it misses. I gave up here yesterday night, today I might just update the whole MT package to 3.15, and find out how to do the MonthHeader thing differently.
Update: I've recently upgraded to the latest MovableType (3.17), with a clean install, but the problem was still there. OK, this time hardcore googling. Finally I've found a forum post where the author of the MTDateHeaders explained some install issues. One thing stroke me: he was referring an MTDateHeaders.pm file too, together with the usual pl. Sparks above head. That's going to be it!
Fortunately I still had access to the old server where everything was working ok. Did a quick'n'dirty find:
find / -name MTDateHeaders.pmAnd there it was, this nasty, bad bad bad module under /usr/local/share/perl/5.8.3! Moved to the new server, and there it goes, everything works nicely.
Before I finish, let me summarize: there's a software on the server, MovableType. There's a small plugin for it, MTDateHeaders. MT has a nice extlib directory for all the modules she and the plugins might need. Added all these together, a question rises: How the hell dares this plugin touch the base perl library directory?! And if it's unavoidable (it is not), why cannot he complain if his vital module is missing?! Wonders of the world, I guess.
posted by peter at 9:03 AM
4 Comments:
> How the hell dares this plugin touch the base perl library directory?
Simple actually. It's built using the standard CPAN/ModuleMaker dist model where the user installing it does 'perl Makefile.PL', 'make', 'make install' to install the perl bits. 'make install' installs to the site lib of the perl install like any other CPAN like module would. It (and the base per install) doesn't know anything about lib/extlib in the MT install. However, you can speficy PREFIX=/yourmtlibdir to override the install location.
Nothing nefarious going on. It's common practice.
The uncommon practice for perl is all of these MT people copying around files like it's mac-drag-and-drop-install fest. :-)
4:39 PM
Thanks for your comment claco.
My problem was that I completely understand, agree with and also enjoy the CPAN model when I write a script and need a module for that. In the case of an MT plugin, the target audience is very different, probably a lot of the users of MT never even heard of CPAN.
The MT module handling practice might be bad, regardless, that's the way it is now, and I guess it's going to be like that for a while.
But whatever, the point is that the problem is solved, and I'm still using this plugin with great satisfaction, so thanks for that, and sorry if I sounded too harsh.
4:56 PM
Not harsh at all. If I had more intention than a quick and dirty hack, I guess the Makefile.PL could seek out or ask where extlib is and Do The Right Thing.
Then again, most MT users probably aren't even running the makefile. :-)
6:05 PM
exactly. :)
9:19 AM
Post a Comment
<< Home