Practical Uses for RSS

Have I ever mentioned that I love RSS feeds? I’ve been experimenting more and more with them, and I’m finding them incredibly convenient for both producing and consuming information. And I’m not talking about blog RSS feeds, although they are of course the most popular use; I’m talking about other ways you can use RSS in personal life and in business.

How do you use RSS? That’s not rhetorical. Really, I’d like to know how you use RSS. What tools are you using, especially script-based tools used for publishing, consuming, or mashing up feeds (not readers or aggregators)?

Here are some practical examples of RSS at work:

Lifestream: we’ve all heard of FriendFeed and Twitter — I’ve been experimenting with a similar lifestream service just for friends and family. I can’t tell you how much more I know about people by getting these RSS alerts about what they’re doing. And because it’s a personal service, I’m getting more real-life entries, and not the polish or image conscious alerts that I get on Twitter.

Web site content: almost any web-based content can be transformed into an RSS feed. The only real requirement is that the information changes regularly.

Upcoming events: RSS is a great way to let people know of events and activities that may be happening soon. It’s easy to turn an “events” page into an RSS feed.

New Products: Got an online store with new inventory added regularly? Add details about your newly added items to an RSS feed to let people know what’s just come in.

Weekly/Monthly Specials: Do you regularly make special offers on different products in your inventory? Again, RSS is a great way to tell people what’s on special this week or this month.

Newsletters: If you regularly produce an email newsletter, then consider converting it to RSS format as well as continuing to email it.

New Links: If you have a links directory, considering creating an RSS feed of the new links added to your directory in the last week or so. If you have a category structure within that directory, with links added often, you can create a feed for each category.

New Members: Do you run a public membership site? Recently joined members could be listed in an RSS feed with links direct to their profiles.

Ticker RSS Feeds: Do you have timely information to communicate to your customers? Automate the process with software and RSS can feed new critical information on an hourly basis (or more frequently if needed).

Vacation feed: I wrote a WordPress plug-in that allows you to import friends’ RSS feeds into your blog. Set a start and end date and time, a post frequency, and a minimum post length, then head out of town for your holiday!

Build an affilate site: sign up for an affiliate site like Commission Junction or Share a Sale, apply to several vendor programs, and then grab their affiliate feed to publish in your blog. Add your own product reviews and posts, and you’ve got a convenient money maker. Or import several relevant feeds with the vacation feed plug-in and you’ve got an auto-pilot income source.

What other things are you using RSS for? Please share!

Optimizing Server Performance, Part 3

Part 3 of 3: Part 1 | Part 2 | Part 3

This is part 3 in a series of posts covering server performance optimization. You should try to follow these tips in order; i.e. start at the top of post one and work you way through each post. If you’re coming here from anywhere other than Part 1 of this post, head there first before continuing on.

Most of the optimization tips presented herein will provide little incremental value. We’ve now reached the point of diminishing returns on our server tweaks.

Install Post Query Accelerator

Important: if you are using WordPress v2.1 or above, skip this step. This tweak is already contained in newer versions of WordPress.
The Post Query Accelerator plug-in improves your server’s perform-ance by ensuring that the MySQL query cache is able to cache query requests for posts.

1. Download the Post Query Accelerator plug-in.
2. Upload and extract it in your plug-ins folder.
3. Activate it in your WordPress administrative panel.

Edit Your Theme or Plug-ins

• Move comments to a separate page from your posts.
• Paginate comments.
• Optimize your plug-ins. Some are poorly written unfortu-nately.
• Optimize your themes: many themes query for information that is static in nature. If it’s static, it should be treated as such, and be hard-coded. Note that this tip would have a huge im-pact if we hadn’t already taken care of caching from the start.

Compress JavaScript and CSS

Use a CSS compressor to remove white space and comments. Try this one at Arantius, or the one at CSS Drive.

