I’ve amended my MT 4.21upgrade instructions to include revising the link to your MT installation in your Typekey profile, if you use Typekey. When doing a fresh install, the Typekey token will still be pointed at the old install and Typekey authentication won’t work. Make sure you change it by logging into Typekey and editing your account preferences.
Any other services that interact with your MT installation (like Flickr’s email to blog feature) will need to be updated as well.

This is just plain wrong. Something about the way the interface for MT 4.21 works means that the spell check button on my Google Toolbar doesn’t work on the entry editing screen anymore.
If you’ve been around here long at all you’ll know that this is not good, not good at all.
Get raedy for some mesed up spellign. 😛

This is my first post since the upgrade. If you’re reading this, then the upgrade went well, or at least so far. I had expected more trouble than I got.
Thus far, I’ve upgraded MT and loaded the Right Fields to Custom Fields plugin. The upgrade went smoothly and Chad’s plugin was easy and effective. My RF data came in flawlessly into CF. I expected that to break every entry with an image and It did, but only briefly. Thankfully, when I set up RF, I had the foresight to set up the template code for placing the images in it’s own template module. That made it easy to replace the RF tags with CF tags. In fact, I was able to do that before rebuilding my blog. Easy.
Next, I upgraded Notifier, the plugin that powers the email notifications that some of you get. This plugin is by Chad Everett as well, and the upgrade was also straightforward. However, the way the notification signup works has changed, so the form at left will not work for now. But, for reasons I’ll explain in a minute, I can’t update that left column yet.
Lastly, I updated the plugin that builds my blogroll at left, MT Blogroll. MT Blogroll was replaced by Linkroller but there was supposed to be a means of importing the data from MT Blogroll into Linkroller. I say supposed to be because I followed the instructions and got an error that blocked the upgrade process. Only be removing my old MT Blogroll data was I able to get the Linkroller upgrade to run. Now I’m not sure if I can recover my MT Blogroll data or not. I’ve posted a question about it on the Movalog support forums, but frankly the folks there have more questions than answers because of the sparse documentation for Linkroller and Arvind hasn’t logged in there in months. I’m not hopeful. If necessary, I’ll start over, the blogroll was hopelessly out of date anyway.
In the mean time, most of my left column is built from MT Blogroll tags. Thankfully it’s a server side include file built by a template that doesn’t automatically rebuild. That means I can leave it alone for now and it’ll display just as it has for months. That’s why I can’t yet fix the subscription template though.
That’s where I am. Tomorrow’s unplugged Sunday around here, so no more work until Monday. I haven’t tried to upgrade Photogallery yet, but that’s a bit lower on the priority list. There are a whole bunch of new things to try in MT4.21 as well, once I’ve gotten these glitches worked out.

Well, it’s time to pull the trigger and upgrade to MT 4.21. Things may get a little wonky while I work through it. Actually, they most certainly will get wonky.
Wish me luck. 😀

