lindalane.com

Centralized Installation

As I mentioned in a previous post, I came across MovableType while I was researching blog software for two of my flatmates in need. After tooling around with it a bit, I decided to use it for myself, and of course, it’s my nature to extoll the benefits of any technology I favor, and thus, many of my friends are now interested as well. Therefore, it’s quite good that I got an Unlimited Personal License. So, this means that on one server, with one installation of MovableType, I can have an unlimited amount of blogs and authors, granted they all use the software for personal, non-commercial use. Great! No worries.

So, all I needed now, was a nice clean way to install it in a centralized manner. Now, the primary domain name of this server is lisbonhouse.com. My first install attempt placed MovableType at http://lisbonhouse.com/MovableType/, CGI’s, static elements and all. This worked fine. I began to create the initial weblogs at lindalane.com, technokitty.info plus others. All of these blogs were placed in the server’s user’s individual Sites folders (an OS X paradigm). Also, all users were logging into the MT Admin area at http://lisbonhouse.com/MovableType/.

I didn’t like this when I noticed that each sites’ users would see lisbonhouse.com up in their browsers’ locations while cruising the site (call me pedantic). As I started to experiment with my own site more and more, delving into TypeKey and TrackBack, I noticed lisbonhouse.com popping up more and more… For example, to enable TypeKey remote sign in, each of my blog author’s would have to register the URL, http://lisbonhouse.com/, with TypeKey, and not the URL of their own blog.

I decided to try a different server location/configuration for MT. I placed it in the central OS X server CGI-Executables folder which is mapped to every virtual host’s /cgi-bin/ path should I tick the appropriate box. I then set mt.cfg’s CGIPath to /cgi-bin/mt/. Now, this was more the type of results I was hoping for. Each user could access MT at their own domain name, and whenever comments were previewed/submitted, the URL’s host name properly stayed consistent. However, upon playing further with TypeKey, TrackBack and comment notification, I found the flaw in the system. MT renders out TrackBack URL’s, Comment Approval URL’s and TypeKey Sign in Referrer’s using <$MTCGIPath$>, thus MT generated URL’s were only valid if you were at the original site, not in comment approval emails, or TrackBack URL’s, etc.

The first plan of attack was to merely update my Templates to reflect my setup. I quickly discovered by inserting http://<$MTBlogHost$> in front of every <$MTCGIPath$> the problem was typically fixed. This seemed OK at first, but I was worried about the breadth of how deep I’d have to go to make this work, and could not initially find where, and then how, to edit MT’s email templates… Ugggh. Secondly, MT was using new funky undocumented tags like <$MTRemoteSignIn$>, which when parsed, create the URL for logging in to TypeKey for registered comments. This left me no room to parse. Luckily, a post from Tweezerman over at the MovableType Support Forum revealed the Template code to get the same effect:

<a href="<$MTSignOnURL$>&amp;<MTIfNeedEmail>need_email=1&amp;</MTIfNeedEmail> t=<MTTypeKeyToken>&amp;_return=<$MTCGIPath$><MTCommentScript> %3f__mode=handle_sign_in%26static=1%26entry_id=<$MTEntryID$>">Sign in</a>

This worked perfectly. However, after finding more and more difficult hills to climb to satisfy my funky installation, I feared more and more for authors of newly created blogs on my server, and how I would have to somehow modify the existing template install to accommodate all of this. In the end, it wasn’t worth it, and I went back to assigning a consistent location for MT, and updating the CGIPath in mt.cfg. Everything worked again. Thus, it would be great to see Six Apart make centralized installation a bit more straight forward.

Hyperlinks

Firstly, I’d like to see MT auto-link any fully qualified URL automatically. There’s a setting in the preferences for each blog to do this for comments, but not posts? Bizarre.

Secondly, on most forums and on some of the blogs I’ve visited, links by default are opened in a new browser window. This would be great too, although I am unsure if it is proper etiquette. If it is proper, some finer control over this type of functionality would be even better. Perhaps the ability to dictate that fully qualified URL’s should open in new windows, and relative and root URL’s should not target their href.

Tags in Tags

The ability to execute MT tags in tags would be great. Granted, there already are a few plug-ins to address this, but the couple I’ve tried haven’t behaved as expected.

