I think this post is overly negative but he brings up a good point about existing MT Perl plugins not working on dynamic pages (the #1 feature in 3.1). I can’t think of any possible way around this though, except rewriting the plugins. Perhaps the Smarty handler could pass unrecognized tags through a Perl shell script and grab the output.
I think that post was unspeakably dumb.
It’s remarkabe that almost all of these 3rd-party plugins, written for MT 2.x continue to work with the Perl-based “static” version of MT 3.1 (whose pages may, and frequently do, contain oodles of PHP).
To expect those Perl plugins to work for dynamically-generated PHP-based pages is a bit too much. 6A is encouraging plugin developers to code PHP versions of their plugins (I think that your suggested alternative, of forming Perl processes right and left for every page served, is too much of a performance hit). But that’s going to be a slow process, at best. (Myself, I have no particular inclination to drop whatever I am doing and rewrite my plugins in PHP.)
There are plenty of other new features in MT 3.1. Why, just the ability to use the new Plucene-based Search plugin (to pick the most obscure of the new features) is well worth the price (free) of the update.
But some people are never satisfied.
Tell us what you really think, Jacques. 😉
I don’t think that post was that negative in comparison to many of the posts that were made last release. (True?)
The Perl shell process would certainly kill performance and cause all types of issues. Even dynamically rendered Perl would be better.
Asking for plugins written for static publishing to work in dynamically-generated PHP-based pages is a bit too much. Some plugins simply shouldn’t be used in a dynamic setting. Take me old mt-rssfeed plugin, it goes out and checks its feeds during rebuild. Put that in a dynamic template and watch your server come to its knees. Besides that constant pounding the feed’s server would take would be a ridiculous waste. All this said, I think making developer rewrite and maintain two version of their plugin in two different languages is highly problematic and tasking on the developer especially when it comes to a plugin of any sophistication. At a minimum, I would have preferred this be kept as its own seperate entity and have it slowly worked into the community. If anything deserves the “D” monkier (developer release) it was this thing.
The rest of my thoughts on the matter are here. There is a thread going on the mt-dev mailing list here if you are so inclined to follow it.
Glad you liked my plugin entry and find it so worthwhile Jaques.
Actually, why not dynamically-rendered Perl?
Aside from the slavish belief that PHP is a better marketing gimmick, why not just have a redirect to an “
mt-view.cgi“, which fires up an instance of MT, and renders the requested page from your MT template?You could do caching, and all the rest, and it would automatically work with all your existing MT plugin tags. Under
mod_perl, it would be just as fast as PHP (without the horrendous compatibility issues). And, even withoutmod_perl, the performance wouldn’t be that bad.