I’m blogging through the upgrade process to MT 4.2. You’ll be forgiven if you forgot I was doing that since my last post on it was 2 1/2 weeks ago. Someday I might get to the actual upgrade. 😛
One of the questions anyone reading this series (Heh, like someone is going to read this :-D) might wonder is why haven’t I upgraded to MT4.x until now? After all, MT 4.0 was officially released over a year ago, MT 4.1 came along back in January and MT 4.2 has been in it’s own beta for several months as well. So why haven’t I until now?
One word – plugins.
I mentioned in my first Adventures in Upgrading post, Getting Ready, that I thought dealing with plugins was “the Achilles heel of the upgrade process”. Many simple plugins haven’t changed for years and should work fine on 4.21, but the more complicated and the more integrated into MT, the more likely it is that a plugin will break when upgrading. I use a few like that, three of which are crucial to the function of my blogs, Photogallery, which powers my photo gallery blog, MT Notifier which manages the email notifications and RightFields which I use for uploading my images and automatically adding them to my posts. It turned out that two of these plugins (MT Notifier was upgraded pretty quickly) would tie my hands and prevent my upgrading.
Lots of other software use plugins, they are a great way to extend the functionality of the software by tapping into the expertise, and enthusiasm, of the community. Researching the status of your plugins is part of any upgrade, and any one, in my case two, can put a roadblock in your upgrade path. The irony in my case was that Six Apart played a role, perhaps indirectly, in each situation.
The big one was RightFields. RightFields was a slick plugin that allowed you to add extra data fields to your entries and had some of the best documentation I’d seen, sorely lacking in some plugins.. To make the long story short, after MT4 was released, myself and other RightFields users began asking when an upgrade might happen. “Soon” was the answer we got from Kevin Shay, the developer, and later by Apperceptive, his employer who had evidently taken over responsibility for RightFields. Then, when MT 4.1 was announced in January, it came with the news that Six Apart had bought and integrated a competing plugin, Arvind’s Custom Fields (then only if you bought the Pro Pack, now available to all). Even though that sort of made RightFields redundant, we were assured that an upgrade was still coming. Shortly after that, Apperceptive was bought by Six Apart, who also insisted that an upgrade path for RightFields users to Custom Fields would be provided. Ultimately, no upgrade came and no Six Apart solution for converting to Custom Fields was provided that I’m aware of, though I suppose they may have helped out with the solution that did emerge. [See update below]
So, what happened? In May, Chad Everett of Everitz Consulting released a plugin for converting RightFields data to Custom Fields data. He originally created it back in December 2007, but the first version couldn’t handle data in a custom SQL table, as was the recommended method for RightFields and how my data was stored. The new version released in May overcame that limitation, finally providing me (and others) an upgrade path. MT 4.2 was in development by then, so I decided to wait for its release. I will still have a pretty significant amount of work because Custom Fields and RightFields work differently and the template language to place the images in posts is different, but at least I have an upgrade path.
The frustrating thing is that Six Apart played a direct role in this road block. As I’ve said, issues with plugins are expected, but you don’t expect the developer itself to create a hindrance to an upgrade. Their buying Custom Fields and then Apperceptive had a direct impact, I believe, on RightFields not getting updated. Perhaps the ramifications were considered and thought through on their part, but from the outside, it seemed that the fallout was considered only after the fact. In the end, a member of the community not affiliated with Six Apart, RightFields or Apperceptive ended up bailing out those who were stuck. I could understand if this had been an obscure plugin, but RightFields has been around a long time (longer, I think, than Custom Fields) and was used by many. Even members of the MT ProNet, folks who make their living implementing MT, were left trying to explain to their clients that they couldn’t move to MT4 because of this issue. I wonder if any lost clients over this.
Ultimately, I think MT is better for having Custom Fields integrated, ironically, because it avoids the very drama that I experienced in the future. However, these kind of situations need to be better planned out in the future.
The other problematic plugin was Photo Gallery. Photo Gallery is a plugin implementation of Doug Bowman’s slick gallery templates for Movable Type by the MT project manager at Six Apart, Byrne Reese. Photogallery takes all the required plugins (there are many), the complex templates and the mind boggling CSS and adds a one-at-a-time upload mechanism. Without an upgrade, I wasn’t sure what my gallery would look like. The gallery isn’t a big part of the site (obviously since I’ve never provided a link to it here), but I’ve got some 1,300 photos in there of cars from various shows and other things that I’d hate to botch up in an upgrade. So I waited. Finally, in February, Byrne released a version of Photo Gallery for MT 4.1. This converts all the photos to MT assets and updates the galleries to MT 4.x. It’s still, I believe, considered beta (or maybe even alpha) software, and it hasn’t really been tested (that I know of) with MT 4.21, but I’m tired of waiting so I’m going to give it a shot and see what happens.
This isn’t really Six Apart’s responsibility. They can’t be expected be responsible for what their employees do outside of work,even if it is related to MT. In fact, it’s an asset to the community that they have such an enthusiasm for the product that they’d develop plugins for it on their own time. Based on some recent dialog on the ProNet, Six Apart recognizes this and does provide some ‘company time’ for personal plugin development. However, when I as a user go looking at plugins and I see some that have been developed by Six Apart employees, the very folks who work on MT everyday, my expectations for that plugin are going to be higher. I think that Six Apart ought to have high standards for their employees who make plugins too. Each plugin ought to have a home page on their website, there ought to be clear communication on the plugin’s status (what version it works with, version number, if it’s alpha, beta or production at the least) and support inquiries ought to be answered in a timely manner, even if it’s to say “Sorry, can’t help now”. My experience with plugins made by Byrne and another Six Apart employee, frankly, has been the opposite. Documentation is lacking and support is hard to come by.
In an ideal world, the standard would be even higher with complete documentation and full testing. But I understand that personally developed plugins will not be built to the same rigor that Six Apart would do in house. I understand that personal resources are limited and choices must be made as to where to spend their time, but in the least good communication on the status of their plugins and timely replies to support inquiries would be extremely helpful. Six Apart employees should be setting the bar high in this regard, not low.
My hope is that sharing my frustrations will help upgrades involving plugins by Six Apart and it’s employees go more smoothly in the future. For those reading this for advice with their own upgrade, be aware that if you use any more sophisticated plugins, you will most likely have issues. Hopefully they’ll be minor, but don’t attempt an upgrade until you know what you’re in for.
Next step – time to pull the trigger and actually move to MT 4.21.
Update: I had forgotten this from the MT Wiki detailing a proposed expansion by Six Apart on the solution by Chad (below). However, it was announced on the ProNet in June and the page hasn’t been updated since July. They did put up a migration page in the official docs and they also came out with a plugin (still in development) for creating and converting Right Fields LinkedEntry fields to Custom Fields. So to imply that Six Apart has done nothing for Right Fields users is inaccurate.

