Bloggers have rushed to secure their selfhosted WordPress blogs after the recent massive hacks on shared hosts. I was one of them, even though only one of my blogs was affected. I spent hours browsing, looking for good resources, common knowledge, and solid tips to form a list of quitessentials on WordPress security. I also found some useful plugins.

However, as with all things, there are good tips, tips that kinda work and tips that might bring you into more trouble. At the same level, you can keep on uploading plugins into WordPress until the year 2020. Each plugin is a potential hazard by itself. The developer can cease its support, leaving you standing in your underwear in the middle of Blogging Street. And the more plugins you have, the more maintenance your blog will need: upgrading to new releases might become a hassle, knowing every single release is a potential bug farm. It would not be the first time I do a quick ‘Upgrade’ of a minor plugin “just before going to bed” only to find myself trying to get my blog to work again as ‘the minor upgrade’ conflicted with something else and crashed the whole site. Sigh.

So… think before you do anything hastily. For every plugin, check the forum posts related to it, check for bug reports and Google its name to see if there are any complaints.

In a past week, I installed several recommended plugins on some of my test blogs, and will report back if I find good and useful stuff. Meanwhile, I will restrict my recommendation to the WordPress File Monitor plugin I wrote about in my previous post.

As for the tips on security, same thing: I will restrict myself to the bare essentials. After all, I am a blogger, not a systems engineer or a web designer. I have limited time and patience to devote to the technicalities of keeping a blog up and running. I’d like to concentrate on contents more than PHP code and SQL database queries.

Nevertheless, I want to list some of the posts on WordPress security that have been cross referenced several times.

• 12 Essential Security Tips and Hacks for WordPress by Syed Balkhi
• Hardening WordPress from the WordPress site itself.
• WordPress Security Tips and Hacks
• 11 Best Ways to Improve WordPress Security
• The Almost Perfect htaccess File for WordPress Blogs by Josiah Cole

After going through all of these, I found some good tips which I will consider, some I will disregard (e.g. I can not lock any file access to a fixed IP address as I don’t work from a single location, and my ADSL lines have dynamic IPs), but there is one I highly recommend to you:

Secure the wp-config.php file!

If you are not familiar with the wp-config.php file in your root directory, take a look at its content….

Yep, that’s right, you’d better believe your eyes… Here is the basic security access data for the inner workings of your WordPress blog. All readable in plain ASCII. So you’d better secure that file, or your blog is wide open as the Louisiana flood gates!

The fastest and easiest way to protect your wp-config file is by adding the following lines at the bottom of the .htaccess file on your root directory:

# BEGIN protect wpconfig.php
<files wp-config.php>
order allow,deny
deny from all
</files>
# END protect wpconfig.php


This code basically blocks “world access” to the file.

Do it now. Safe blogging!

This WP-config tip was discovered via WPSecurityLock and DevLounge
Pictures courtesy Public Domain Image and The Nosebean’s Blog

During the the latest spree of hacks in April and May, hackers dropped a malicious .PHP script on the root directory of selfhosted blogs.
The script changed all .PHP files, adding one line of code which redirected visitors to a virus-infested site, and then deleted itself. There was anything between a day and an hour between the drop of the hacking .PHP file, and its self-deletion.

In my frantic search to close the security holes on my blogs, I came across a WordPress plugin called WordPress File Monitor by Matt Walters.

The plugin monitors your WordPress installation for any file changes incurred by scanning your directories from the root down. The plugin detects changes based on the files’ hash (a number that uniquely identifies each file based on content, name and timestamp) or on the timestamp of the files only. Of course the “hash” method is more secure, but takes more computing time from your server.

“Changes” could be an upload of a file, the deletion of a file, or changes made inside a file.

You can configure the scan to happen between 1 minute and an indefinite interval. Or you can decide to only scan your files manually from the dashboard.

When a change is detected, a notification appears on your WordPress dashboard:

