mezzoblue ASP to PHP, with MT to Boot!

2013 年 12 月 8 日2,8470

December 02, 2003 10AM PST

Step right up, step this way. Ladies and gentlemen, I give to you the amazing journey from one server-side technology to another. You’ll be amazed, you’ll be awed, you’ll laugh, you’ll cry. You’ll… okay, so my writing style needs to calm down a touch.

I’ve been working on this on and off for months now, and I meant to have it up far earlier than this. Some of the final details are fuzzy at this point, but the bulk of it is on target.

This is the process I went through when upgrading my Movable-Type powered site from IIS (and ASP) to Apache (and PHP), from start to finish. For the benefit of Google, and you the reader, I’ll try to spare no detail. Much the same as I ended up blessing the kind souls who have written up their own experiences, one day I hope someone will find the exact answer they need somewhere in this.

Why I Switched

I originally set up mezzoblue on an IIS host because ASP is what I knew. I am not a programmer, but the odd time I needed to fool around with code it had to be something that I could easily use.

When I created BlueSpark (a free, light-weight ASP-based content management system: think server-side Notepad) I realized even my knowledge of that was only rudimentary at best. So reasons to stay on IIS quickly eroded, and I found myself wanting to get into PHP about two or three months ago. Why PHP over ASP? Momentum, baby. All the cool toys are written in PHP, and more importantly, a large chunk of them are open.

I’m no anti-Microsoft zealot, but I see huge advantages to working with open source software. Now that I’m actually on an Apache server I can say that custom .htaccess files are a hugely important thing to have, and IIS’s handling of the same is positively archaic in comparison. I’m sure there will be plenty of other little gems I’ll discover as I play more.

How I Learned

So cut to about a month ago. In my copious, vast amounts of spare time I started thumbing through a Peachpit press book by Larry Ullman: “PHP and MySQL For Dynamic Web Sites.” If you’re familiar with C/C++/Javascript syntax, you’ll easily breeze through the first 50 or 60 pages. In fact, I skipped to Appendix A which covers installation, and with a little help from the manuals I managed to get Apache, PHP, and MySQL up and running on my spare Windows laptop one evening.

By the time I was a hundred pages into the book, I’d already started working on converting mezzoblue. There aren’t many scripts, and a lot of the work involved rebuilding my main three server-side includes. I hadn’t really dealt much with the content pages within, I had only laid the foundation.

What to Do When Things Go South, or: Motivation

And it was about this point my IIS server began acting up. Reliability decreased over a good week, and then one day things just stopped working about 80% of the time. It was down, then up, then down again. My host’s site suffered the same problems, so I couldn’t even file a claim to see what was going on. Needless to say, when I finally got an answer it was less than satisfactory.

So I started investigating hosts. I need generous bandwidth and storage space, but I don’t use a lot of server processor time. Unfortunately, the amount of bandwidth I use gets lumped into higher-end accounts. But Matt Mullenweg made me an offer I literally couldn’t refuse, so I jumped.

Static Conversion

But that’s only the beginning, of course. I had a host. Now to port Movable Type, and rebuild my site on Apache. Well, let’s just say this wasn’t as easy as I had hoped it would be, but it didn’t turn into the disaster I had feared it might.

I had backed up all my files from my IIS server earlier in the week, and I was irritable enough with the downtime that I decided to jump in head first and initiate the domain transfer. I put up my pre-built PHP page with an apology message for the next day or two of downtime, and went to work. I started with the static content, that was easy enough. I plugged in my new iBook and grabbed a copy of BBEdit Lite, and started re-linking.

The nice thing about server-side includes, of course, is that all your standard site-wide bits like headers and footers and sidebars and the like can be stored externally in their own individual files. The upshot in this case is that a lot of my static content looked like so:

inlude files, content, include files

Not a lick of content had to be changed, all I had to do was re-link the new include files, which, if you’ve been paying attention, I had already built last month. Copy, paste, upload, test. Copy, paste, upload, test. That was a fun evening, at least in comparison to what happened next.

Movable Type, or, How to Make a Bad Thing Worse

Now here’s where I hit the big snag. Equal parts assumption and hope had led me to try uploading the entire Movable Type install to my new server. After all, MT is Perl-based and should work without a hitch. I made sure server-detection in my FTP program was automatic (since it’s very important you’re not uploading .cgi files as binaries), dropped the works onto the server, re-linked Perl and the appropriate user directories, set my permissions, and loaded the MT interface.

Nothing.

Well, not nothing, but not a lot more: Error 500, internal server error. Not helpful. I double-checked my paths and my permissions, then tried again. Still nothing. In a fit of desparation I dropped one of the .db files into a text editor and noticed that there were paths in those consistent with my old IIS install — not a comforting thing at this point.

Remember how about I stated I’m no programmer? I was stuck at this point. Luckily, I have what we commonly refer to as ‘problem-solving skills’ so I came up with a few more plans. You may laugh, you may cringe, but at this point they seemed worth a shot.

Next up on the list: re-installing MT, then dropping the old data directory, db, on top of the new install in hopes that the interface would just recognize the old data and think everything was okay. But I couldn’t login to Movable Type after doing it. I reverted back to the freshly installed db directory, and was able to login fine. I tried selectively dumping a couple of the larger .db files into the new directory, but had no luck doing that either.

DNS Trickery

So I still had the archives, but no way of getting at them. Hmm. I was smart enough not to cancel my prior hosting account, so I grit my teeth and moved my DNS back to the old server.

A day or two of waiting for propogation, then I was able to log in to my old MT interface, manually export my entries and comments thanks to Six Apart’s about not locking users in, save my customized templates, then switch DNS back to the new server.

At this point the cards started stacking back in my favour again. My new server gives me a static IP, so I was able to point my copies of Firebird and Safari toward it without waiting for the propogation. I set to work getting the old entries imported into my fresh install, and added my templates through the interface.

Which is not to say this process wasn’t without its share of trouble — even though I temporarily pointed Movable Type toward the IP instead of the domain, I wasn’t able to access everything. When saving entries or comments, for example, the refresh would go to a non-existent page on mezzoblue.com. This was only a minor inconvenience though, since the data was saved regardless. While waiting for the rest of the world to catch up, I was hard at work plugging the holes and making sure things would be up and running by the time the DNS change went through.

At this point I made a valiant attempt to switch from Movable Type’s default Berkely DB system to MySQL, since that was the other half of the equation. However, since I needed a quick fix, my inexperience with the latter got in the way and I eventually conceded that to a later date. Bigger fish to fry, after all.

Summary

So while I showed some foresight, the process was hardly as smooth as it could have been. For a few days, I wasn’t able to do much in the way of posting new content, and a static page greeted visitors to the site. Effectively, I was knocked offline as I waited for the jump to and from and then to my new host, although during that time most were still able to access one server or another.

I’ve been on Apache for two months now, and I couldn’t see myself going back. I haven’t even begun to scratch the surface of the things I can do, but it’s comforting to know that if I need to, they’re there. At least I’m in the happy spot of being able to blame shortcomings on lack of brainpower, rather than lack of horsepower. That, in my books, is the easiest of the two to fix.