So, you visit your WordPress blog and all you get is a blank white screen. You can’t log into WordPress either. This is when you freak the *$!@ out.

Don’t panic! It may look like your blog has been deleted, but all the data is probably still there. The White Screen of Death usually appears when you have a problem with a theme or plugin. To fix the problem, you need to log into your server and rename the folder that contains the malfunctioning theme or plugin. This is a process of trial and error, so keep renaming folders and refreshing the blog to see if it’s fixed.

Once your blog is back, try renaming the folder to its original name. Usually whatever was wrong will have righted itself. If not, delete the plugin (after backing it up) and try reinstalling it with the latest version.

The White Screen of Death always terrifies people, but it’s one of the easiest WordPress problems to fix. Clients are never more grateful than when I magically recover their blogs this way. By far, it has the biggest reward to work ratio of any problem I solve.

I typically use the Contact Form 7 plugin to create forms in WordPress. It easily creates forms using shortcodes to generate the input fields. One of the only limitations is that the shortcodes don’t allow you to add javascript behaviors like onClick, onBlur, etc., nor does it support the relatively new “placeholder” attribute. This becomes a problem when I want to set up a form that displays text in an input field that disappears when a user clicks on it. I do this when I don’t want to use a separate label and instead put that information in the text field itself, like “Name” or “Email” etc.

Outside of Contact Form 7 you can achieve this behavior in a few ways. You can use the “placeholder” attribute along with a script like this to add support for legacy browsers. You can also add onBlur and onFocus actions to each input field. Or you can use a jQuery script to add blur and focus behaviors.

If you stick to using Contact Form 7, there’s a way to alter the plugin code to support this feature, but I don’t like to do that because the changes get erased if you update the plugin, which a client might do. The jQuery method I mentioned above can usually be used with Contact Form 7 to make text appear and disappear. However, I ran into a problem when I tried executing this in a Woo Theme. The form code caused the code for the slider in the theme to break. After spending a lot of time trying to fix it, I found a pretty simple solution. You don’t have to use the shortcodes to get the form to work!

First, I used the shortcode to create the HTML for the input field I needed. I then replaced the shortcode with that HTML and added the javascript onBlur and onFocus actions to it. I tested the form and was surprised to find it worked! Here’s the code I used for the text field:

The only downside I can see is that there’s no way to make the field required if you set it up this way. Otherwise it works!

I recently moved a client from WordPress.com to a self-hosted WordPress installation. After I imported all her entries, I noticed that the shortcode WordPress.com had used to display her YouTube videos was no longer working. Instead, the shortcode itself was appearing, like this:

[youtube=http://www.youtube.com/watch?v=1LLls4hPEfM&w=500&h=311]

This is actually pretty easy to fix once your figure out the regular expression that can grab the YouTube video id, width and height from the shortcode. Then you add a shortcode definition to the functions.php file of your theme by copying and pasting this code:

function youtubeSC($atts) {
	$posttext = substr($atts[0],1);
	preg_match('/v\=([a-zA-Z0-9]+)/', $posttext, $youtubeID);
	preg_match('/w\=([0-9]+)/', $posttext, $width);
	preg_match('/h\=([0-9]+)/', $posttext, $height);
	
	return '<iframe width="' . $width[1] . '" height="' . $height[1] . '" src="http://www.youtube.com/embed/' . $youtubeID[1] . '" frameborder="0" allowfullscreen></iframe>';
}

Hope that helps!

Today I got the phone call I always hate to get from clients. It was Stephanie O’Dea telling me her site was down. Whenever someone reports a site outage or hacking I drop everything and get on it immediately. In this case her web site had been replaced with a message saying her account had been suspended.

I immediately got in touch with the support team for her hosting company. These are the times when learn if you made a wise hosting decision, because no one wants to be left hanging when their site is down. I got in touch with a representative right away as I always have with Quality Host Online, which is why they’re one of my preferred hosting companies. It turns out they’d shut down the account because a script had sent a flurry of emails all at once. They assumed someone had hacked the account and was sending out spam.

I had a clue they didn’t though. Stephanie was particularly stressed because she’d just tweeted a link to a giveaway she was hosting on the site. You entered by posting a comment. WordPress automatically sends Stephanie an email notification when someone comments. Stephanie has a large Internet following, so hundreds of people were commenting at once, causing the blogging software to send 400+ emails in a matter of minutes. The hosting company assumed this was spam and shut down the site.

I explained what was going on and got Quality Host Online to turn the site back on, after which I immediately logged into WordPress and turned off the email notifications under Settings -> Discussion. Problem solved, all within 45 minutes.

The site crash was both good and bad. Bad because the site went down, obviously. But it was good to know that the hosting company monitors security issues like this and will be sure to shut down the site quickly if it ever does get hacked. You want to be alerted to a security breech as soon as it happens so you can minimize the damage. I’m glad to know Quality Host Online is on top of that. Now I also know to tell a client to turn of email notifications if they expect a flurry of comments to be submitted all at once.

I was frustrated recently when I couldn’t find a WordPress plugin to do something I wanted. One of the great things about the WordPress community is that someone has usually created a plugin for anything you want to do before you even realized you wanted to do it. In this case I was looking for a plugin that could randomly select a winner from one of my giveaway posts.

I routinely giveaway free products on my blog and allow people to enter by leaving a comment. Alas, there was no way to randomly choose a winner besides going to Random.org and then counting dozens of comments to find the Nth one. It was time-consuming and annoying. It also didn’t allow me to disqualify people who’d entered more than once, or to simply reduce their number of entries to one to even their odds.

So, I got out my text editor and wrote the plugin myself. It’s called Pick Giveaway Winner and it’s available on the Make My Blog Pretty plugin page as well as at the WordPress Plugin Directory. It was fun learning how to setup a plugin and submit it to the official site. It was less fun installing and using Subversion to commit my changes, which gave me flashbacks to my last job and all the command line horrors I thought I had escaped forever.

Hopefully this plugin will be useful to WordPress bloggers who do lots of contests. Let me know if you like it!

Recently a client wanted to know if we could have the same blog appear on two different sites with two different domain names. I told her yes, we could. Then I had to go figure out if we actually could.

Yes, kids, your web designer often doesn’t know how to do something until they surf the web and teach themselves how to do it. Self-instruction and a sense of adventure are a big part of this job. The technology field is always changing and there are always new things to be learned. It’s part of the reason this job is fun, because you constantly get to solve new puzzles and do things you didn’t know you could do.

My client was Erin Bried, author of How to Sew a Button: And Other Nifty Things Your Grandmother Knew. That book was so successful that her publisher signed her to write a sister book (er, brother book?) called How to Build a Fire: And Other Handy Things Your Grandfather Knew. Erin already had a blog for the “Button” site, and since both sites have the same how-to theme, she wanted the same blog to appear on both of them.

When I’m trying to learn how to do something new, I start by Googling keywords I think will lead to the answer. This led me to discover three possible ways to solve the problem:

Option #1: Modify the database prefix

This solution required that you install two copies of WordPress on the same host using the same database. (Note: This is not the same as setting up WordPress’s multi-blog option. Instead, these are two independent WordPress installations in separate folders on your web server that are using the same database.) You can install two copies of WordPress in the same database if you specify that they use different table prefixes. By default, all the tables in a WordPress installation start with “wp_” but you can change it to whatever you want in the wp-config.php file.

After you’ve installed both copies of WordPress, you then go into your second installation’s wp-config.php file and rename the table prefix to be that of the first installation. The second WordPress blog will now draw on the data from the first installation, but will remain separate.

This solution seemed way too risky for me to try on Erin’s sites since her first website was live and receiving steady visitors. Messing with the database and the configuration files in this way left a big opportunity for things to go horribly, horribly wrong. I also wasn’t sure if such a modification might screw up any WordPress updates I’d have to install in the future. So, I continued Googling.

Option #2: Crossposting plugin

If you activate the Xpost plugin on your blog, whenever you write a post it will also be posted at another blog that you specify, as long as that blog supports posting via XML-RPC. If someone comments on that post at either site, the comment will be posted on both sites. Having two sets of duplicate data can lead to problems if things get out of synch, but this seemed to be the best solution to the problem that I could find.

I installed the plugin, but because Erin’s sites are both managed within the same WordPress installation using the multiple blog option, the plugin wouldn’t work properly. Thus, I abandoned this approach.

However, as I was Googling for the link to that plugin to include in this post, I found another plugin called Cross Post which claims to work with WordPress MU, though I can’t verify whether it works or not. Regardless, I’m glad I hit a roadblock because it led me to ultimately find a better way to solve the problem.

Option #3: Theme switching

Stumped, I went to the kitchen and made a peanut butter sandwich. By the time I was done chewing, I had thought of another approach to the problem—theme switching. The Theme Switcher plugin allows visitors to use any theme installed on your site by adding the string ?wptheme=ThemeName to the end of the query string. I installed the plugin, visited the original blog with the “Button” theme, added the proper query string to the end of the URL to display the new theme, and voila! The original blog was being displayed with the new theme!

One problem: Now all the pages on the original blog were being displayed with the new theme. Not good. Once you switch the theme, it remains switched until you change it to something else or delete the cookie stored in your browser. I didn’t want visitors of Erin’s “Fire” site to head over to her “Button” site and see the wrong template.

To overcome this issue, I wrote a snippet of code to insert into the header of the new theme that made sure to load the proper theme at the right time:

if (is_page() && ($_SERVER["SERVER_NAME"]=='www.originalThemeSite.com') ) {
	if (! empty($_COOKIE["wptheme" . COOKIEHASH]) && $_COOKIE['wptheme' . COOKIEHASH]!= 'Original theme name') {
		$expire = time() + 30000000;
		setcookie(
			"wptheme" . COOKIEHASH,
			stripslashes('Original theme name'),
			$expire,
			COOKIEPATH
		);
		$redirect = remove_query_arg('wptheme');
		wp_redirect($redirect);
		exit;	
	}
}

This code first checks to see if you’re visiting the original site (not the new one) and if you’re on a page in the site (not a blog archive, search results page, individual entry, etc. which should display the new template). This checks to be sure you’re on a page that should display the original theme, not the new one. If that’s true, it then checks to see if you’ve got a cookie from the Theme Switcher plugin and if that cookie is not set to the original theme. If that’s true, it resets the cookie to the original theme name and reloads the page.

Once those changes were uploaded, the theme switching ran perfectly. To make the link to the blog a bit easier to remember, instead of http://www.domainname.com/blog?wptheme=ThemeName I used the Redirection plugin to send any visitors of http://www.domainname.com/blog to the theme-switched address instead. The same can be achieved by editing the .htaccess file, but I like using the plugin because it allows you to make changes within WordPress without having to FTP.

One other thing to note is that if you have more than two themes installed on your multiple WordPress installation, someone could hypothetically switch the theme of the blog to any of the other themes if they know their names. In that case, it’s good to only install the themes you need, and if you want to be extra safe you can add the code I listed above into the templates of all the themes on your installation.

You rarely ever want to be in a crash, be it a car crash, a market crash, or a blog crash. But if you are, first is covered by car insurance, the second is covered by the media, and the third is covered by me.

Recently, I had a client who needed to restore two blogs after her server crashed a few months prior. The server was home a personal site and a popular television fan site. A backup of both blogs exited, but due to various issues, she wasn’t able to obtain those files right away. The personal blog was put on hold for the time being, but the television site needed to come back online right away. Being a tech savvy client, she set up a fresh WordPress installation on a new host and kept the television blog going until she got the backup files from the old server.

When the client contacted me to restore her old entries, I realized we’d have to take different approaches to how we restored each blog. The personal site didn’t have any new data since the crash, so the simplest approach was to just restore the database for that blog. The television site required me to merge the old data (which included posts, comments, links, and tags) with the new data.

Not as simple as it looked. (The trouble with prefixes.)

The personal site sounded like an easy fix, but of course it wasn’t. The client had tried restoring the personal site’s database herself, but when she went to her blog she was faced with the WordPress installation screen instead of the posts and comments she expected. At this point she decided to call me for help.

I took a look at the database using PHPAdmin and realized that the tables in her WordPress database were missing the “wp_” prefix that is used by default. You can adjust the settings in the wp-config.php file to use whatever prefix you choose on your tables, or to get rid of the prefix completely, which appears to be what happened here.

To solve the problem, you can do one of two things. You can edit the wp-config.php file so there is no prefix. Or you can add the prefix to all the tables, as well as make edits to some values in the wp_options and wp_users tables as described here. Once I made the adjustments, the site was back up and running like it had been before. Plus, I got to feel like a magician!

Merging the old blog with the new

Next, I had to take on the trickier blog restoration. First, I set up a fresh WordPress installation on my development site and hooked it into the database the client provided me. The database was rather large, so I used Big Dump to import it quickly. I then I opened PHPAdmin and edited the site address in the wp_options table to match the address of the development blog. Then I was able to log into the site using my client’s old credentials. (NOTE: If you try viewing the WordPress blog at this point, you’ll probably see a blank screen because the template selected in the database doesn’t exist in your WordPress installation. Select a different theme and then you’ll be able to see the site.)

From there, I exported the blog using WordPress’s built-in export tool under Tools -> Export. This created a huge XML file of all the posts, comments and tags that I could import to the newer version of the blog, thus merging all the information. The XML file was a rather huge 60mb, which would most likely cause WordPress to timeout if I tried uploading it all at once. So I used WordPress splitter to divide it into 5mb files instead. Late that night, when web traffic was lighter, I imported each of the XML files into the client’s current blog. For a finishing touch, I exported her old WordPress links and imported those into her site as well. The process took about an hour to complete, but all her data was restored.

All’s well that ends well

The client was very happy with the end results. I was glad that I knew two different ways to restore WordPress blogs and knew which one fit each situation best. A straight-up database restoration is by far the quickest way, when it works, taking only a few minutes instead of the hour the XML import required. However, if you’re uncertain of your database’s integrity, like you might be if your site had been hacked, the XML import is a safe way to go too. The XML import doesn’t allow you to import any of your plug-in settings and other general settings though, which is another downer. I hope you never have a server crash, but if you do, hopefully you’ll now know how to recover from one.

When I started blogging on my own self-hosted site in 2003, PastaQueen.com, I chose to install the Movable Type blogging software. At the time it was one of the best blogging platforms available, plus it was free. It was also written in Perl, a programming language I was using at my day job at the time. Using Movable Type helped me develop my professional skills as I learned how to install and manage the software.

Now it’s 2010, I no longer program in Perl, and Movable Type is no longer my blogging platform of choice. Over the past several years, WordPress has made great strides to become a free, easy-to-use software package with a lively community of devotees and open source developers–emphasis on easy-to-use. After working with both Movable Type and WordPress, the latter beats the former in all areas. It’s insanely easy to install and update. A developer has probably already written a plug-in for any feature you might desire. And WordPress’s template files are much easier to read and manage than Movable Type’s.

I’ve thought about switching my blog, PastaQueen.com, from Movable Type to WordPress for over a year now, but the thought of transferring over 5 years of archives intimidated me. I was afraid of losing PageRank and search engine links if I failed to redirect my entries properly. However, after a spam attack at the end of 2009, the pain involved in transferring the site seemed worth the pain it would save me via WordPress’s superior spam-filtering abilities.

Here’s a step-by-step guide to the process I went through to transfer over 1000 entries and over 27,000 comments from Movable Type 4.2 to WordPress 2.9 on my blog, PastaQueen.com. Hopefully it will help anyone else out there brave the process of migrating their site from Movable Type to WordPress.

1) Backup everything