Clicking on “View changes” gives you more details. In our case a file called “try.php.jpg” was dropped at the root directory level:

Based on the alert, you can take the appropriate action, or just clear the alert.

You can also configure the plugin to send an email alert to a specified address. As a test, I set the scan interval to one minute and edited the .htaccess file on my root directory. The warning email was sent immediately:

This email is to alert you of the following changes to the file system of your website at http://www.haveimpact.org
Timestamp: Sun, 23 May 2010 00:11:54 +0200

Changed:
.htaccess

As some directories, such as cache directories, change their information on the fly, you can exclude them from the scan.

This plugin is highly recommended to help you secure your selfhosted WordPress blog!

Read more about blog security in these posts.

Picture courtesy Discoveries in Medecine

While researching ways to better protect my blog, I discovered a loophole typical for selfhosted sites on shared servers, such as GoDaddy.

The loophole concerns all PHP based CMS (Contents Management Systems), including WordPress, Drupal, Joomla, phpBB, etc…: Many of them allow users to upload files: Forums allow attachments to posts, users can upload their avatar in .jpg format, some comment systems allow code to be embedded. Combine this with shared-hosting services like mine, GoDaddy, which allow files without the .php extension to be executed as if they were PHP code, and you have a hacker’s bomb.

Here is how you can simulate a file drop hack:

1. Create a simple text file with a simple text editor and put the following PHP code in it:
   
   

   php
phpinfo();
?>

   This code does no harm. The command only displays the basic PHP variables for your site, but a hacker could put any malicious PHP code in it, including code that modifies all files on your site.

2. Save it as test.php.jpg
3. FTP it to the root of your site
4. Execute it in your browser (and you don’t have to be logged in) as: http://www.yoursite.com/test.php.jpg
5. If you get a “Page not Found” error, you are cool, and your hosting service protects you from this hacking method. But if you see something like this screen, the output from the php-code you just uploaded, your host is vulnerable:



… and if the code were malicious, the user just dropped a hacker’s bomb on your site….

Sure enough, a user does not have FTP access to your site (I hope!). But… as long as he can upload the file, even as a disguised .jpg file as in our example, and figure out where the uploaded file  is stored in your site’s file structure, he can execute it.

How can you can protect your blog from users uploading disguised PHP file? This documented vulnerability can be corrected by adding some code at the bottom of your .htaccess file in the root directory of your blog (or any PHP-based CMS):

1. As for any changes you make to any file on your site, first backup the .htaccess file, so you can roll back in case it does not work for you.
2. Edit the .htaccess file and add the following piece of code at the bottom:
   
   
   

   # BEGIN drop-file hack stopper
RemoveHandler application/x-httpd-php .php
<FilesMatch ".(php|php5|php4|php3|phtml|phpt)$">
SetHandler x-httpd-php5
FilesMatch>
<FilesMatch ".phps$">
SetHandler x-httpd-php5-source
</FilesMatch>
# END drop-file hack stopper

3. Upload the modified .htaccess file to your root directory
4. Now, assuming you still have the test.php.jpg on your root directory, try executing it again with the same command: http://www.yoursite.com/test.php.jpg

If now, you get a ‘Page not Found’ error, then you are protected. At least for this hack, that is.

One word of caution: this was NOT the method used in the most recent massive hack affecting thousands of sites, as described in this post, but at least it closes one more door for hackers. A door which gives them unlimited access to your website.

Safe blogging!

Cartoon courtesy Life on the Homefront

If Vesalius were a blogger...

After the latest spree of hacks on thousands of websites, it is time to look at some of the commonalities and ways to security our sites better. Given that the security holes are clearly at the level of the website hosting companies, and it is their duty to close those holes, nothing stops us from securing our own sites better. That is what our next series will be about: how to secure our self hosted blogs.

Godaddy published more background information on their blog:

This is a complex attack with many components. Here is a high-level overview of how they occur:

