Photo by Michael Biven

First thanks to everyone who helped pull this off: Mom, Dad, Carrie, Lane, Kegan, Biddy, Tom, Charm City Cakes, the staff at Tsunami’s Baltimore and everyone who showed up. Without these people the event wouldn’t have happened, the cake would not have been made and I would have probably had a heart attack from stressing out trying to have everything work out. Thank you all big time!

UPDATE 7/15 Charm City Cakes emailed me today to say they are glad the cake was a hit and that it should appear in an episode in September.

A little over four months ago I started hatching a plan to surprise my brother Brian with a birthday party at Tsunami’s in Baltimore. The idea was to have some family and friends to come in from his home town of Louisville to surprise him with his friends in Maryland and a cake from Charm City Cakes. With Brian’s job and CCC both in Baltimore it seemed like the perfect over the top way to celebrate his birthday. The original idea for the cake was a simple round cake with some type of collage of little bits of his life; music (he plays in a couple of local bands), Tsunami’s (he manages and helped open the Baltimore location) and Star Wars (from his childhood). After talking with Mary Alice at CCC the idea of doing the Millennium Falcon was brought up and after thinking it over that is what we stuck with.

Brian tried very hard to wreck the plans twice. Originally he told me he was going to be working on his birthday which was going to make it hard to smuggle everyone into the restaurant plus the cake. Later I found out he had the day off and had a show scheduled with one of his bands, but with Carrie’s help we were able to get that show cancelled. Then he tells me he was thinking about leaving the restaurant and moving back to Louisville, I had to ask him to not rush into anything and at least wait till after his birthday since I had not seen the Baltimore location (there is a Tsunami’s in Annapolis as well). The last thing that complicated things was that Lane and I had to drive in that morning from Kentucky and the GPS unit was not set correctly for DST and was showing us an incorrect arrival time. It was our responsibility to get Brian there at 6 PM and CCC was scheduled to be there about 6:15. A few frantic phone calls later with Lane’s, Carrie’s and Mary Alice’s help everything was taken care of and we arrived with Brian a bit late surprising him with a group of close family and friends and a very kick ass cake!

Keep an eye out for the episode later this year on Ace of Cakes. I have a feeling that it will be the one were Duff is in Louisville delivering a cake to the Lebowski Fest. Brian was great on camera, but for myself I don’t think they ever had a person who will be blipped so much in what gets aired. I was a bit excited, relieved and that was the first and last surprise party I ever organize.

Added for those viewing this in a feed reader and not seeing the comments. As Lane pointed out the cake was chocolate cherry with the cockpit and several of the other details made out of a very dense rice krispie treat. There was a couple of wooden dow rods to keep two pieces of the cake attached and it was mounted on a pedestal to give the look it was in flight. We did start to wonder how we would cut the cake, but Lane had the great idea to grab a knife from one of the sushi chefs there and as soon as it was in Brian’s hands he had no problem dismantling the ship. Another comment or assumption made by people is that it would not taste as good as it looked, while fondate isn’t the best the cake and the rice krispie tasted great. I don’t remember seeing anyone without a smile eating the cake and even with the large amount of fondate there was plenty of cake to go around.

Thanks for the comments, it was a great addition to Brian’s surprise party and to a very long week. Lane and I drove from San Francisco, CA to Louisville, KY; got a few days break and then drove from Kentucky to Annapolis, MD to check into our hotel, grab Brian and rush out to the restaurant in Baltimore.

Two common questions I see both at work and from friends is how best to migrate a WordPress site from one server to another or how to go about changing the Domain Name. There are four different scenarios that will affect the changes you would be making:

Changing the Domain Name only or in combination with one of the scenarios below
Moving from one self-installed server to another self-installed server
Moving from a self-installed server to WordPress.com
Moving from WordPress.com to a self-installed server

Below are the steps that I suggest including backups, starting DNS changes, configuring the new server, database import and changes, verifying the new server, final DNS changes, 301 redirects and final verification. I will point out which applies to each of the different scenarios and also briefly go over a few tools that can help at the end of the guide. Remember though I don’t expect anything bad to happen this guide is completely use at your own risk and I do not take responsibility for anything resulting from following them.

Backup:

(applies to all four scenarios)

