Archive for April, 2008

WordPress Server Migration Process

I have found that I am moving a fair number of WordPress sites around to different servers. The following is an outline of the steps I have found useful that can reduce the complexity (and cost) of these migrations.

Yes, I know that a bunch of these steps couple be eliminated with simply copying and moving databases around. That is great if you are very familiar with db managed and related tweaks. This is more of a dummies guide to the transfer. Please though do comment and let me know your thoughts and best practices you have found for such migrations.

Option 1: Database familiarity required

  1. Setup up a Web server with mySQL and Apache. If a hosting recommendation is required then I recommend WestHost that can provide this service for less than $35.00 per month.
  2. Setup a mySQL database to match the database name, ID and password in use by the currently active WordPress installation. This is found by looking in the active site’s wp-config.php file.
  3. Install the version of WordPress currently in use for the active site. To simplify matters, copy the wp-config.php file from the active site for use on the new site. It is not uncommon for the site to be operating under old versions of the software. Archived versions are available for download at http://wordpress.org/download/release-archive/.
  4. Back up the database. The easiest way to do this is to install the WP-DB-Backup plug-in. After this five minute install an admin can then create and save this backup of ALL tables.
  5. ZIP the database backup and use phpMyAdmin to restore the database to the new server. Instructions may be found here on http://codex.wordpress.org/Restoring_Your_Database_From_Backup
  6. ZIP the entire active site. This is then uploaded to the new site to replace the default WP files used during the install. (Some folks have said to skip the initial install of WordPress and rely on the database and file transfer for the install. If this works for you – great. I like the initial setup first to confirm that the dB is setup and the software works properly. This helps identify other issues such as the server itself not being configured properly for WordPress. Sure, this is wiping out the initial install. But the confirmation of the WordPress compatibility with the server is nice.)
  7. The site will then by default be set to function at the live site domain. The site needs to be checked before the domain name is transferred. Either set the internal DNS for the server and computer connection to the new server or enter the dB and change the values to one that will work to check the site.
  8. Review the site and check for any errors. The only error I have ever run across is that occasionally the path information to the files on the server need to be adjusted in the dB. This is a very quick task for someone familiar with myPHPAdmin.
  9. Switch over the DNS to direct traffic to the new server.
  10. Adjust the new servers Apache configuration to direct the domain traffic to the WordPress directory. This is usually done via a control panel.
  11. Adjust the WordPress settings to serve up the site under the new domain. This is done within WordPress’ main settings page.
  12. Check site, Feedburner and Google Analytics and other external hooks.
  13. Once comfortable with the new site, the old site may be decommissioned.

Option 2: In this option the client does not have to mess with the database items at all. I have found that this works well with sites that do not have too many posts.

  1. Setup up a Web server with mySQL and Apache. If a hosting recommendation is required then I recommend WestHost that can provide this service for less than $35.00 per month.
  2. Setup a mySQL database to match the database name, ID and password in use by the currently active WordPress installation. This is found by looking in the active site’s wp-config.php file.
  3. Install the version of WordPress currently in use for the active site. To simplify matters, copy the wp-config.php file from the active site for use on the new site. It is not uncommon for the site to be operating under old versions of the software. Archived versions are available for download at http://wordpress.org/download/release-archive/.
  4. Set up the links (blogroll) items on the new site.
  5. Zip the entire content of the entire active site. This is then uploaded to the new site to replace the default WP files used during the install.
  6. Export all content using the built-in export utility and deliver the XML export file to the client. This should end the use of the old server.
  7. Uses the built-in import function to import the provided XML file. They select to create author accounts as prompted by the import.
  8. Adjust user accounts as needed.
  9. Review the site and resolves any errors.
  10. Switch over the DNS to direct traffic to the new server.
  11. Adjust the new servers Apache configuration to direct the domain traffic to the WordPress directory. This is usually done via a control panel.
  12. Adjust the WordPress settings to serve up the site under the new domain. This is done within WordPress’ main settings page.
  13. Check site, Feedburner and Google Analytics and other external hooks.
  14. Once comfortable with the new site, the old site may be decommissioned.

,

No Comments

Use the right technology for a social media press release or social media newsroom

I have been a proponent of the social media press release (SMPR) and the social media newsroom (SMNR). These efforts by Todd Defren and others have pulled together into a package much of what online communications folks have been saying for awhile. Over at my agency we have even managed a fair number of tests and implementations. In these implementations a common roadblock has been the lack of the clear understandings of the underlying technical requirements.

Many others have stated that an SMPR or SMNR must be built out using blogging technologies. Blog technologies enable the RSS feeds, XML formatting, tagging, commenting and many other functions. They also enable search engine optimization in manners expected of social media search engines such as Technorati, Bloglines and others.

This said, I have found the technical teams that implement the strategies sometimes prefer to hack up an existing CMS to force it to fit a blogging and SMPR/SMNR framework. This has resulted in less than optimal performance. This lack of performance is then blamed on the idea of an SMPR itself. In reality, had the efforts been built out within a dedicated package the performance would have been satisfactory.

Take away – build out a dedicated SMNR site within a blogging CMS such as Movable Type or WordPress. We have found that the hosted TypePad environment is also customizable for the solution. Using such technologies allows us to focus time, energy (and budget) on the content rather than transforming a non-blogging CMS do what others provide right out of the box.

, , ,

No Comments

Identify Your RSS Feeds on Your Home Page

A client was wondering why individuals and search engines are not finding their news feed. They have several RSS feeds off of a number of internal pages. However, these deep links were not found by individuals or search engines.

This is not uncommon. The best practice for the solution is to identify the RSS feeds on the site’s home page. This identification will then result in the display of all news feeds when the home page URL is placed in a news reader. In addition, search engines will then be able to more readily find and scan the feeds.

The code is simple. You should have the following placed on the home page so that the RSS feeds may be discovered by crawlers and readers. One line is placed in for each RSS feed. Change url/to/rss/file to the full URL for the RSS file.

<link rel="alternate" type="application/rss+xml" title="RSS" href="url/to/rss/file">

This should be something that is coded into all sites we manage that have RSS feeds. Any TypePad or WordPress sites have this function built into the home page via the CMS.

No Comments