MovableType LDAP integration

This week, at work, I cobbled together a hack for MovableType that hooks it up with an LDAP server for author accounts: MovableTypeLDAPAuthors. This is an early, early, early release of the thing, and is likely to do very nasty things for all that I know. But, I wanted to share, and it seems to be working for the proof of concept at work (that is, MT weblogs on our intranet for every employee). Hopefully soon it'll be approved, and I'll be looking into a commercial use license for MovableType.

You know, for all the praise I've read about MovableType, something I've really not seen much attention toward is the code itself. I mean, yeah this thing is great, and it's so simple to install and use by even non-techies. But, under the hood, there're some nice things going on - like a very decent object persistence approach; templating for pretty strict code/presentation separation; a workable servlet-like app structure with facilities for localization and a dispatch-table approach to executing web app methods. There are some spots that are a bit too if/else-ful for my taste, like the CMS' edit_object() method, but hey, it works.

In other words, MovableType isn't just a cobbled together tangle of code that happens to produce weblogs. I've seen piles of well-used code on the web before that all seem to do what they advertise, but present a nightmare under the hood. (cough Matt Wright's famous scripts cough) No, MovableType looks like the result of experience, and I feel biased, because it demonstrates a lot of the same perl web app design patterns I've been employing and advocating for years now. So, my LDAP hack was a bit of enjoyable fun, instead of a chore.

Along the lines of what I'd written last week about perfection versus good enough, I think MovableType is a good example. It's something I could have written, but didn't write and didn't release and didn't support and didn't make lots of people happy along the way. All the did-nots are the important bit. It's why I have two projects dead (Iaijutsu and Iaido) after a few years' effort, and MovableType is a gigantic success today.

So, these are the kind of lessons that are an important part of what this weblog is about for me.

shortname=ooocei

Archived Comments

  • Exciting to see work in this direction. I'm using MT a lot for student projects at the Berkeley J-School, and can imagine this being useful. However, I don't have a need for each student get their own blog. Instead, I would want to make sets of students into LDAP groups and then attach that group to a specific blog. See these: http://journalism.berkeley.edu/projects/biplog/ http://journalism.berkeley.edu/projects/sanpablo/ http://journalism.berkeley.edu/projects/election2002/ So in these cases we have, say 20 students in a class, the output of which is a publication in the form of a web site. I have to create a login for each student. LDAP would be useful for me if I could tell them they could use their existing network logins.
  • Hmm, this sounds like a good idea: Shared blogs based on LDAP groups. I have yet to get far into how to configure this stuff beyond hard coded module vars, but I think it would be useful to pick a branch of the LDAP tree where all blog groups might live. I could then make an explicitly-run script that generates any not-yet-existant blogs for LDAP groups, or maybe work in some autocreation magic that generates them on the fly.
  • What are you using for your LDAP back end? OpenLDAP? MsExchange? What other things use it? http://webseitz.fluxent.com/wiki/IntraNet http://webseitz.fluxent.com/wiki/LDAP
On joining the FSF: The first actually useful membership card?  Previous On the road to a PersonalWebProxy Next