The very first thing to do is make a complete backup of the existing site for a few different reasons. First if you really do care about the work and effort you are putting into your site take the extra time to backup it up on some sort of regular schedule. Next is that we are about to make changes to the site and you will want a recent (as in the day your making the changes) backup to fall back on just in case something goes awry. And if you are moving from a self-installed copy of WordPress to another you will already have a copy of the plugins, themes and uploads to copy over to the new server. You do already have a current copy of WordPress and any plugins you have installed right?

So now on to backing up your site. I would suggest that you follow Lorelle’s guide to create a backup for WordPress and keep in mind the XML export would be needed if you are migrating from or to WordPress.com.

First set of DNS changes:

(applies to all four scenarios)

Try to make the following changes in DNS at least 24 hours before you plan to switch to the new domain name or server. Drop the Time To Live (TTL) for the A record that the blog uses down to something like 300 (make note of it’s original setting since you will need to change it back later). The TTL is in seconds so the 300 is equal to 5 minutes. During the migration to the new server you will be getting a new IP address, this way the TTL is dropped and since you made the change at least 24 hours before your migration you should only be looking at a 5 minute hiccup during the switch to the new server.

Configuring the new server:

(applies to all four scenarios)

Next on the new server go ahead and complete the basic install of WordPress. If you are moving to WordPress.com configure the new site, keep it set to private, but do not enable the domain alias at this point (under Options > Domains). For self-installed copies of WordPress depending on what type of access you have with the server you may need to edit your hosts file on your local computer to complete the install since you do not have DNS pointing to the new IP address, specifically when you run the file wp-admin/install.php.

Importing the data:

(applies to all four scenarios)

Now that we have the basic WordPress site completed it is time to import the data (posts, comments, pages) into the new server. Remember if you will be changing the Domain Name as well you will need to make the necessary changes in two tables in the database which I will go over at the end of this step.

If you are moving from one self-installed copy of WordPress to another use the backup of the database to create a new database on the new server. You will need to recreate the database user and edit the file wp-config.php to reflect any changes in the database name, user and password.

If you are moving to or from WordPress.com you will only be able to import the data to the new server from the XML export you created earlier. From the dashboard at the new WordPress.com site go to Manage > Import and then select WordPress. You will then be prompted to browse to the location of the XML from the previous export. Also when importing the file you will be asked if you want to change the author for the posts and drafts you are importing.

If you have changed the domain name used for the site and used the database backup to import your data you will need to make changes to two different tables. We need to change the Blog Address (URL), WordPress Address (URL) and the GUID for the posts. The Blog Address is listed as siteurl in the field option_name and the WordPress Address is home in the same field. You can use either phpMyAdmin or mysql if you have shell access, but the examples I give will be using phpMyAdmin.

The first two fields are located in the tables wp_options. After logging into phpMyAdmin click on the name of the database in the left hand side (you will need to select it form the drop down box if you have multiple databases) and then click on the SQL tab at the top of the page. In the “Run SQL query/queries” text box enter the following and press “Go” to change the Blog Address (URL):

UPDATE wp_options SET option_value =

replace(option_value, 'http://old.domain.com', 'http://new.domain.com')

WHERE option_name = 'home';

And to change the WordPress Address (URL):

(remember if you have your WordPress files in its own separate directory this URL will be different than the Blog Address)

UPDATE wp_options SET option_value =

replace(option_value, 'http://old.domain.com', 'http://new.domain.com')

WHERE option_name = 'siteurl';

To update the GUID with the new domain name enter:

UPDATE wp_posts SET guid = replace(guid, 'http://old.domain.com','http://new.domain.com');

And for any links to other pages or posts internally in your site with absolute URLs:

UPDATE wp_posts SET post_content =

replace(post_content, 'http://old.domain.com', 'http://new.domain.com');

Now that we have the data over get your theme and any plugins that you will be using configured on the new site.

Checking our work up to this point:

(applies to all four scenarios)

At this point you should have the new site up and running on the new server, but before we make it live by updating DNS with the new IP address or enabling the domain alias in WordPress.com you should take a moment to verify (thanks to the edit to the hosts file) that everything looks and behaves correctly. Consider viewing the site both while you are logged in as an admin and while logged out. You won’t be able to view a WordPress.com site while logged out unless you create a new user account and grant it permissions to access the site under Options > Privacy.

Final changes to DNS:

(applies to all scenarios)

After you are satisfied with the new install make the final change to DNS by either changing the A record or enabling the domain alias in WordPress.com. The changes for the A record includes updating it with the new IP address and changing the TTL back to it’s original setting.

301 redirects:

(applies to scenarios where the domain name changes)

So you just changed the domain name for the site and you might be asking yourself what about any links to the old domain name that are still getting spit out by search engines. You can take care of this with a simple .htaccess file in the root of your old domain names web server. Simply create or edit the file to include the following:

RedirectMatch permanent (.*) http://new-doamin.com$1

This will send any links to the old domain to their corresponding page at the new domain name as long as you do not make changes in the permalink structure. The longer you can leave this the better, but you should start seeing search engines updating with the new link, because we used a permanent redirect.

Final checks:

(applies to all scenarios)

It would be easy to think you’re done and stop right here, but I would suggest a couple more checks. Though you might have to wait a few hours or a day depending on how you made your DNS changes, take advantage of Google’s Webmaster tools, the Feed Validator, or Yahoo! Site Explorer to verify your sites robots.txt, sitemap, and any errors that they encounter with your site or feed. Also keep an eye on your bandwidth after the change just in case you have misconfigured something that is causing any problems with the site making calls to itself (ie using the RSS widget to load its own RSS feed) or anything else that we might not think of at the moment.

Closing and additional tools to help:

If you are planning on moving your site I hope you’ve found this guide useful, good luck and enjoy.

A few additional tips to help you check things as you go or troubleshoot (hopefully not) any problems.

Flush your local DNS cache:

In addition to making the changes in your local compuaters hosts file you may need to clear out your local DNS cache.

Mac OS 10.4 and older:

lookupd -flushcache

Mac OS 10.5:

dscacheutil -flushcache

Windows XP and newer (might work on Windows 2000):

ipconfig /flushdns

Query DNS servers with dig:

Being able to query the DNS server you are using or others is another handy skill to have when your mucking around in your sites DNS. On a Mac running OS X or Linux you can query your’s and other DNS server to see what they have listed for your domain using dig.

check your current DNS server for the A record

dig domain.com

check your current DNS server for the MX record

dig domain.com mx

check your current DNS server for the A record on a subdomain

dig sub.domain.com

check a different DNS server for the A record

dig @DNS.server.com domain.com

check a different DNS server for the MX record

dig @DNS.server.com domain.com mx

check a different DNS server for the A record on a subdomain

dig @DNS.server.com sub.domain.com

Taking responsibility of your WordPress site by keeping it up to date to the latest version and managing it’s load on the server hosting it is just as important as the content you’re writing for it. Security updates, performance improvements and other bug fixes will help keep your site running smoothly, but there are a few other steps you can take to improve it’s performance.

Keeping WordPress in check:

First thing is to make sure your install is current. It’s amazing the number of sites that you can come across that are still running older versions even with great tools like the WordPress Automatic Upgrade plugin written by Keith Dsouza of Techie Buzz which is a very simple way to update your site. It will backup your sites files and database, download the latest version of WordPress, place the site in maintenance mode (a simple splash screen), de-activate all plugins, updates WordPress and then reactivates the plugins after you have clicked the upgrade link. This step is probably one of the most missed tasks in maintaining your WordPress site and remember we’re not just talking about performance improvements here, but also keeping it update to any available security patches and preventing exploits like adding spam or reading copies of your saved drafts.

Caching in WordPress:

After making sure you have the latest version installed using caching is one of the simplest ways to improve your sites load times and also help reduce its load on the server. Donncha O Caoimh’s WordPress Super Cache plugin is an improved version of the WP-Cache 2 plugin by Ricardo Galli Granda. One improvement is that unlike the WP-Cache 2 plugin Super Cache will actually create a static HTML page instead of still having some PHP calls when served from the cache. It will serve simple HTML without having to use any PHP as long as the user visiting the site is not logged in or has not posted a comment. If they have commented or are logged in and tries to load a cached page the normal WP-Cache function will serve the page, but one of the best features of this plugin is the “LockDown” button. This will prevent the cache files from being deleted when a new comment is made. So if you think a post of yours is going to get hit by Digg or Slashdot you can have the server ready for the traffic or simply enable this after noticing any high traffic.