Use a JavaScript obfuscator to remove white space and comments, and shorten method and variable names. Or minify your code with jsMin. The space saved is a bit less than with obfuscation, but it could lead to fewer debugging problems down the road.

Place JavaScript at the Bottom of the Page

While a script is downloading, it will block downloading of other page components, even if those components are on different servers. Moving scripts to the bottom of the page alleviates this problem, but obviously not every script can or should be moved to the page bottom.

Additional Security

This is not an optimization technique. In fact, using this technique will hurt performance on your server (not for everyone; just for you when you are using your administrative panel). However, if you are beginning to receive high traffic, it might be a wise idea to harden the security on your WordPress installation.
The Admin SSL plug-in for WordPress will secure admin and login pages via SSL. You will need access to your own or a shared SSL certificate. Installation and usage instructions can be found on the developer’s site.

Use eAccelerator

“eAccelerator is a free open-source PHP accelerator, optimizer, and dynamic content cache. It increases the performance of PHP scripts by caching them in their compiled state, so that the overhead of compil-ing is almost completely eliminated. It also optimizes scripts to speed up their execution. eAccelerator typically reduces server load and increases the speed of your PHP code by 1-10 times.”

Tune your MySQL Database

MySQL performance tuning is a bit of a mystical art, and conflicting advice is common. Use these settings at your own risk, and only use them on a capable machine:

• connect_timeout = 5
• join_buffer_size = 1M
• key_buffer_size=64M
• max_allowed_packet = 16M
• max_connect_errors = 20
• max_connections = 500
• max_heap_table_size = 128M
• myisam_sort_buffer_size = 64M
• read_buffer_size = 1M
• read_rnd_buffer_size = 2M
• query_cache_limit = 8M
• query_cache_size =128M
• query_cache_type = 1
• sort_buffer_size = 16M
• table_cache = 512
• thread_cache_size = 256
• tmp_table_size = 64M
• wait_timeout = 14400

Tune Apache

IBM’s developerWorks is always a great source of information, including this article on Apache tuning.

Conclusion

Preparing for an expected traffic spike or responding to a traffic spike is a great problem to have, and you’re in good company. I hope these tips get you our or keep you from getting into a jam. If you have any additional tips, please post in the comments. I’m all ears.

Part 3 of 3: Part 1 | Part 2 | Part 3

Optimizing Server Performance, Part 2

Part 2 of 3: Part 1 | Part 2 | Part 3

This is part 2 in a series of posts covering server performance optimization. You should try to follow these tips in order; i.e. start at the top of post one and work you way through each post. If you’re coming here from anywhere other than Part 1 of this post, head there first before continuing on.

Most of the tips in this section could be classified as incremental improvements. Taken by themselves, they each have a small impact on overall performance; whereas the previous chapter’s tips all have rather significant effects.

Use Feedburner

Your RSS feeds are a silent killer that could quietly be eating 20 to 40 percent of your bandwidth. RSS readers automatically pull the latest posts from your site and aggregate them for your subscribers. And they do this often and many times, inefficiently.

You can use a service like Feedburner to handle this traffic for you. A word of warning for established sites: you’ll need to redirect your existing subscribers (preferably, automatically and seamlessly) to your new feeds.

If you don’t want to entrust your RSS feed to a third party, another option is to serve your feeds from another server or hosting account.

Profile your Pages

If you use a profiler to look at what is required to be downloaded to run each of your blog pages, you might be surprised. You’ll see a mixture of scripts, stylesheets, images, and maybe Flash in the page. Yahoo! determined that 80 percent of the end-user response time is spent downloading these front-end components.

If you’re a Firefox user, download the Firebug extension and examine each of your blog pages. This is a great way to examine the effect of your plug-ins, images, styles, scripts, ads, and anything else you might be serving to the public.

If you don’t use Firefox, you can get a lite profile by using a web-based profiler.

Trim the fat!

