The Trials and Tribulations of TypeKey.

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.

It’s a tentative solution to a problem with the new TypeKey authentication system and it’s a bit of a kludge. In order to make use of TypeKey there’s a mildly complicated bit of JavaScript that goes into your templates that uses cookies set by the TypeKey service to determine if you’re logged in or not. If you are it displays one form and if you’re not it displays a different one, or none at all depending on how you’ve set up your comments. If your blogs are on a different domain (or sub-domain) than what you installed MT on then a small bug shows up related to the cookie that keeps your templates from recognizing when someone has signed into TypeKey. If you’re only accepting TypeKey authenticated comments then this will mean that the form for comments will never be displayed even after a successful login. Here at SEB I’m allowing both TypeKey and non-TypeKey comments so the bug showed up here as simply not displaying the alternate comment form if you signed in (it gets rid of the Name and Email fields). TypeKey would still work under my setup, but it didn’t look like it worked.

Well, the solution they’ve come up with is to have you click on a link to activate the form and this calls the TypeKey service for the login and then dynamically reloads the page through the comment script by pulling your template from the database and re-rendering the page from a URL that matches your MT install. This allows your template’s JavaScript to recognize the cookie because that’s based on where your MT install is located, not your blog. While this does work it means that every time you want to comment you have to click a link to get the form. An annoyance, but not too horrible a kludge. Troublemaker that I am, however, I’m doing something with my templates that ends up not working with this new dynamic method of displaying the comment form: I’ve got a PHP include for the sidebar on the left which isn’t processed by the new dynamic comment script probably because MT is written in PERL. You’ll notice this when you click on the link to leave a comment the new page that renders won’t have the left sidebar on it.

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.

The truth is that TypeKey was intended to be as simple of a solution to comment registration as it could possibly be, I might even argue that it’s too simple. Contrary to what you might think the changes made to MT to integrate TypeKey are pretty minimal. There’s a couple of new template tags related to TypeKey and a new field in both your blog configuration and your author profile for a TypeKey code generated by the service to ID you and your blog, but the actual act of determining whether or not you are signed into TypeKey isn’t handled by any code in the MT script itself. Rather it’s all done via JavaScript and cookies in your template and that’s why they’re having so much trouble with things such as sub-domains. The one good thing about this is that if you don’t want to bother with TypeKey at all then you don’t have to change a single thing in your 2.661 templates for them to work in MT3.

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. grin

9 thoughts on “The Trials and Tribulations of TypeKey.

  1. Not sure the current kludge is that useful.  (I’m not sure, in fact, what the value is of having TypeKey-optional commenting).  As things stand now, I have to (a) click to go to the comments (entry archive) page, (b) click to say, yup, I want to comment, (c)* click to go to TypeKey login, (d)* click to enter my TypeKey login info [leaving out the form filling, which I do via RoboForm], (e)* click on the stupid IE warning that I’m going back to an insecure page … and then I get to do my comment.  And I still have to do my URL manually, if I choose to.

    So that’s a minimum of two clicks to comment via TypeKey, or five if it’s the first TypeKey activity of the day (I guess).  I may just go back to the old-fashioned way of doing things …

  2. That might work for the other blogs I host, but for SEB here it’s on an entirely different domain so I wonder if that solution would work at all. Guess it’s time to play a bit and see what happens.

  3. Interestingly enough you appear to be right, Arvind. And just like you reported it appears that PHP in the template isn’t being processed as my left sidebar isn’t showing up.

    Looking at the URL above it appears that signing into TypeKey is still re-rendering the page and pulling the template from the database which would explain why the PHP include is being ignored, but at least it eliminates the need to click a link to get the forms to display.

    I also notice that the cookie that indicates you’re logged in is still not being recognized as anytime I want to comment using my TypeKey account I have to click the signon link on each entry forcing the page to be re-rendered. So it does eliminate one click, but still requires logging in over and over and over again. Again, if I were only accepting TypeKey comments this would be very annoying and get old very quickly. The only bright spot is that under FireFox once I’ve logged into TypeKey it’ll automatically log me back in on a repeat visit so quickly that I never see the page display, but I bet it’s annoying as hell for folks using Internet Explorer.

  4. On my blog my sidebar and category navigations mess up which are both php

    I’m still trying to understand dynamic comments. If you have it set to 1, the new templates create a link which redirects you to the mt-comments script in the cgipath specified in your mt.cfg install. If you don’t have it set to 1 you get it all on the individual page where non-typekey comments can be posted but typekey comments get re-directed once logged in, to the mt-comments.cgi. I’m testing out a series of combinations specifying different blog locations in the typekey prefs and different redirect back links in the typekey login pages.

    Typekey is still quite young and although a good idea I would have prefered 6A implementing a blacklist into the comments that autoupdated, similar to the news box but a blacklist !

  5. Les, since you are evaluating blogging applications (BLAPS?), I want to make a couple of suggestions.

    I recall that you enabled a thread enrollment/notification capability and then removed it because of performance issues. If you can achieve performance, such a feature would be very nice.

    Will you be able to restore the tag instructions that you used to have? Not a big thing but they might be helpfull every once in a while.

  6. VernR, I actually have tried two different comment notification scripts. One of them didn’t require hacking the code, but didn’t work quite right with my setup. The other one was MT-Notifier and I had to remove it when I upgraded the site to MT3 due to the changes in the commenting system. Chad is working on updating it for MT3, however, and as soon as he has something to try out I’ll get it back into place. He did send me instructions on how I might hack the old version into MT3, but I’d rather wait until it’s properly modified for MT3.

    As for the BBCode link, I just need to add that back to the form. Meant to do that by now, but I’ve been lazy. I’ll get it back on here tonight.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.