1. The attacker is coordinating attacks against three different hosting providers for this to work.
   • At Hosting Provider ‘A’ – A malicious file is placed on hosting accounts at this provider. No two files have the same name.
   • At Hosting Provider ‘B’ – A file is uploaded listing the infected domain names and unique file names from provider ‘A.’
   • At Hosting Provider ‘C’ – A malicious “scareware” site is placed on compromised accounts
2. After the attackers put their files in place, they use Hosting Provider ‘B’ to trigger the malicious files on Hosting Provider ‘A.’ When triggered, the malicious file:
   • Scans the hosting account for any php file
   • Injects malicious content, installing malware that directs to Hosting Provider ‘C’
   • Removes any trace of itself from ‘Hosting Provider B’
3. The attack is complete when an infected website receives a visitor. The visitor, if not adequately protected, will have malware installed on their machine.
4. The malware will alert the infected computer to purchase fake anti-virus software, located at Hosting Provider ‘C.’

The common factors of all the recent hacks are:

1. The affected sites were all .PHP based CMS’s (Content Management Systems): WordPress, Drupal, Joomla, phpBB…
2. A .php file was put on the root directory of the website, executed a few hours later, and then deleted (more).
3. While executing, the .php file inserted malicious code in all .php files of your site which redirected visitors to a site which infected the visitor’s computer with a virus. (more)

So the basic questions are:

1. How can we avoid .php file being dropped on our site?
2. If a .php file is dropped through a hosting provider’s security hole, how can we detect it fast, before it executes?
3. If our .php files are infected, how do we cure them easily?

Again, while we can not close the security hole of the hosting providers, we sure can take some measures to either tighten the hole ourselves, or at least monitor the changes happening on our sites?

Some solutions:
In this post, I suggest a solution to monitor for file changes and uploads on your selfhosted WordPress blog.
In this post, I described how to cure infested files.
Here, I describe how to protect login information being read from our WordPress blog.

Safe blogging!

Picture courtesy WikiMedia

Godaddy got hacked again this morning (This is what Godaddy has to say about it). Update: and again on May 20.
If you host your blog on Godaddy, you would do well to check your site regularly for any malware, and here is how.

The hack is the same as the previous 4 hacks, affecting thousands of sites: A oneliner malware code is inserted in every single .php file on your site, starting with:

?php /**/ eval(base64_decode("goobledegoob"))

I described before how to cure it, but here is another, slightly more sophisticated way which first lists the infected files, prompts to continue, deletes the oneliner malware in all of your .php files, and lists the cured files. It is inspired by a script written by Andy Stratton in this post.

The script will not only work for Godaddy + Wordpress, but for any .PHP based site (I used it this morning to cure a Drupal site) on any host.

Here are the right steps to follow:

1. Make sure you backup your site, just to make sure. There are many tools to do so, but a “brute force” copy of your entire blog directory to your local computer using an FTP tool like Filezilla, works fine.
2. Download this zip file. It contains a file called “fixfiles.php”. Extract it and store it on your computer.
   (Ok, no zipfile? Here is the fixfilesphp.txt version. Save it as fixfiles.php)
3. FTP the “fixfiles.php” file to the root directory of your blog. In GoDaddy, that is the /HTML directory (which also contains index.php, wp-login.php etc..):

   
   

   

   GoDaddy Root Directory

   If you only want to clean a subdirectory (and its underlying tree), put the file in that the subdirectory, but remember also the command in the next line will have to reflect that.

4. Then execute the code with the command:
   

   http://yoursite.com/fixfiles.php

   or

   http://yoursite.com/subdir/fixfiles.php


   if you put it in a sub directory)

5. The code will first scan for the malware code in your files, in both the directory it is put, and all underlying directories.
   If you get the message:

   0 Infected Files in ./

   …then your site is clean.
   If any malware is found, the script will list the infected files and prompt you to fix them:

   Click on “Fix Files”, Click OK on the prompt to proceed:

   
   The script will scan through all files again, and clean the malware. It will list all files that were cleaned.

   