Any static file can be offloaded to another server. Aside from images (mentioned above), you can also offload JavaScript, CSS, Flash, and other static files. Amazon S3, Steady Offload, and even another hosting account or server are all options.

YSlow

Yahoo! also has a Firefox extension called YSlow. Its analysis of your page is based on 13 strategies that they use to optimize their pages for download. To use it you must first have Firebug installed. Read more about it on Yahoo’s Developer Network.

Reduce the Number of HTTP Requests

Reducing the number of HTTP requests required to render a page reduces server load.

Use Image Maps

Combine multiple, contiguous images into one image, and use an image map to link it. The file size will be the same, but you eliminate separate requests for each image. This is not a feasible strategy in all situations, but it should work for some.

Use CSS Sprites

You can combine all of the images in your page into a single image and then use CSS properties to display the desired image segment. Dave Shea has an article on A List Apart and there’s a good sprite generator from Ed Eliot and Stuart Colville (authors of High Perform-ance Web Site Techniques).

Combine Files

If you use more than one stylesheet or more than one script, consider combining like types together. The weight of the page won’t change, but you’ll reduce the number of requests required to build the page.

Use External Files

To allow for caching, your CSS and JavaScript should be stored in external files, and linked / imported into the page being downloaded to allow for caching.

Optimize Images

Most bloggers don’t use image editing tools to resize or polish their images. They should. By using a high-quality web graphics program like Adobe Photoshop or Adobe Fireworks (formerly Macromedia), you can ensure that you’re using the appropriate file format (e.g. jpeg’s for photos, gif’s for line art), and that your images are optimized for web viewing.

I often see JPEG’s decrease in size from 40 KB to 20 KB with a negligible impact on image quality.

Turn off or Slow Down Comments

If your blog posts are receiving a large number of comments, you can do one of two things to temporarily ease the load on your server:

Temporarily turn off comments

Find which of your posts is receiving heavy comment traffic, and disable commenting on it until traffic has died down a bit.

1. Open the WordPress administrative panel
   Go to Manage | Posts
   Deselect the “Allow comments” checkbox for each high traffic post

After a few hours or days, turn them back on again.

Update the Cache Less Frequently

Every time a new comment is posted, WP-Cache will try to update the static version of the page. Tell it not to. Comments might appear stale throughout the day, but it’s a better alternative than a server crash.

1. Open the wp-content | plugins | wp-cache plugin folder.
2. Open wp-cache-phase2.php for editing
3. Comment the line: add_action(’comment_post’, ‘wp_cache_get_postid_from_comment’, 0);

Pages will now not be regenerated every time a new comment is entered. After a few hours or days, uncomment the line. Thanks to Simple Thoughts blog for this tip.

Monitor your Site

This is not really an optimization tip, but monitoring your server will at least tell you when you’re in trouble. Think of it as a first line of defense or an early warning system. You know the call from the host will be coming!

I use iWeb for dedicated servers, and they have a free monitoring tool that’s simple to setup. Create an account, add an address to monitor, and then specify ports to watch and query intervals. Common ports include 80 (web), 8080 (Tomcat), 3306 (MySQL), and 110 (mail).

That’s it for part 2 of this series. Tune in tomorrow for the third and final installment.

Part 2 of 3: Part 1 | Part 2 | Part 3

Optimizing Server Performance, Part 1

Part 1 of 3: Part 1 | Part 2 | Part 3

I recently compiled a list of tips for people interested in easy ways to optimize server performance. The tips were directed at WordPress users, but many carry over to traditional web applications as well. After all, a blog is a specific kind of web site, so performance improvement tips for a blog will also improve the performance of a web site. That said, you will certainly get more value out of this book if you’re running WordPress and / or a MySQL database server. There are quite a few tips, so I’ve broken this post into multiple parts (yes, another one of those!).