One of the first things I did while getting into the Template section of MT, was to extract the header and sidebar as Template Modules. This was perfect as if I wanted to alter the header or sidebar, the changes would be consistent across my site. This is when I found my first need for tag-in-tag functionality.

Of course, my Header Module contained the HTML <head> element and sub-elements, including the <title> element, and I did not want to have the same page title for every page in the site. For example, in the original Category Template provided by MT, the title is rendered with:

<title><$MTBlogName encode_html="1"$> - <$MTArchiveTitle$></title>

My hope was to replace the entire header chunk of this Template with <$MTInclude="Header"$>, and place the following line of code above it:

<$MTSetVar name="pageTitle" value="<$MTBlogName encode_html=\"1\"$> - <$MTArchiveTitle$>"$>

and then in the Header Template, I would have:

<title><$MTGetVar name="pageTitle$></title>

This, of course, didn’t fly, I made a few other attempts:

Escaping the quotes:

<$MTSetVar name="pageTitle" value="<MTBlogName encode_html=\"1\"> - <MTArchiveTitle>"$>

Removing the quoted parameter, and the “$” signs:

<$MTSetVar name="pageTitle" value="<MTBlogName> - <MTArchiveTitle>"$>

And every other possible iteration I could come up with, but MT just wouldn’t have it. This was quickly rectified with a bit of php in each page:

<?php $pageTitle = '<$MTBlogName encode_html="1"$> - <$MTArchiveTitle$>'; ?> <$MTInclude="Header"$>

And lastly, the following code in the Header Template for the <title>:

<title><?php echo $pageTitle; ?></title>

PHP was quite helpful in enabling the display of other unique elements originally located in each Template’s <head> elements, in the Header Template module.

I also used PHP to change the style class of the currently active category link in my menu bar as a visual indicator to inform the user which category page they were on:

<MTCategories> <li><a <?php if (<$MTCategoryLabel$> == $archiveTitle) { echo 'class="selected" '; }; ?>href="<$MTCategoryArchiveLink$>"><$MTCategoryLabel$></a></li> </MTCategories>

PHP Integration

This works great, as just documented. However, there are a few dynamic pages in MT’s arsenal, specifically Comment Preview and Search Results, that are served from MT’s CGI’s and thus, PHP calls in those resulting templates won’t fly. But, for quickly solving an issue like the situations previously mentioned, or for integrating MovableType and other PHP applications (check out my photos section), it does the job.

I won’t go into this benefit any further, as I’m sure those familiar with PHP will have no trouble getting right into it. And, I’m considering doing another write up on the photos database application I’ve built and integrated into MovableType, so I’ll save more detail for then.

Plug-Ins

It does appear that there are a few plug-ins out there to address some of these issues, and also some plug-ins that add entirely new levels of functionality to MT. Also, their level of integration isn’t limited to new tags. However, I’m surprised that there aren’t many photo gallery plug-ins, at least documented on http://www.mt-plugins.org. I expected that concept to be quite popular. Since I have my own pre-existing php photo database, and have successfully integrated it, this doesn’t affect me personally.

My favorite plug-in, by far, is John Gruber’s Markdown, which is currently being used in this post, and has also been back-applied to all of my previous posts. It offers the ability to ‘markdown’ a fantastic natural text language for posts, by parsing it into glorious HTML. The original text document does not look marked up at all (with the exception of some elements, primarily images), and the resulting HTML is loaded with all the necessary tags to make it look great when rendered. I recommend this one to all Movable Type users. The fact that Aaron Swartz has had great involvement with it (Swartz being one of my current heros), which only adds icing to the cake for me.

I came across John Gruber’s weblog, http://daringfireball.net/ when following the controversy between Apple’s Dashboard and Konfabulator. I thought John’s commentary was insightful, well documented, to the point, and accurate. I have enjoyed reading his commentary since. Discovering that he was also the competent coder that developer Markdown, I was further impressed. Keep up the great work John.

Hopefully, a few other MT users will come across this post and offer me some suggestions to overcome some of my issues, and hopefully a few other MT users will come across this post, and in some way, it will assist them with some of their own issues.

Comments are MOST welcome.