UPDATE: The method of dealing with the problem of blogs on subdomains and TypeKey mentioned in this entry has changed since the time it was published and the issue has changed accordingly. I’ll be doing a writeup on the new method which you can read here.
If you’re paying attention you’ve probably noticed that we’re running on the beta 3 version of MT3. You’ve also probably noticed that the individual entry pages now require you to click on a link before presenting you with a form to fill out if you want to leave a comment. I’ve had one or two people ask about it so I figured it’d be quicker to just post an explanation.
Now the reason I use a PHP include is so I can render the sidebar once and then include it on all the templates I want to use it on. Previously I just had it in each template which meant all the MTArchive stuff was being calculated for every template the sidebar appeared on and that’s why it used to take so damned long to post a comment. By doing it once and using an include I sped up the time required to post a comment considerably. So my speed trick is now incompatible with the kludge for the TypeKey solution they came up with. It doesn’t break anything, but it screws up the rending of my pages.
This shows you a little bit of how much work it’s been for the folks at Six Apart to integrate TypeKey into MT3. I’m willing to bet they never imagined it would be this much trouble. The truth is that 90% of people that use MT will probably have the install on the same domain as their blogs and the problems I and others are having would never affect them. I had to get fancy, though, and put my blogs on sub-domains and (in SEB’s case) separate domains. Prior to the kludge if you went to my wife’s blog at http://anne.jenkinsonline.net you would see it display the same bug that SEB was, but if you accessed her site as http://jenkinsonline.net/anne (which is all that a sub-domain really is) then everything would work the way it was supposed to when signing into TypeKey. If your blogs are set up in the latter manner then all the troubles with TypeKey and cookies and using a dynamic form display won’t affect you and this will probably be the case for most of the folks using MT. I like the look of sub-domains, though, and I want to be able to use them so I have to jump through hoops to get it to work.
In fact, as much as I’d like to allow TypeKey accounts the kludge that they’ve come up with for the sub-domain problem will probably result in me disabling TypeKey altogether and yanking out all the code related to it and using the much simpler code of the old-style templates while relying on MT-Blacklist to filter out comment spam just like I did under 2.661. That is, unless they manage to figure out a better solution to the problems with TypeKey logins than what is in Beta 3.
This is why I said that the new plugin API is a much bigger deal than TypeKey is. The new plugin API involved some major changes to the core code of MT whereas TypeKey is largely handled in your templates. Sure, there’s some changes to the comment listing functions inside of MT to allow you to ban TypeKey accounts from posting on your blog, but the code changes for TypeKey are considerably smaller than what the new plugin code required and you can pretty much ignore TypeKey completely if you want to by never making use of the code needed to utilize it. Yet ironically it seems like TypeKey has been the bigger headache for Six Apart both in terms of just getting it to work right in all situations as well as the reaction it received from the community (I’ve yet to hear anyone complain about the new plugin API). Anyway, I thought you folks might find this peek behind the scenes interesting and I hope I’ve explained it in an understandable way. A lot of the gnashing of teeth over TypeKey by folks out there is probably unwarranted, unless you’re like me and have just a funky enough setup that it makes working with TypeKey a real pain in the ass.