My goal with this series of posts is to give you some fast and easy ways to prepare for traffic spikes. Of course, a crash due to a traffic spike is a good problem to have, but it would be better still if we could avoid it altogether. So to get you started quickly, try to follow these tips in order; i.e. start at the top of post one and work you way through each post. The tips near the top will give you the most bang for your buck, according to my determination of the trade-offs among tip priority, tip complexity, and time required for implementation. And keep tuning until you feel you’ve done enough to ensure that your server is able to handle the traffic. As we move lower down in this list, we’ll reach a point of diminishing returns. Each additional tweak could take more and more time for less and less improvement.

These posts contain the tips that I’ve picked up over the past several years. Some are from experimentation. Some were learned during consulting engagements. More are from administrators who have kindly shared their experiences with others. Many are from RTFM (“delving into the product documentation”). I’m not going to provide an overly deep explanation for each tip. You’re busy. You’ve got a site to administer.

I hope you find these tips useful.

Knowing When to Upgrade

Although it might be a hard decision to make, we must each make a determination about the viability of our current hardware and network. Not all servers, networks, or hosting accounts are created equally.

Server: your server must be physically able to handle high traffic loads. This means an adequate processor, plenty of RAM, and the often over-looked network card.

Network: hosts will have network limiters on their servers because they must parcel out their limited bandwidth to many servers at the data center.

Hosting account: your hosting account will have stated provisions for bandwidth. Larger hosts are usually much more generous with bandwidth. Some hosts will also make bursting provisions, which permit periodic spikes in traffic that are not maintained over long periods.

Upgrade Path

So if you’re using a shared hosting account (good ones are Lunar Pages and BlueHost) and your host is forgiving, you might need to be moved to a newer, more powerful server. You might also be forced to upgrade to a VPS plan. I am not a fan of entry-level VPS plans, so if you’re forced to go this route, don’t choose the least expensive plan and hope to maintain the response times you have with a shared account. A good VPS provider is Spry. Another option is to try moving to a host that uses grid service or cloud hosting, like Mosso or Media Temple.

If you’re using a VPS plan, you might need to consider upgrading to a more expensive plan that gives you a larger share of the processor and RAM. Or at least negotiate for an increased burst rate. If you’ve outgrown VPS entirely, you’ll need to move to a dedicated server. Good providers are iWeb and Liquid Web.

If you’re already using a dedicated server, you might need to look into upgrading your network card, adding RAM, using more and multi-core processors, or upgrading your hard drives. Or, you might need to add additional servers and configure a load-balancing solution. Or move MySQL to a server or servers on its / their own.

Hard decisions, especially when each step up the ladder involves increasing amounts of money.

Enough with this, let’s get started with the tips!

Install WP-Cache

WP-Cache is a WordPress plug-in that can have a dramatic impact on the performance of your blog. By dramatic, I mean anywhere from a 1,000 to 10,000 percent performance improvement, reducing response times by a few tenths of a second in many cases.

By default, all pages requested from WordPress are built dynamically; with WP-Cache, when a visitor requests a page or post, a stored, static version of the requested page is presented instead.

1. Download the WP-Cache plug-in.
2. Upload and extract it in your plug-ins folder.
3. Activate it in your WordPress administrative panel.
4. In Options | Reading, make sure that gzip compression is not selected.
5. Open the Options | WP-Cache subtab, and it will attempt to configure itself.

Deactivate Plug-ins

It is possible to use too many plug-ins. Each plug-in requires additional server resources and processing time, and some require the use of additional software.

In all situations, a good practice is to only use plug-ins that you need to help you administer your blog, or that enhance the experience of your reader. In high-traffic situations, you need to be ruthless about trimming the fat.

One of WordPress’s nice features is being able to quickly activate and deactivate plug-ins. Go through your list and see if any plug-ins could be removed temporarily while you meet a spike in traffic.

Use Your Visitors’ Browser Caches

First-time visitors to your page need to download all of the page components (HTML, CSS, JavaScript, Flash, images, etc.) before the page can be viewed, and this can require a fair amount of bandwidth.