FYI – There’s a good list of possible gotchas for the upgrade to MT 4.21 on the movabletype.org forums.
Additionally, it’s been reported on the MT ProNet that Arvind’s MT Blogroll plugin (whch I use to generate my hopelessly outdated blogroll at left) has to be completely wiped out or the upgrade will stall. Arvind has instructions on his site on how to upgrade MT Blogroll to his mew MT 4 plugin, Linkroller. I’m going to give that a shot and see what happens before I ‘nuke’ my MT Blogroll install.

I mentioned that I was going to blog through my MT 4.2 upgrade experience. This is the second post in that series.
Update 10/09/2008 – Added instructions on pointing Typekey to your new install.
Update 10/04/2008 – After some feedback on the MT support forums, I’ve changed this to separate the MT upgrade from upgrading plugins. Still would like any clarification from folks who know better.
In my first Adventures in Upgrading post I said this about Six Apart’s recommended install method for MT:

What I think is wrong is that in step 4 it directs you to copy the new MT files over top of the old MT files. Nothing wrong with that in general, and even if something went wrong you could re-install the old version of MT, but I prefer to leave the old version intact and install the new along side, in a separate directory. Why? Because if (when?) something does go wrong that’s not easily fixed, you can simply re-load the database backup you made in step 1 and go back to the old version until you figure out what went wrong. If you’ve overwritten the old installation with the new, you have to re-overwrite the new with the old to go back. The upgrade page mentions this, but as an alternate method rather than the preferred method. That’s backwards, in my opinion.

Well, I’ve since learned why Six Apart recommends the copy over method. The fresh install method is significantly more challenging and it’s easier to mess it up. It’s been a while since I did an upgrade (the upgrade to MT 3.33 was two years ago) and I had forgotten the extra work needed when doing a clean install. The old upgrade guide for MT 3.33 at Learning Movable Type lists 14 steps for a fresh install, vs. 6 for the overwrite install at movabletype.org. For the many users, the overwrite install is probably the better choice. For major upgrades like this one, I still like the clean slate approach.
The problem is, I don’t know which of those extra steps are still needed and which are not or if there are others that should be added because there is no documented ‘fresh install’ instructions, that I have found, for MT 4.2. The Six Apart Upgrade guide mentions the fresh install as does the Community Upgrade Guide on the MT wiki (down as of this writing), but no where is it described in detail. I’ve asked on the MT support forums about it, but haven’t gotten any answer yet.
Looking at the old MT 3.33 post at Learning Movable Type, here is my interpretation of the steps as they apply to MT 4.2:

1. Do not attempt to do an upgrade late at night when you are about to go to sleep and no one on earth is awake who can help you if you screw up.
2. Back up your database. (See Backing Up Your Blog).
3. Create a new directory on your server for the MT4.2 program files. If your existing MT files are in a directory called “mt” or “mt_3-2”, label this new directory something like “mt42” or “mt4”, so you can tell the difference.
4. Download MT4.2 from Six Apart.
5. Unzip the file to your local PC and upload the files to the new directory on your server. If your new directory is in the cgi-bin, make sure you upload the mt-static directory outside of the cgi-bin, to somewhere in your public_html directory. Upload the images in the mt-static directory as binary files. Upload all other files as text. If you have command line access to your server, you can save a bunch of upload time by downloading the tar.gz file (instead of the zip), uploading it to the server and unzipping there. Instructions on doing that here.
6. If you have made custom search templates, copy those over to the new search template directory.
7. Compare your old mt-config.cgi settings to the new settings in mt-config.cgi-original. Using a text editor, copy the relevant settings over to the new config file. Most importantly, put your DB info and password in the new mt-config.cgi-original where indicated. Also note that you should have a new cgi path on the config file, as you have put your MT files in a new directory. A complete listing of MT Configuration Directives can be found here. Copy over directives from your old mt-config.cgi file that are not default directives into your new mt-config.cgi-original file.
8. Change the name of mt-config.cgi-original to mt-config.cgi. Set permissions of all the cgi files in the new installation to 755, with the exception of the mt-config.cgi file. Set the permissions of mt-config.cgi to 644. This is important because your database login info is there and you don’t want to grant everyone access to it.
9. Point your web browser to the location of the new mt.cgi file. The program should automatically recognize that you are doing an upgrade and it should prompt you to upgrade. If this doesn’t happen, make sure you have done all the previous steps. You might also want to clear your browser cache before pointing to the new mt.cgi file.
10. Rebuild all of your blogs.
11. Copy or install all your plugins to the new plugin directory in the new MT directory. You need to do some digging here and find out which ones need new versions and which don’t. For the ones that don’t, you can copy these from your old MT directory to the new MT directory in the same place (if they are in the extlib directory, copy them to the new extlib directory). For the plugins that have a new version, install that version per the instructions from the developer.
    For any more complicated plugins that have their own upgrade or install routine (aside from simply copying the files over), you may want to do them one at a time, rebuilding in between, so that the install processes aren’t trying to run simultaneously.
12. Rebuild all of your blogs again. Frankly, I’m not sure if all these rebuilds are necessary. You may only need one rebuild after all the upgrade processes the main MT upgrade and any plugin upgrades) are complete. If not needed, I think that the only thing multiple rebuilds will do is waste your time.
13. Once everything is working, remove permissions from your old CGI scripts. After you have completed your upgrade change the permissions of the current mt-upgrade.cgi to 644. After everything’s been working for a while, you can remove the old installation folder from your server.
14. If you use Typekey, you’ll need to update your Tyepkey profile so that it points to the new installation. Log in to your Typekey account and you’ll find the settings at the bottom of your Acount Profile page. Any other services that interact with your MT installation (like Flickr’s email to blog feature) will need to be updated as well.

So there you go, how to do the clean install. Keep in mind that this is the thinking of a guy who hasn’t done an upgrade in 2 years and is not a professional MT guru. If anyone has any additional info or corrections, please add it in the comments.

I mentioned that I was going to blog through my MT 4.2 upgrade experience. This is the first post in that series.
The first step in any upgrade is knowing what you’re in for. How hard is this going to be? What do I need to know ahead of time? What are the possible gotchas? I like to be prepared and frankly usually spend too much time in this “Getting Ready” phase. There are two reasons for that:

