MT 3.1 was released the other day only 3 months after the release of the last version. (The good news) The new version introduces subcategories, publishing in the future, plugin pack (including MT-XSearch and Plus) and new callback hooks. It also introduced dynamic publishing which is causing controversey and has left me rather stunned. (The bad news.) Personally, this one hurts a lot more then the whole licensing controversy.
The issue is that this dynamic page feature was implemented as its own template engine using PHP and Smarty. The dynamic page generation system in MT was a hefty piece of work, but there are some major issues that have me and others wondering if there wasn't a better way. While all built-in tags have been ported and switching between the two models are a matter of a checkbox, all plugin tags will not work. Worse yet, going forward, plugins will have to be developed twice and in two different languages to support both publishing models.
A thread I started on the mt-dev list has errupted into a discussion of the features merits and demerits with this post that Ben Hammersley made.
I'm of a similar mind with Mr. Hammersley's post. Ben Trott was kind enough to post the reasoning and process Six Apart went through in regards to MT's dynamic publishing feature. I wrote a lengthy reply that I thought was worth turning into a weblog post since I've been making so few.
Thank you Ben. It does help. I think a lot and will try and be as concise as possible. (This message will be long anyway, but it could have been much much longer.)
I want to repeat my stance one more time for all just so that is abundantly clear: options are good, very good. The need for dynamic page generation understandable. PHP is fine too. Its how this feature is implemented and was introduced that I have issue with.
One of the biggest burdens I find to working with MT these days is that it requires A LOT of effort to figure out how things work and what is in there because of a lack of timely and accurate documentation.
I did receive the technology preview and frankly didn't notice it was in there until someone mentioned it matter-of-factly at BlogOn. I take the responsibility for not having done my part and looked at those previews so I could said something sooner. I didn't have the time (still don't) in the short span from preview release to beta and didn't realize I was looking at such a seismic shift in architecture. (I had to create (guess at?) my own change log by diffing the lib directory in the the sneak peaks
and post it to the mailing list.) In hindsight though Six Apart should have made it more of an issue in its communication. It also should have eased something this big into the community. Having handed out the documentation to how the dynamic page generation system works under the hood and how plugins are developed would have been marvelous!
The options you explored were mostly what I was thinking with option 3 being the most promising also though I had more in mind.
As mentioned by Ben Hammersley, I would have put more effort into the optimizing the rebuild functionality. Part and parcel to that, I would have explored how templates are developed and constructed so they could be optimized for static AND dynamic generation. The bonus being those opting to stick with static generation also benefit. In my experience working with users complaining about the rebuild time of MT, a fair amount was due to resource intensive elements being used repetitively throughout their templates primarily in their sidebars and navigation – next/previous X, latest entry/comments and calendars being the biggest culprits.
For some time now I've had the concept of a Master Site Template
on my wishlist. (Start at around the 4th paragraph of this post for what I mean: http://www.timaoutloud.org/archives/000311.html) While making users lives easier by avoiding all of the cutting and pasting involved in the current system, I would think this could help performance because that HTML would be generated once and could be cached or used in the dynamic assembly pages whether it be PHP or Perl.
I also know the comments in the rebuild process says that There is not a good way to determine exact dependencies
, but could a template be tokenized and its tag usage recorded when its saved so rebuilds like next/previous pages are more intelligent? (If my templates don't have a NextEntry tag why rebuild the next entry?) Couldn't some of this more intensive information be cached for faster lookups? What if MT would rebuild a series of HTML fragments and assemble those with a lightweight CGI (ala blosxom perhaps with a bit of funky caching) instead of going through the whole MT startup and initialization and incurring the overhead?
I would have been OK with some type of special tag set or other delineation for dynamic page generation. (By making it seem as easy as checking a box, you give an impression that isn't consistent with reality – if you use plugins the templates won't work.) A tool to convert existing templates (instead of the check box) to dynamic ones and flag issues (unrecognized tags) along with advise to potentially working around them – like Arvind's advise of includes – would have been brilliant. While this flies in the face of some of the ideals Ben laid out, so does the current implementation. I've seen a number of users grumbling that their templates don't work. Yes its because their layouts use plugin tags, but as we know, users don't read the manual – some may not even know which tags are plugins and which are not. This is why the current approach and its introduction is so serious in my mind.
The current solution essentially says that the users ideals are absolute and the weight of these ideals will be dumped on (3rd party) developers and there are no tradeoffs. Developers must work twice as hard and be equally as proficient in two languages in order to meet user expectations. I know this was probably not the intent, but that is the result in its current state.
The dynamic page generation technology should have been released as a separate entity and once plugins, know-how and design issues were worked out, integrating it into the MT core. If anything warranted the D
moniker in MT this is it!
I realize figuring this out is not trivial (then again that's why you folks are making the big bucks!) and that my ideas are admittedly half baked since I don't have the resources or motivation to figure them out. Despite the analysis you shared, I'm sorry to say that this was still hastily rushed to market and more care should have been applied by easing this into the community rather then the big bang it is.
Now the toothpaste is out of the tube and I'm dreading the impact it going to have my projects and the tool that I've bet my current career and livelihood on.
I regret if I come off heavy handed or a whining crotchety old man (I have not no plans of [making] and a donation of $500 to WordPress), but this is how I honestly feel and it serves little purpose in my mind to not state it.
This text was originally posted here.