6. Delete the “fixfiles.php” file from your site after execution.
7. If you are using a caching plug-in, don’t forget to CLEAR YOUR CACHE, otherwise the malware will continue to be served to your users, even though you cleaned your .php code

All of that is “curing” the problem. I have looked everywhere, but am yet to find a way to “avoid” the infection. It looks like the hackers found a loophole in Linux shared hosts (and not just those on Godaddy), which the hosting companies have been unable to identify and/or close.

Until such time, scan your sites every day, and cure the problem immediately before your visitors get infected.

Picture courtesy Owning Pink

Sucuri.net malware scanner

I reported before how to detect if your blog was infected with the recent massive hackers attacks on hosting sites, and how to cure it.

As a follow up, here is the easiest way to detect if your blog has the malware injected: Use the sucuri.net free scanner !

Just enter you blog URL including “http://”, press “Scan”, and there you go.

If the “Malware information” tab goes red, this means that -unfortunately- your site has been infected.

Cure the problem immediately as I described in this post.

If you are a technically a bit more savy, in this post I describe a script that verifies the infection and cures it.

Update: I adapted a script to easily verify and cure the infection on your site. Check this post for more.

The GoDaddy hosting service got hacked three times in a row now. On April 27, May 1 and May 7, many sites, including thousands of WordPress blogs, got infected by malware code. Update: GoDaddy hosted sites were massively attacked again on May 12 and May 17.
In a recent post, I described how I found out the hard way my Drupal site was hacked, and how I cured it the hard way.

Last night, BlogTips was hacked too, but this time, I was able to cure the problem faster.

The problem is so wide spread, and the impact for the infected blogs is that devastating it is worth to checking yours too, if it is hosted on GoDaddy. Once infected, you need to cure your blog real fast before browsers and search engines blacklist your blog. Here is how:

1. Check if your blog is infected

If your blog is part of the recent GoDaddy attacks, you (and your visitors) might see it if your site redirects to a malware site which gives a Windows-like screen asking to scan your computer.

The easiest way, however, is to check some of your .php files. If the first line of the file starts with:

?php /**/ eval(base64_decode("goobledegoob"))

(where “goobledegoob” is a long series of numbers and characters), then unfortunately my friend, your site was hacked too.

2. How to cure it

Cure the problem fast before your users and search engines start mistrusting your blog. Thecremedy is to remove that one-liner with the hack code from all your .php files. You can do that manually, but you’ll be busy for quite a while.

An easier solution is offered in this post by the folks of Sucuri Security.

1. save this PHP code in a file called “wordpress-fix.php” on your computer. It contains two basic commands to remove the EVAL malware code, and extra empty lines from all your .PHP files on your root directory and all sub directories.
   Update: to avoid the script to time-out before all files are cleaned up, you might add  the line
   set_time_limit(0);
   as the first PHP command
2. FTP the “wordpress-fix.php” file to the root directory of your blog. In GoDaddy, that is the /HTML directory (which also contains index.php, wp-login.php etc..):
   

   GoDaddy Root Directory

3. Then execute the code with the command: http://yoursite.com/wordpress-fix.php
4. Delete the wordpress-fix.php file after execution.
5. Update: if you are using a caching plug-in, don’t forget to CLEAR YOUR CACHE, otherwise the malware will continue to be served to your users, even though you cleaned your .php code

3. How to prevent from being hacked?

Well, at this moment, it looks like it is GoDaddy being hacked, and not the individual blogs. It is still advised to change your FTP password, and your admin password on your blog, but that by itself does not seem to prevent new hacks. One of my sites got hacked twice in a row.

You can also subscribe to Sucuri’s free malware monitoring service, so they can scan your blog automatically for malware,…

Let’s hope GoDaddy gets their security back inline quickly, otherwise we are all in deep poohooh for a while!