1. I want to know everything that I possibly might need to know so that nothing will go wrong. (That doesn’t work, something usually does go wrong anyway.)
2. I’m lazy, so the longer I prepare, the longer I can put off doing the actual work. 😛

Regardless, being prepared is a good idea. Going to the Movable Type website, you’ll find a page titled Movable Type 4.2 Upgrade Guide. You’ll be forgiven if you think this is the actual upgrade guide, it’s not. It’s a guide for the new stuff in MT 4.2 that you should be aware of when upgrading. In fact, the first step there is to follow the steps in the Official Movable Type Upgrade Guide. Still, there are some good points in the 4.2 guide about obsolete plugins and upgrading your templates as well as links to some 4.2 specific documentation.
The actual upgrade guide, in my view, is a little light on details and, frankly, I think it leads folks the wrong way. It lists 6 steps, including one step each for downloading, unzipping and copying the files. Honestly, the upgrade is pretty simple, but if you’re like me and you’ve mucked around quite a bit with templates and custom CSS (and you barely know what you’re doing), you need to make sure you’re not going to break stuff in the process. I guess this page is the over view, with links to other pages that you might need depending on your installation. Fair enough.
What I think is wrong is that in step 4 it directs you to copy the new MT files over top of the old MT files. Nothing wrong with that in general, and even if something went wrong you could re-install the old version of MT, but I prefer to leave the old version intact and install the new along side, in a separate directory. Why? Because if (when?) something does go wrong that’s not easily fixed, you can simply re-load the database backup you made in step 1 and go back to the old version until you figure out what went wrong. If you’ve overwritten the old installation with the new, you have to re-overwrite the new with the old to go back. The upgrade page mentions this, but as an alternate method rather than the preferred method. That’s backwards, in my opinion. [Update: See post #2, it’s not so backwards after all.]
I’ve already mentioned that there are two upgrade docs, one that’s more a supplement and one the official, recommended process. (Interestingly, there’s also a ‘community generated’ upgrade guide in the MT Wiki. Oddly, it’s not linked to from the main page, but that’s just as well as it as primarily written by a guy who’s only ever done one actual upgrade. Namely, me.) Between those two documents, there are close to a dozen other linked documents to review to see if they apply to you. For a guy like me who likes to know it all ahead of time, that’s a little overwhelming. I suspect that most folks will just dive right in and see what happens.
Most of that is stuff you can worry about later, after you upgrade. Changes to make so you can take advantage of new features. One area that you should pay close attention to ahead of time, however, is plugins. Especially if, like me, you rely pretty heavily on plugins to make your site work the way you want it to. That, as far as I’m concerned, is the achilles heal of the upgrade process. I’ll cover than in the next post.

MT 4.2, the new version of Movable Type, the software that powers salguod.net is finally here. After a long beta period, it was released last week. Since the release of MT4 over a year ago, I’ve been itching to upgrade. Unfortunately, until a couple of months ago, a couple of important plugins that I uses weren’t upgraded for use with MT4, so I couldn’t upgrade. Once that was solved, decided to wait until the release of the next version, and that’s MT 4.2.
A lot of good stuff in this release, which focused on performance improvements. It’s supposedly significantly faster than other flavors of MT4, but since I’ve never run them, I can’t tell.
I’ll be upgrading soon, so things may get a little wonky at times around here. I’m planning on trying to blog through the process as well, so look for my posts on Adventures in Upgrading.

Kansas Bob pointed me to a neat site called Wordle. It uses your RSS feed to generate what it calls “beautiful word clouds” of the text from your site. I plugged in salguod.net Saturday morning and got this:

You know, I have to tell you, I wasn’t sure what I was going to get. I’ve not been happy with my blogging of late, so when I saw a big ol’ Jesus, front and center and Maria as the next most prominent … Well, it did my heart some good.
I’ve posted a couple of new things since then, so the cloud has changed since then, but still cool to see God, Jesus, Love, Sacrifice and Maria prominently displayed.

Check out Bob’s post, he’s got Wordles of the ESV New Testament and the entire Bible. Neat.