Fixing an Old Website

Send to Kindle

Lois and I have recently befriended an amazing Nashville-based Singer/Songwriter. Since I intend to write a long post about him in the coming weeks, I’ll leave his identity as a mystery for the moment, since it has little to do with the specifics of this post.

The story of how we met him is interesting in and of itself, but a key piece of it involved the fact that his website was badly broken. As a result, Lois sent him an email (letting him know that), and ended up striking up a friendship in the process.

His website was built a long time ago, when he was employed by a record label. At the time, the code was likely cutting edge, but by today’s standards, even if it worked (which it didn’t), it would be considered a wild mess, and extremely difficult to maintain. One example, the site is optimized for 800×600 viewing, and bothers to tell you that on each and every page. 😉

The site broke when the record label folded. They were kind enough to hand him all of the code, but he’s not a techie. Someone (I have no idea who) put it up on a hosting provider, but I can’t imagine that they tested it, or bothered to fix it if they did. Worse, the site has gone through many iterations, and all of the code for every iteration is still laying around on the host in one directory or another.

He told us that another friend of his offered to fix the site, but she got sick and hadn’t found the time to get to it. Finally, I couldn’t take it any longer, since we were too embarrassed to point people to the site (even though we love his music!) so I offered to give it a shot.

As technical as I am, I am a horrible designer and I don’t have as much web experience (as a programmer) as people might think. The only two systems that I’m reasonably familiar with are Zope (which runs the main Opticality website) and WordPress (which powers this blog). I had never written a single line of JavaScript, and while I thoroughly understand HTML and CSS, my lack of design skills (and sense) cripple me when starting from scratch in those arenas.

Last week, I officially took control of his site as his new webmaster. My goal was to fix the site, not improve it in any way! In other words, it would still be the ancient look-and-feel when I was done, but at least it would work! After much head-banging, I finally achieved that last night. I’m still not announcing that site in this post, for a number of silly reasons, but my initial goal has been met.

Why am I writing this? Because I want to share a few revelations that I learned along the way.

There was a page on the site that had JavaScript-based popups to bring up the Lyrics and Stories behind a number of his songs. The popups didn’t work. Since I had never coded up any JS, nothing jumped out to me as obviously wrong. I wrote some standalone tests that mimicked what the popups did, and they all worked for me. In other words, I proved to my satisfaction that it wasn’t my browser settings that were blocking the popups.

Long story short, after much head-banging and Googling, it turns out that the popups were being blocked inside the site’s HTML/JS! What? Norton Symantec Personal Firewall, in an attempt to save its users from themselves, rewrites HTML files before they are served. It inserts a series of JS functions to override window.open() and onerror() and a few other functions. At the end of the file, it resets them.

Still, who cares what a personal firewall does on a user’s machine? We all do! My guess (and I’m reasonably sure I’m right here) is that the friend who took the files from the old record label, and put them up on the hosting provider for the musician, had the Norton Symantec Firewall installed on their machine. Each time they touched one of the HTML files, the Norton Symantec JS was inserted into their copy, which they then uploaded to the hosting site, and voila, all of the popups stopped working, for everyone!

I had to hand-strip all of the inserted JS. Why? Because unlike Zope, WordPress, or any other CMS-like system, any design element (or coding error) is propogated among dozens of individual files. The bad JS was in 50+ files, that I hand-edited. If I didn’t like a menu item, instead of changing it in one place (like I would in Zope or WP), I had to go into every page on the site that displayed that menu, and make the identical change.

You might ask why I didn’t factor out those parts. The main reason is that I wasn’t looking to introduce new problems. One of the things I’m particular good at is doing rote tasks extremely quickly. Once I knew exactly what I needed to do, I was able to accomplish the edits faster than most people. I am also proud of the fact that I didn’t introduce a single typo in all of those edits (to my knowledge).

I also added a PayPal cart for him (he was taking orders via email!). I had never done that before either, so that was another learning experience. Within 24 hours of my putting up the new cart, he has already received orders (successfully) from both the US and the other side of the world! Cool! 🙂

Finally, I incorporated a free streaming flash player so that people could listen to 30-60 snippets of a number of his songs. I had never done that kind of stuff before either, so that was an interesting learning exercise as well.

Bottom line: inheriting an old site, laden with problems, is not a fun task for someone with as few web skills as I have (had?). But, since I love learning stuff (in particular, web stuff), the overall experience was positive for me, and I’m very happy to have helped our new friend.

I can now take my time, possibly going for a complete redesign, knowing that at least he can easily take orders for his CD now, even if the site is still not much to look at…

Update: Painful epilogue. I commented out (or thought I did) one menu item. I used an HTML comment, as in “<!– blah blah blah –!>”. I tested it in both Firefox and Google Chrome, and the menu item was gone. Unfortunately, I didn’t test it in IE. A few minutes ago, I pulled up the site in IE to test something else (lucky for me), and noticed that some of the pages were 100% blank. Removing the “!” from the closing “>” made it work in IE. Ugh. Of course, since I haven’t refactored yet, I had to update 45 files by hand again… I also found one other thing that doesn’t work in IE, but that’s a Flash thing, so some more work to be done.