Picture courtesy TheTechHerald

In a previous post, part of a series about selecting the right blog platform, I urged you to think if you want to selfhost your blog or not. I revisited the subject, stressing the fact that when you choose for selfhosting, you should be aware of the many things bloghosting platforms like Blogger would do for you, you’d have to do yourself. And that includes a lot of technical stuff. Are you prepared to dive into the technical part of the maintenance of your blog, potentially diverting your attention from writing good contents?

I want to drive the point even further: when you choose to selfhost your blog on a hosting provider, like Godaddy or Network Solutions, there is one more thing to be extra cautions about: hackers.

OK, running any kind of blog, you have to ensure basic password security for your administrator’s account, and not use obvious passwords like “admin” or “password” or “secret” (don’t laugh!), but also the hosting company itself can be vulnerable to attacks, without any of your wrongdoing. And recently, hackers have concentrated their attacks on these companies. I guess their reasoning is “why to concentrate on a single blogsite, if we can attack thousands of sites at once when we attack a single hosting site”…

Recently Godaddy has been a victim of two series of attacks, one on April 27 and a second one on May 1. I was a victim of both attacks for one of my sites. Even though my particular site was running Drupal, and no conventional blogsoftware, most of the affected sites were WordPress blogs. Following several forums on the subject, it seems like thousands of blogs were infected.

While this is not a post about hacking techniques, and what to do to cure hacking attacks, let me describe to you what I went through in discovering and curing the hack so it helps you make up your mind if you really want to go to selfhosting your blog…

When I wake up in the morning, love

On the beautiful morning of April 28th, I woke up and checked some of my sites. One of them is a simple Blogger blog showing the latest posts for Humanitarian News, my mega aggregator of nonprofit news. I noticed the posts were not refreshed, and showed an error in retrieving the RSS feed from the mother site. I use a simple RSS to Java tool, described in this post to generate the posts, so trying to debug the problem using Feedvalidator, I found out the feed from Humanitarian News was seen as invalid. I did not think much of it at that moment, although now I know it was a symptom of a hack.

A few days later, Humanitarian News no longer loaded on my Iphone browser, so I checked it on my laptop, only to find that my site was redirected to a malware site. Darned.

Panic

My instinct told me to check the index.php file, the root of my site. I found one line of code was inserted in the file, which looked like

?php /**/ eval(base64_decode("goobledegoob"))

Thus, panic in the house! Using Filezilla, I checked more .php files, and more, and more. All the same: each had the php one-liner inserted. Darned once more.

I googled the code, and found that the one liner was the actual hack. When browsing the website, users were redirected to the malware site. I knew that I had to act fast, otherwise browsers would soon show this infamous screen, the nightmare for any webmaster:

Firefox Badware warning

…and in no time Google would report my site as harmful. So I had to act quickly. It was then 10 pm…

At first, I started to clean up all .php files manually, deleting the intrusive one liner, but soon gave up. Suspecting a vulnerability in Drupal, my CMS, I decided to put the site offline, and reinstall the software from scratch, including all themes and plugins. Luckily, I keep a good track of each of these, for all my sites. It took me about four hours before I had my site back up. 2 am. Sigh, but with a clean site.

Before going to bed, I decided to back up my entire website onto my laptop. A good decision, it seemed afterwards. I also changed the admin passwords, blocked all other user passwords, and changed the FTP password.

Argh, not again?!

On May 1, I saw the same problem popping up with the RSS feed. I checked the index.php file, and exactly the same problem: I was hacked, once more. Again, I put the site offline, and this time, restored the entire site from my backup. Three hours of work.

This time, I googled a bit deeper, and found that indeed, I was not alone. Thousands of sites had been attacked, all hosted on Godaddy, my hosting company! Following some of the forum discussions, it looks like even today, Godaddy blames vulnerabilities of WordPress, although it was soon clear many other sites using different CMS-es were attacked. Mine was only one example, I was using Drupal. Beh.