But you can use the “Expires” or “Cache-Control” headers to make sure that their browsers cache those components. This won’t help with the first page request, but all additional page requests will avoid downloading those same resources again.

There are quite a few considerations to look at here, but many can be avoided if we just keep things simple. It won’t be optimal, but it will give you the most bang for your buck.

1. Go to Presentation | Theme Editor in your WordPress administrative panel.
2. Click the “Header” link on the right.
3. At the very top (this must come before any other output), enter:

   ?php

       Header("Cache-Control: max-age=172800, must-revalidate");

       $strExpires = "Expires: " . gmdate("D, d M Y H:i:s", time() + 172800) . " GMT";

       Header($strExpires);

   ?>

You can also set an expiration date far into the future, but you run the risk that the user never sees the content that you’ve updated unless the file name changes. Setting expiration to two days (172,800 seconds) is a good tradeoff to get you past any traffic surges. Adjust as necessary.

Optimize your Database

The larger your database, the more advantageous this tip will be.

1. Open phpMyAdmin
2. Open your WordPress database (not information_schema)
3. Perform a backup just in case
   1. Click the “Export” tab
   2. check the “Add DROP TABLE / DROP VIEW” checkbox;
   3. check the “Complete inserts” checkbox;
   4. check the “Save as File” checkbox;
   5. Click the “Go” button and download your backup
4. Optimize your tables
   1. Click the “Structure” tab
   2. Click the “Check all” link below the table list to select all tables
   3. In the “With selected” drop-down box, select the Optimize tables option.

Serve your Images from Somewhere Else

This tip is often a tough sell, because it does require more time than the others to implement; however, its effect can be large.

Images eat a lot of your bandwidth, especially in blogs, and result in additional requests to your server. If you find that you use images in your posts, consider serving them from another server.

A user’s browser can only open two resources from one address at any one time. Offload your images, and your viewers’ browsers can open four simultaneous connections.
So your server is using less bandwidth, is being hit with fewer requests for resources, and your viewer’s browser is receiving twice as much content simultaneously. Not bad.
A service I would wholeheartedly recommend is Amazon S3; to a lesser extent, Steady Offload and Flickr.

Amazon opens up their server farms for several uses, one being their S3 storage service. You can access Amazon’s rock solid reliability for a very small price: $0.15 per GB per month for storage, and $0.20 per GB of bandwidth.

Assuming your average blog page contains 100 KB worth of images, you currently have 100 posts in your blog, and you post at a rate of 100 posts per year, your image storage cost is literally less than $0.01 per year. Your bandwidth costs would work out to $2 per 100,000 visits.

Steady Offload is an interesting service that mirrors your static content on their site. It’s effortless to set up, and you only pay for bandwidth you use. For high-traffic situations, I still would prefer Amazon’s reliability.

Flickr is a great option if you have a personal or non-commercial blog. They have restrictions against professional and corporate use, which can limit its usefulness for some. Also, it’s an image-sharing site, which might be a concern. On one hand, your images get more traffic, on the other hand, your images could be “involuntarily shared” with others.

I’d recommend that you stay away from ImageShack and PhotoBucket, although use of both is popular. ImageShack’s bandwidth per hour limit makes it useless during traffic spikes and both ImageShack and PhotoBucket are frequently blocked by corporate firewalls, and it’s never a good idea to alienate portions of your audience.

Don’t Touch your MyISAM Tables!

This is not a to-do tip, but rather a not-to-do tip. It had to be mentioned, as it’s a very common source of questions with folks who are just digging into MySQL. Many people contend that converting your MySQL MyISAM tables to InnoDB tables will have a large impact on performance, and this is true in certain situations.

InnoDB tables feature row-level locking, meaning that when a row in a table is being edited, only that row must be locked. In MyISAM tables, the entire table must be locked to edit a row.