Comment and Pingback Spam:

Besides being just plain annoying comment and pingback spam can actually increase the load generated by your site. First make sure you are using the Akistmet plugin that comes with WordPress, then take a look at the using the comment blacklist feature under Options > Discussion. This will help reduce the number of spam that finds its way into your comments and pingbacks, but we also want to prevent blatant spam from posting at all to keep your queue of stuff marked as such as low as possible. To do that you can add some additional lines to your sites .htaccess file that I found at Perishable Press. By adding the rule found at the previous link you can keep any spammer from directly calling the file wp-comments-post.php to post a comment. If you do find that you have a large number of items marked as spam (hundreds or more of pages when you got to Comments > Akismet Spam) keep in mind that Akismet will automatically delete messages marked as spam greater than 15 days old. Depending on how your sever is performing it’s possible you might see the site slow down while its deleting all of those items marked as spam (a little later I’ll show you a tool that will help see what is going on in the background).

Offload as much as possible:

Any images, videos, audio, CSS and JavaScript files that you are serving from your server increase the number of requests that the web browser makes each time it loads your site. The good thing is that there are some very simple alternatives to place these files on a different server that is configured especially to serve static files. Instead of just using the obvious services from Flickr and YouTube for images and videos you can also use services like Amazon’s S3 to serve the CSS and any JavaScript files that your site is using. Also take a look at any additional JavaScript that you are adding for statistics, ads, calendars or basically any other information your are adding to it that is not a post or page. Consider using a web statistics product that is hosted on a different server (Google Analytics) instead of one that is served from your site like Mint for example. Other web stats tools like AWStats and Webalizer don’t actually place any scripts on the site, but instead use the web servers access logs to generate the statistics, either of these tools would allow you to remove a call to any type of a webstats tool, but remember these are generally created from a scheduled job that is run and would not provide you with any type of real time reporting.

Pruning the Plugins:

If there are any plugins that you are not using you should deactivate and remove them from the wp-contents/plugins directory. After that take a close look at each plugin and try to determine the value your site gets out of it and what actually goes on in the background when the it is used. In the next section I’ll briefly go over a few tools that you can use, but remember to check both the WordPress Codex, forums and the plugins site as some of the question you’re about to ask may already been answered. If the plugin actually interacts with the database look at the number of queries that it is sending to it and try to determine if it using any type of caching or can be rewritten without using the database. If you are lucky enough to find a way to improve it’s performance make sure to submit a patch to the plugins author to allow others to benefit from your hard work.

How to see what is going on:

Here are a few tools you can use to see what is going on in the background on the web server your site is hosted on.

Firebug

A Firefox add-on giving you tools to edit, troubleshoot and view CSS, HTML and JavaScript in real time for a web page. Allowing you to see the load times and sizes of individual files (images, CSS and JavaScript) it can help pin down what is slowing down a site. And if you add the YSlow add-on from the Yahoo Developer Network it will integrate with Firebug to give you some feedback on your sites performance and some suggestions on how to improve things.

LiveHTTPHeaders

Another FireFox add-on LiveHTTPHeaders will display the http headers showing you any redirects, sessions, cookies, compression or caching that may be happening when viewing your site.

Mytop

To see what queries are running in your database you could use mytop which is similar to the Top command, but looks at MySQL instead. This tool would require that you have shell access and the ability to install it if it is not already there, but it’s a great way to see real time what your sites is asking the database for and to do.

Access / Error logs

Looking at your web servers access and error logs can give you a great deal of information. Being able to see any web server or PHP errors, where all of that traffic is coming from if the site starts to crawl to a halt from high traffic, if it is getting crawled or scraped by a bot, and can show suspicious activity. If you see a problem or suspect something unusual is happening these logs should be one of the first places you look.

Phpinfo

And don’t forget to take a look at how PHP is setup by using phpinfo. Create a file called phpinfo.php and enter only the following in it:

<?php

phpinfo();

?>

Save that and place it in your sites directory on the web server and you will be able to view the options, extensions, and a slew of additional information on PHP and the web server when you load the file in your web browser.

OK, that was a basic overview of some steps I take to optimize a WordPress site (or any site for that matter), but don’t forget another way to keep things humming along would be to consider actually hosting it on WordPress.com. Hopefully these steps will point you in the right direction to improving your site performance.