First, backup everything. This includes your Movable Type database as well as any images or other media you’ve uploaded to the blog. If something goes wrong during the migration, you’ll be happy you did.

2) Export your entries from Movable Type

Movable Type has a built-in feature to export your blog as a text file. Go to Tools -> Export and click the Export Blog button. At the prompt, save the text file to your hard drive.

3) Import entries to WordPress

I installed WordPress on the same domain as my blog, but in a different folder. Later on, I set up a redirect to point all the old pages to their counterparts on the new page. You can install your new WordPress installation wherever you like, but once you do, go to Tools -> Import and click on Movable Type and TypePad. After you install WordPress, make sure you update it to the latest version.

If you have a small amount of entries, you can use the upload option to import the data. My exported text file was 15.2mb which would have caused the upload to time out. Instead, I used FTP to send the file renamed at mt-export.txt to the /wp-content/ folder as directed.

The importer will then ask you if you want to map a user from Movable Type to an existing WordPress user, or if you want to create new users. After that, WordPress will start importing your comments and entries. In my case, it would time out after the server memory met its maximum limit.

There are two ways to proceed from here. If you have a text editor which handles large files, you can splice the file into smaller pieces that are smaller than your server’s memory limit. However, I was uncertain if I could simply splice the mt-export.txt on any line, since there may or may not be important information above the splice point that I didn’t want to cut out.