In blogs, the only time you would require table locking is when content is being added, e.g. a comment or a blog post. As readers outnumber commenters and posters by an overwhelming majority, using InnoDB tables for a WordPress blog would actually hurt per-formance, not improve it.

If you were considering it, don’t do it!

That’s it for today. Check back in tomorrow for part 2 of this post.

Part 1 of 3: Part 1 | Part 2 | Part 3

Choosing a Blog Platform

Never has it been easier to setup and maintain a blog, and a large part of the reason is the blogging platform. The blogging platform includes the blogging software itself, along with the hardware and infrastructure required to power the software.

The two main categories of platforms are hosted (often referred to as “services”) and self-hosted (often refereed to as “standalone”).

Hosted Blogs (Blog Services)

Hosted platforms refer to services whereby a service provider grants you access to their hardware, network connection, and software, and you create a blogging account to use on that platform. This would be very similar to signing up for an account at a site like Facebook or MySpace. As far as you’re concerned, there’s nothing more than a web page where you enter and view your information. Everything that goes on behind the scenes is con-trolled by someone else, and you have no stake other than being a user of the service.

Within the hosted blog space, you have a few subcategories of service, as well. There are pure blog plays—your account is used to create a blog, and the end result that gets traffic is a blog and a blog only.

There are also social networking services that build blogging into their platforms. MySpace has a very rudimentary blogging system, though I don’t believe that it meets the accepted requirements of a blog. Then there are services that fall somewhere in between, like Xanga and Vox, which offer a mix of media and social networking.

Some pure play examples include:

• LiveJournal
• TypePad
• Blogger
• Blog.com
• Wordpress.com (not to be used with the software available from Wordpress.org)

Advantages of Hosted Platforms

• Inexpensive: many are free; others (like TypePad) are offered with multiple price points
• Simple to setup: just create an account and get to blogging
• Page rank: search engines might give more favorable weightings to hosted blogs, but note that this, if it is true, would only hold true for low-traffic blogs
• Automatic updates: you don’t have to worry about keep-ing hosted software updated and patched

Disadvantages of Hosted Platforms

• Inflexible: there are fewer configuration options with hosted platforms. This often results in applying workarounds or “hacks,” which make moving off of the platform cumber-some.
• Fewer design choices: you typically only get to select from a limited number of average designs, and you often can’t make updates to the standard designs
• Generic URL: some hosted platforms will allow you to use your own URL, but the process can be complex; others don’t offer the option at all
• Less control: you are at the mercy of the platform
• No commercial sites: some platforms will not let you serve ads on their platforms

Self-hosted Blogs (Standalones)

Self-hosted platforms consist of a web hosting account you establish with a data center, and the blogging software you install on the data center’s server.

Some self-hosted solutions include:

• WordPress (not to be confused with the hosted accounts at WordPress.com)
• MovableType (the self-hosted version of TypePad)
• SubText
• typo
• Apache Roller

Advantages of Self-hosted Blogs

• Design flexibility: you have full control over design and lay-out
• Great software: the best software exists on self-hosted plat-forms
• Custom URL: custom URL’s are ubiquitous on self-hosted platforms
• Adaptability: your blog can change as your needs change

Disadvantages of Self-hosted Blogs

• Difficult setup: setup can sometimes be difficult
• Cost: while the blogging software is free, the hosting platform will cost you money
• Hosting issues: unless you choose a good host, you might have to suffer from downtime or poor support.
• Upgrades: you will need to keep your software patched

Blogs are really specialized versions of content management systems (CMS), which are systems used to manage the computer files, images, media and content of a Web site. CMS’s generally support workflow, which is a process for moving content from creation, through approval, to publishing with automated routing and notifications. CMS’s usually support a large number of authors and editors (sometimes collaboratively) in a distributed environment.

Blogs are simplified versions of CMS’s, though they retain many of the same characteristics, and I do know of some people who use WordPress in place of a full-blown CMS.