Selfhosting or not, revisited

While the experts are still trying to analyse how the security on so many sites was compromised, it looks like it is a common and pretty recent problem with hosting companies becoming an easy (it seems) target for hackers. While we have not seen the end of it yet, it does stress the importance of the question: Do I really want to selfhost my blog?

That question is not just related to money, to self-reliance – call it independence – but much more “Do I really have the technical savvy, and the time, to technically manage my site?”. Or in other plain words: Do I want to blog, or do I want to become a webmaster?

Update: 2010 will probably go down in history as the “black year for PHP hosted sites on shared servers”. The 5th wave of hacking is going on as we speak, and the hosting companies are still to work out a way to avoid the hackers to get in. Meanwhile, it is important you check your site for infections several times. If you find the infection, cure it immediately. If not, malware will spread to your visitors.

Picture courtesy HughBriss

The past few weeks, I have been quite busy working with RSS feeds. I continue to be surprised about the possibilities RSS gives us, bloggers and web developers alike.

Here is an overview of the tools I discovered:

From RSS feed to Javascript: Feed2JS

If you want to spice up a page on your website, or integrate a feed into a blog widget, then have a look at Feed2JS. They offer an easy, fast and gratis way to convert any RSS feed into a simple Javascript. Each time the page with that Javascript is run, it displays the contents of the feed as if it were content on your page.

As an example, I took this feed from Humanitarian News:

http://humanitariannews.org/blog/9/feed

…and ran it through their feed2JS builder. You can customize the options: display the content of each feed item – or only the first x characters, open the links in a new browser window or not,… If you are really sophisticated, you can even customize the style sheet.

Hit “Generate JavaScript”, and you will get the code to integrate on your site. In my case, the code snippet looked like this:

<script language="JavaScript" src="http://feed2js.org//feed2js.php?src=http%3A%2F%2Fhumanitariannews.org%2Fblog%2F9%2Ffeed&amp;chan=y&amp;desc=1&amp;targ=y" type="text/javascript"></script>

To see the script in action: I used this code to generate the latest “Aid News” updates on The Other World News.

Create an RSS feed for any website: Feedity

How about websites which don’t have an RSS feed? No panic, Feedity comes to your rescue. Their basic (free) service will generate an RSS feed out of any website. The only thing you need to do, is to jug in a URL for any website, refine which items you typically would like to include in the feed, and Feedity does its job.

As an example, let’s do something really interesting. Let’s create an RSS feed with the latest sites which link to The Road to the Horizon, one of my blogs.

The Google URL to search for in-bound links to this blog is:

http://www.google.com/search?q=%22www.theroadtothehorizon.org%22+-site:theroadtothehorizon.org

When we feed this URL into Feedity and hit “Preview”, we don’t get much:

…but you have to “teach” Feedity what items on the page to look for before it can convert webcontent into an RSS feed: Use the “Simple Refine” drop down menu to select an example of what you are looking for, hit “Refine” and.. voila:

Hit “Get Feed” and you are done. In the example of the above case, the URL for the feed generated from this Google site search is:

http://feedity.com/rss.aspx/google-com/UlVQU1Bb

..which generates this result:

Now please tell me this is pretty neat?!

Feedity lets you define up to 10 RSS feeds for free, updated 5 times per day, and displaying a maximum of 10 items. If you want more, you’ll have to pay. Nonprofits, bloggers and humanitarian organisations get a significant discount.

RSS tools for all needs: xFruits

Moving on from geeky to geekier: xFruits offers a 11 sophisticated RSS manipulation tools for free:

• Aggregate several RSS feeds into one
• Generate an HTML webpage out of your RSS feed
• Generate an HTML webpage suited for mobile users out of your RSS feed
• Generate an RSS feed from Emails anyone sends to your xFruits Email account, or from the unread emails in your Email box
• Create a PDF from any RSS feed
• Generate an Email with the updates of any RSS feed
• Convert RSS to OPML, and create a webpage compatible with mobile devices from your OPML
• Publish your RSS feed on the most popular blog platforms, using their APIs
• And last but not least, convert your RSS feed to Podcasts…