It seemed safer for me to just repeat the import process with the same 15.2mb file. Because the importer was smart enough not to import the data it had already imported, it was able to get farther through the process before the memory timed out. I kept repeating this process until everything had been imported. It was time-consuming, but I wasn’t in a time-crunch situation, so I chose caution over speed.

3b) Modify mt.php if your Movable Type entries were set to “Format: convert line breaks”

When I imported my entries, I was puzzled to see that where there were supposed to be two line breaks denoting a new paragraph, there was only one line break. This made my blog messy and hard to read. After some research, I learned this was happening because I had written my Movable Type entries with the Format drop-down set to “Convert link breaks.” When the entries were imported, WordPress did not translate this formatting correctly.

Luckily, there is an easy fix that I found on the site On a Lark. Open up wp-admin/import/mt.php and replace this line:

// Processing multi-line field, check context.

if( !empty($line) )
$line .= “\n”;

with this:

// Processing multi-line field, check context.

if( !empty($line) )
$line .= “\n\n”;

After I changed the importer, I deleted my WordPress installation and reinstalled it since this was faster than deleting all the poorly formatted entries and comments. I then uploaded the modified mt.php and imported my entries with the correct formatting.

4) Use Movable Type Blog Import Utilities to import tags

The WordPress importer script has one major flaw: it doesn’t import your tags. Tags are an important part of my site structure and I didn’t want to retag all my entries. Instead, I used the Movable Type Blog Import Utilities written by Simone Carletti to bring them over.