Popular CMS’s include:

• Textpattern
• Drupal
• Joomla

Which Platform is Best?

It’s a personal decision. The majority of my blogs are self-hosted. I prefer the flexibility and design options available to me in self-hosted software. Self-hosted solutions are also much more professional. Blog readers can tell a difference.

Often, whichever blog platform you start on, you finish on. As  your blog gets larger and more backlinks are created, you start to become handcuffed to the platform. This blog, for example, was hosted on Typepad until two weeks ago. Not because I preferred Typepad, but because it started as a quick and dirty personal blog that continued to grow. That’s one reason I always recommend that peopled start blogging on a flexible platform–you always have room to grow.

In February 2007, I conducted a usability study with several readers, placing the same content on two different blogs, one hosted, and one self-hosted. Both were setup to take full advantage of the underlying platform, meaning I made the blogs look and behave as best as I could with the tools I had available. Universally, the self-hosted blog was perceived to be higher value, and the content was considered to be more credible.

Note that this was a small study, and usability tests are not what I would consider scientific by nature, but the anecdotal evidence is worth considering.

For my money, I will always go self-hosted. Your mileage may vary. If you just want to try this blogging thing out, try one of the hosted services. But if plan to maintain a professional blog, I think you’ll find yourself upgrading quickly.

I’ve used six different blogging services, hosted and self-hosted, and I’ve dug around the API’s of several. WordPress is hands-down the winner.

• WordPress has an extensive theme directory. Themes are used to change the look and feel of your blog. You don’t need to know how to design or code a thing.
• Thousands of themes are available around the web, and if you want a premium theme, you can find quite a few of them. Premium themes are great for sites that you want to monetize, or where you want to convey a professional presence.
• WordPress has an extensive plug-in directory. Plug-ins enable you to add interesting functionality to your blog. How about a map of your recent readers? Adding a contact form to your about page? Showcas-ing affiliate products? Fighting spam? Improving your search engine rankings? Mobilizing your site? If you can think it, a plug-in is probably around to do it.
• WordPress offers complete administrative control over your blog. There are very few things that you can’t do with your WordPress blog if you’re self-hosting.
• WordPress has excellent user management, using a role-based security model that supports multiple levels of access. For example, authors can write articles, editors can publish those articles after approval, adminis-trators can change the design of the blog.
• WordPress fights spam. A comment spam plug-in installs with Word-Press by default. Say goodbye to that annoying Blog Blaster spam.
• WordPress has an active and enthusiastic contributing developer community. This means that software updates are frequent, bugs are fixed regularly, the software is mature, and requested features are actually added to the product by people who care about and use the product. The WordPress community is the reason why WordPress is such a powerful and easy-to-use product. It is a real gem.
• WordPress has an easy-to-use page editor. With pages, you can really blur the lines between what is a web site and what is a blog. Pages allow you to store static content (i.e. content that isn’t regularly updated). Pages are especially common for people who use WordPress as a content management system. For a lite version of WordPress-as-CMS, check out the Thirty Days to Blog Traffic site.
• There are a large number of SEO (Search Engine Optimization) reasons for choosing WordPress, but a discussion of them is outside the scope of this book, so I’ll just say that WordPress has paid atten-tion to how to help search engines find your blog.
• There are also plenty of SEO and traffic-related plug-ins available for WordPress.
• It’s free! There are other free blogging packages out there, but none offer the same combination of power and simplicity that WordPress offers.

Here’s an interesting exercise: Google “moving to WordPress.” People are moving for a reason!

In a nutshell, if you’re blogging, you need to be using WordPress. It’s that simple. WordPress has built a fanatical community and support base for a reason: they’re the best. If you find yourself on another platform like Blogger or TypePad and you want to move to WordPress, I’ve detailed the migration process step-by-step.

How to Port Your Blog from TypePad to WordPress (Part 2)