Let’s just take the last one to illustrate the power of RSS feeds. Let’s take the feed from Have Impact !, our micro finance project and run it through the RSS-to-Voice function. The web output looks like this:

It looks like my original RSS feed, but a podcast icon is added before every post. Give it a try and listen to the quality of the spoken voice. Good, hey?
Check out how the same RSS feed looks and sounds like in the Podcast output and mobile output.

The ultimate RSS tools: Yahoo Pipes

And going geekier. The geekiest of them RSS tools must be Yahoo Pipes. Pipes can do just about anything you want with an RSS feed. It can aggregate, edit, manipulate and mix RSS with content at your free will.

I use Yahoo Pipes a lot for Humanitarian News, which aggregates content from 600+ different sites. The technique, I described in an earlier post: Each feed is filtered for lousy formatting, non ASCII characters, mixed with other similar feeds, sorted, truncated and output as a new feed which is imported into my news aggregator.

Yahoo Pipes is for free, supported by an active user forum, but definitively not for those faint of heart: “super geeks domain!”

And more RSS tools: rss-tools.com

And if you hadn’t enough yet, check out The RSS Tools Directory. If you can’t find an RSS tool there, it probably does not exist.

Icon courtesy of Insic Designs

If you are a serious blogger, you will not only write blog posts, but also tweak your blog layout. You will add widgets, fine-tune the layout, add navigation features, icons etc…

This takes up a significant amount of time and effort. As an example of “The Life of a Blog Master”, take a look at change log for my personal blog, The Road To the Horizon.

That blog, running on Blogger, is two and a half years old, has about 1,500 blog posts and gets +-15,000 visitors a month, so it is very dear to my heart.

Came a time though, I got tired of the limitations imposed my old Blogger template. A narrow and two column layout had become outdated and I wanted to swap it for something more appealing. That time was last weekend.

The Road's old template

From the moment I decided to take “the big step”, until the new site was up, I spent about 50 hours, often with cold sweat on my forehead as no matter how well I prepared the migration, things still went wrong.

In this post, I want to share how I swapped my template and what typical problems one should be prepared for.

1. Find a template:
   The first thing to do, of course, is to scout around for a new template. I found the Business Template, a free three-column template made by OurBlogTemplates:
   
   


The Business Template

2. Test the new template:
   I knew changing a Blogger template was not easy, so I created a test blog on Blogger, uploaded the new template and experimented with its features. I created some dummy posts to check the styling for tables, images, videos, and the widgets, etc..
3. On a test blog, customize the new template to your liking:
   I tweaked the CSS styling, the column width and imported several scripts I use in my blog. It took me a full evening until the new template did what I had in mind. All of it still on the test blog.
   I did not style the site with all details as I thought it would be double work and might lose some in the migration from the test site onto the new site anyway, I thought… In hind sight, that was a good approach.
4. Migrate the widgets onto the test template:
   As Blogger does not support the automatic migration of widgets when you swap templates, I recreated all widgets on my test blog. I manually cut and pasted the content from my “old” blog onto the test blog.
   There are short cuts available so you don’t have to manually cut and paste all widgets, but that did not work for me: all HTML/Java widgets gave errors. “Better safe than sorry”, I thought so old fashioned cut and paste, it was…
   Five hours later, all widgets were copied and properly debugged.I had to reformat some widgets as the new template’s side columns and bottom widgets had different widths than on my old blog.
5. Make backups:
   I made a “Blogger” backup of the “old” site. A Blogger back only contains the posts on the home page, but it has all the styling and widgets codes as if it were an independent web page. The following days, I used the backup to check “how my old site looked like”. I use a developer tool like Firebug to double check some HTML codes and CSS styling.