I downloaded the mt-utils.php file and uploaded it to the wp-admin/import/ folder. Now when I went to the Tools -> Import page I was presented with another option:

I clicked through to get to the tag importer, which required me to create a new template in my old Movable Type installation that would generate a text file I would use to import my tags. I did so, saved the text file and uploaded it according the tag importer’s instructions. Then I was greatly befuddled when it didn’t work.

Then I realized that my previous editing of the mt.php script had caused the tag importer not to work because it was trying to match the body text of the Movable Type entry with the body text of the WordPress entries. My WordPress entries had an extra line break inserted into them, causing a mismatch. To make the mt.php script work I found this line:

foreach($posts as $post) {
if ($postId = post_exists($post->title, $post->content, ”)) {

and replaced it with this:

foreach($posts as $post) {
if ($postId = post_exists($post->title, ”, ”)) {

Then I found this line:

} else if ($postId = post_exists($post->title, $post->content, ”)) {

and replaced it with this:

} else if ($postId = post_exists($post->title, ”, ”)) {

I tried importing my tags again and this time it worked.

5) Translating my Movable Type templates to a WordPress theme

Next, I had to go line by line through my Movable Type templates and translate them to a corresponding WordPress theme. I had to pay particular attention to what URL each link and image was pointing to and update it to the new folder on my site where WordPress lived. I also had to install some WordPress plug-ins to make some items in my sidebar functional, such as my Recent Posts widget.

This was the most time-consuming part of the process. I chose to do it after I’d imported all my entries so I could make sure everything would display properly with the actual content in it. I chose to leave any images I’d uploaded for posts in my old directory structure since I didn’t want to update every post to point the images to my new WordPress folder.

After the theme was complete, I double-checked all the pages from the archives, search pages, tag archives, and home page, etc. Now we were ready to launch!

6) Setting up redirects and launching!

Because my WordPress entries were in a different folder than my Movable Type entries, I needed to redirect the old posts to the new posts. I wanted to do this without breaking any links, especially any links from search engines. The best way for me to do this was to use the htaccess tool in the Movable Type Blog Import Utilities.

Again, I went to Tools -> Import and clicked on the MT Blog Import Utilities, this time going to the htaccess tool. Again, I had to add a new template on my old Movable Type installation to create a text file I uploaded to the utility. Once I did this, the utility generated code that I pasted in the .htaccess file that lives in the root directory of my old blog. This file can be used to tell search engines and browsers that a page has moved. I had to do some slight tweaking to the Movable Type template to get my URLs correct, but once I did, I was extremely happy with the results! I updated my htaccess file with the results and voila, the new site was launched! I double-checked the htaccess file by trying to access some of my old Movable Type generated files, and each time I was redirected to the WordPress version immediately.

7) Other items to consider

Each blog installation is unique, but another thing you might need to redirect are your site feeds. I added lines to my htaccess file that redirected my Movable Type feeds to the new WordPress feeds. Both Google Reader and Bloglines adjusted to the change seamlessly.

For now, I still have my Movable Type installation on my server, just in case I realize I need to move something over that I’ve forgotten. After a few more weeks I’ll probably back it up and then take it down.

Conclusion

Moving my Movable Type blog to WordPress took the better part of a weekend. I’m very glad I made the change though. Overall, it was slightly less painful than I imagined it would be, but I imagined it would be like chewing on a porcupine. The Movable Type Blog Import Utilities saved me a lot of time since the redirects were the part of the process I dreaded most. Thank you to Simone Carletti for writing those and making them publicly available.

If you too make the move from Movable Type to WordPress, your unique blog installation might run into issues that I didn’t have here. Hopefully the vast resources on the Internet will be able to help you through any situation. Good luck!

The LinkWithin plug-in has become very popular among bloggers because of its ability to link to related posts by displaying thumbnail images from those posts. We are a highly visual species, so the inclusion of images next to the links makes them far more appealing and increases the likelihood that readers will click on them. Linking to related posts on a blog encourages readers to spend more time on a site and each link helps increase search engine optimization.

This feature is particularly popular among food bloggers who frequently post pictures in their entries. Here is an example screenshot of the plug-in taken from a client’s site, Simply Sugar and Gluten Free:

The downside? Bloggers don’t necessarily want all of their posts to appear in the LinkWithin widget. One client of mine manages events, sponsored reviews, and site pages in WordPress that she doesn’t want to promote at the bottom of her posts. Looking around the LinkWithin site, no solution to this problem is listed, nor did they respond to my request for help.

However, I was able to find my own solution after I realized LinkWithin operates similarly to a search engine. It indexes your site to generate a listing of posts and has to update this index regularly to include your latest posts. You can control what parts of your site a search engine indexes by creating a robots.txt file on your site. You can get more complete information on robots.txt here, but for our purposes, all you have to do is create a file titled robots.txt in the root directory of your web server with this information in it:

User-agent: *
Allow: /

User-agent: LinkWithin
Disallow: /directory-or-pages-you-want-to-hide-from-LinkWithin/
Allow: /

The first block of code says that it’s ok for any search engine to index your site. The second block then tells the LinkWithin spider not to index anything in the page or directory listed after the “Disallow:” text. You can add as many Disallow lines as you want, either to hide specific pages, or to hide any pages within a directory. If you want to disallow a directory, but want to include one specific page in that directory, first disallow the directory and then add the specific page to the Allow: line.

I hope this helps anyone who’s run into this problem with the LinkWithin plug-in. Happy blogging!

There comes a time in every self-hosted WordPress blogger’s life when they will see this:

WordPress updates are like dentist appointments and oil changes, annoying yet necessary. You’ll get cavities and car problems if you don’t get checkups, and you’ll endanger the health of your blog if you don’t update WordPress.

Why do I need to update?

Think of your blog as a castle you need to defend. Inside the tower are all your precious blog entries. Outside the stone walls is an army of hackers, spammers, and other nasty people who at any time might launch an attack on your blog. The developers of WordPress know about your enemies, so they’ve built defenses like moats and drawbridges to keep them out.

Despite these obstacles, occasionally a hacker finds a weakness in your defenses and breaks into the castle. They might find a lose stone in the wall or find a way to dig under the castle into the courtyard. You can defend you blog from 99 different types of attacks, but it only takes that one hundredth unprotected way to allow someone to break through.

The developers of WordPress don’t just hang around the great hall eating slain deer. When they become aware of a new type of attack, they patch the vulnerability in their software and issue a new release. That’s when you get the message on your dashboard asking you to update. If you ignore it, you are making your blog more vulnerable to attacks.

Different types of updates

Each WordPress update has a release number, like 2.8 or 2.8.2. These numbers give you information about how major the update is, as well as give the developers a way to track what changes were made in which releases. The farther the number is to the left, the more serious the update is.

If the first number has changed, like from 1.0 to 2.0, this indicates a major change in the software. The developers might have rewritten major parts of the code or restructured how it works internally. This type of update can sometimes be tricky to handle since it usually involves updating your database or the way your files are structured. You should back up your blog before any update, but especially before this type of update.

The second number, or rather the first number after the dot, refers to a less major, yet still significant update to the software. It indicates that there have probably been some minor bugs fixed or a few small features added. You’re less likely to have problems when doing this type of update.

The third number, or the number after the second dot, refers to a small change in the software. This type of update is usually only released when a bug or security vulnerability needs to be fixed right away. Otherwise, they would wait to include the changes in one of the other types of updates.

Backup your files

You should always backup your WordPress blog before initiating an update, just in case something goes wrong. You can do this several different ways.

CPanel
If your host uses CPanel, you can create a backup through that interface by going to http://yoursite.com/cpanel and entering your username and password. There is an icon titled “Backups” that you can click to guide you through the backup process. Make a full site backup and download it to your computer. Also, open the file after you’ve downloaded it to make sure you have everything.

WordPress Plugins
If you don’t have CPanel, there are two WordPress plugins available that will create backups of your site. The WP-DB-Backup plugin backs up your database. Your database contains all the entries, comments, and other settings related to your blog. However, it does not include any images you have uploaded or any of your site’s themes or plugins. The WordPress Backup plugin saves copies of these files for you. You can have the backups emailed to you, or store them in a zip file on your server. Please note, if your web host’s server breaks down, you won’t be able to access any backups stored there. For that reason, it’s always wise to retain a copy on your local computer.

FTP backup
If neither of the options above are available to you, you can log into your site via FTP and download your blog directory to your computer. It’s slow and not the most efficient method, but it will suffice. If you don’t know what FTP is, you shouldn’t be backing up your blog this way anyway.

Updating WordPress

Ever since WordPress 2.7, it has become very easy to update your site. Log into your WordPress dashboard and go to Tools -> Upgrade. You should then see this screen:

Click on “Upgrade automatically” and you’ll see a screen where you’ll have to enter your web host login information. After you’ve entered this information the first time, it will be saved and you’ll automatically be sent to the next screen, which alerts you that WordPress has been updated. That’s it! It’s easier than flossing.

If you are upgrading from a version of WordPress earlier than 2.7, you will have to update your installation manually. Unless you are technically inclined and are 100% sure you have a backup, this is best left to a professional.

Backups are great. Knowing how to use them is better.

Let’s say the worst happens and for some reason your WordPress upgrade goes, horribly, horribly, wrong. Good thing you made that backup! However, if you don’t know how to restore your blog using the backup, it’s not much use to you. Restoring a site can be complicated and is probably a task better left to your web developer.

Please update!

It is up to you whether your update WordPress or not, but ask yourself, how valuable is your blog? If a hacker were able to infiltrate and delete everything, would you be able to brush it off or would you be brokenhearted? If it’s the latter, keep up with the updates. It doesn’t hurt to floss either.