This is Part 2 of a 2-part post on migrating your blog from TypePad to WordPress. << Part 1

While the information in this post uses TypePad as the subject. much is transferable to other platforms.

Part 1 discussed overall migration considerations, preparing for the move, exporting data from TypePad, Importing data into WordPress, cleaning up images and file references, and taking advantage of some of WordPress’s features.

Redirect Traffic to your New Blog

If you’re going to drop any traffic, it’s going to happen right here!

1. Make sure the receiving server is ready for traffic.
2. Go to your domain registrar, and point your domain to the nameservers on your new hosting account or server. You’ll probably also have to delete the MX records that still exist.
3. Wait.
4. Ping your domain name to see which IP address responds, TypePad or your new server. As soon as the responding IP address is your new server, continue.
5. In your WordPress administrative panel, go to Options | General, and make sure your blog is pointing to your domain name, and not the temporary URL or IP address you used to setup your WordPress blog. If you’re using a new domain, this step doesn’t apply to you. Important: don’t perform this step until you know your domain is pointed to your server or you’ll lose access to your administrative panel. If this does happens to you, just open up your MySQL database, and update the entry in the wp_options table.
6. After cutover, go to your TypePad control panel and select Site Access | Domain Mapping. Remove your domain mapping. This step doesn’t need to be done, but I prefer to make a clean break.

DNS is painful. You need to coordinate different servers in different locations, and you can never be sure if what you see is what someone else will see (until propagation completes). So when something goes wrong, it’s often hard to pinpoint where the problem is. If you do things in the above order, you shouldn’t run into any problems. [Read more]

How to Port Your Blog from TypePad to WordPress (Part 1)

This is Part 1 of a 2-part post on migrating your blog from TypePad to WordPress. Part 2 >>

While the information in this post uses TypePad as the subject. much is transferable to other platforms.

You’re reading this post for one of several possible reasons:

• You’re looking into moving your TypePad blog to a self-hosted WordPress version, and you want to know what to expect
• You’re in the process of moving your blog, and something isn’t going right or something appears a bit wonky
• You’ve already moved your blog, and you want to make sure you’ve dotted your i’s and crossed your t’s
• You like me and you’re bored

When Quick Migrations Get Ugly

I have good news and bad news for you. Migrating to WordPress is incredibly easy (for the most part). And for most people, it should be a relatively simple move, even if some parts can get rather tedious:

• If you’ve hacked TypePad with any custom styles, stripping out the remnants of those styles can be painful
• If you have a large number of posts, error checking can be tedious
• If your posts are thoroughly cross-linked, you’ll have to re-link them
• If you’ve used a lot of photos in your posts, you’ll have to re-reference them and create your own thumbnails

That was the good news. The bad news is that to minimize downtime, to make sure your feed is available to your readers, and to ensure that you maintain your page rank after the move, you will have to jump through some hoops. So the physical migration itself is easy — moving your content from one blog on one server to a new blog on another server — but attending to the other concerns is what could cause you some headaches. If you have a high page rank, and want to maintain it, you’ll have to jump through some hoops. If you want to minimize site and feed downtime, be prepared for a little extra work.

There are many other smaller considerations, but the above are what consumed most of my effort. At the risk of stating the obvious, you probably noticed that characteristics of larger, more active blogs lend themselves to the more difficult migrations. Even still, I wouldn’t expect the total migration time to exceed 15 to 20 hours. For smaller, simpler installations, 1 hour would seem like an eternity.

Another thing I’d like to point out before going further is that I’m assuming that you’re going to be transferring a domain name along with porting your blog. That is, your TypePad blog is available at http://yourblog.com, and it should maintain that address when the migration is complete. If you’re moving from http://youraccount.typepad.com to http://yourblog.com, then the process is far simpler, because you won’t need to worry about the DNS propagation lags. Of course, you’ll also lose any page rank (at least temporarily) that you’ve worked to achieve, so understand that before you go in. [Read more]