6. Copy the CSS styling and customizations of the templates:
   I downloaded the template XML files of the “old” site, the test site and the news one. I opened them in three separate windows (that is where a wide screen comes in handy)…
   I copied all CSS styling and Javascript-calls from the test site template onto the new one.
   Then I copied all customization from the old site template onto the new one. These included the Google Analytics scripts, all meta tags for the SEO (Search Engine Optimization), the code for Yahoo SiteExplorer and Google Webmaster (explained in this post), …. There was plenty of other stuff to transfer. I had forgotten how much I tweaked my template in two and a half years..
   I went through the old template line by line to ensure that all bug fixes and oddities I added over the years were properly migrated onto the new template. Preparing the new template took me about three hours.
7. Upload the new template. And pray:
   Then came moment “X”: after a deep breath, I clicked on ‘upload’ to pull the newly customized template onto my ‘live’ blog. I refreshed the browser view and sure enough, my blog posts appeared. All still without widgets of course, but I had not lost anything.
8. Re-create the widgets:
   First thing I did on my blog – now with the new template-, was to create a prominent widget to warn my visitors I was working on the site. Always a good practice, pampering your visitors…
   Then, one by one, I re-created all widgets and copied their contents from the test blog onto the “live” blog.
   Another three hours went by.
9. Debug the obvious formatting problems:
   Now the real work started… I navigated around the site, as a user would, and soon enough found all kinds of oddities: Some of my customized styling and home made JavaScripts conflicted with the template. It had all kinds of weird effects. Nothing major but nasty enough to give a sloppy impression. Sloppiness is not a feeling I want my users to have, so I literally worked through the night debugging the new template.
10. Debug text re-wrapping in the posts:
    A quick nap and three coffees to wake me up later, I took a fresh look at my new site.. It looked nice, but as I browsed through the posts, I found some with miss-formatted tables. As the width of the main post column was slightly wider, I also noticed some posts had odd text wrapping, with plenty of orphans and widows (single lines above and below images, videos and built-in widgets)…
11. Ask your visitors for feedback:
    While I was working on the blog, I tweeted the URL of my migrated blog asking for feedback. During the next days. I tweaked the template based on “the demands from my clients”..
12. Go through all of your posts:
    I was surprised about the number of formatting glitches that came to light with the new template. Not because the template was bad, but because many posts relied on the CSS styling of the old template. Some posts looked pretty darned bad.. I decided to go through all posts, one by one.
    And spent about next three evenings doing so… Of my 1,500 posts, probably I probably re-edited about 200. Some took half an hour, , some of them were ok in two seconds.. Still, this is the part I had totally underestimated when planning this migration.
13. And while checking the posts, check for dead links and the like:
    I found plenty of oddities while checking all posts. Many of them had nothing to do with the migration itself. Some posts I had not checked for months, or even years, so I found dead links to videos and pictures, which I corrected on the fly. I also discovered that two and a half years ago, as a beginner in blogging, I had used the Blogger’s WYSIWYG editor a lot. And I can tell you, the HTML code the editor generates is sloppy, making reformatting some posts a pain.

But now, about a week later, I have the site where I want it. I still have a stack of posts I need to correct, but they are really minor changes. That can waituntil I scraped together enough energy to do it.

The Road's new template, 50 hours later...

Main lessons learned in migrating a Blogger template:

• Test your new template on a temporary blog first.
• Implement all customization on your test blog to see if it works.
• Do the migration work in a weekend, when you have time to concentrate on the job at hand.
• Migrate the customization systematically, ensure you don’t get distracted or you will loose track of what you are doing.
• Ask for feedback from your visitors.
• If you planned a certain amount of time, rest assured you will spend at least five times as much.
• Serious bloggers don’t use Blogger’s WYSIWYG editor. It makes reformatting a nightmare.
• Consider migrating your Blogger blog onto Wordpress. Migrating a Wordpress template is a breeze.