As part of my experiments with social media sites I came across the iBlogStats site.  Its a great external dashboard for your blog, but it gave me a nasty shock by highlighting I had about 50 xHTML validation errors on my homepage!

Over the past month I’ve found that my posts have consistently had 40 to 50 validation errors before I manually hunt them down and resolve them.  All of the posts were published using a combination of Windows Live Writer (WLW) and Wordpress.  While I find them to be very easy to use the lack of quality in the output (and the effort required to repair it) made me wonder whether I’d chosen the right platform for my blog.

Some of the errors I was experiencing:

• paragraph end tags with no begin tag
• div tags surrounded by paragraph tags
• attribute construction errors where a title attribute had been moved within hyperlink, and had been concatenated with the href attribute instead of relocated after it
• img tags that weren’t properly terminated

… and the list goes on.  To make matters worse I couldn’t resolve the errors directly in the Wordpress online editor because it insisted on converting div tags to paragraph tags, destroying the visual style of the posts in the process!  I had to maintain a copy of the original post HTML elsewhere, edit it in a text editor then paste the repaired HTML over the existing content shown in the Wordpress editor.  A rather tedious process.

A little time on Google found some tips that have dramatically improved the quality of automatically generated xHTML:

• Turn off the visual editor in Wordpress: 
  (via Weblog Tools Collection and More than scratch the surface) 
  In Wordpress’s admin interface, switch to the users tab and edit your current user. Uncheck the "Use the visual editor when writing" option.  This resolves the "div converted to paragraph tag" issue mentioned above, and various other errors introduced when Wordpress "fixes" your HTML, so validation errors can now be repaired online.
• Configure Windows Live Writer to publish xHTML:
  (via whateverblog)
  Windows Live Writer did such a good job of detecting my blog settings that I didn’t even think of manually configuring it to publish xHTML.  How embarrassing! In WLW select the Weblog\Edit Weblog Settings menu item.  Open the Advanced configuration options pane.  Make sure "Markup Type" is set to XHTML.
• Be careful where you "Insert Tags"
  If you use the Web Layout view to write your post, be careful where you call the "Insert Tags" feature.  WLW uses paragraph tags and non-breaking space to add blank lines to your post.  If you are not careful you might insert your tags after a non-breaking space on a blank line and inadvertently wrap the tag’s div directly within paragraph tags.  When you validate the results this will be highlighted as an error.

While some errors remain the volume is more manageable (a couple per post) and they tend to be easier to resolve.  The most painful one remaining is the "attribute construction error" but it is looking more and more like this has been introduced by one of the plugins I’m using.  I’ll continue debugging my configuration and report back if I ever manage to track this last major bug down!

Best practice for self-hosted blogs is to install your software in the site’s main directory instead of a subdirectory. It may seem a small issue but not doing so dilutes the value of your site identity and brand. After all a site called http://tech.niques.info/blog/ would indicate the blog is just a part of a larger site, not its primary focus. That would send mixed messages to your audience.

Unfortunately I was thinking about technical maintenance instead of branding when I originally setup this site and installed into a subdirectory. While Wordpress gives you options to cloak this fact, I was beginning to find that some plugins didn’t cope well with the configuration. So I decided to “bite the bullet” and move the installation to the root directory for the site for technical as well as branding reasons..

A quick scouring of the net turned up madteckhead’s Wordpress 2.2 Server Migration. While some other articles seemed to more closely mirror my problem I found them to be a little too simplistic and wasn’t confident they would work. So I’ll be describing how I adapted madteckhead’s instructions to safely migrate Wordpress between directories on the same server.

The instructions will assume Wordpress is installed immediately below the root directory for the website (e.g. in http://tech.niques.info/blog/), and you have write access to the directory containing the root directory for the website. The examples will use the following directory structure.

. /
./oldrootdir/
./oldrootdir/currentwordpressdir/
./newrootdir/
./oldrootdir-backup/

Instructions

Note: You will need to adjust the instructions to reflect the directory structure of your site.

1. ssh to your server and navigate to the parent directory for your Wordpress installation. Backup the current installation files using a command like:

   cd ./oldrootdir/
tar -cvf ../wordpressbackup.tar currentwordpressdir/

2. Move up a directory level (i.e. to the directory above the website), then restore the files. Rename the resultant directory to be the new root directory for the website: cd ..
tar -xvf wordpressbackup.tar
mv currentwordpressdir/ newrootdir/
3. Copy the contents of the current website root directory across to the new directory. This ensures your .htaccess, robots.txt and other key files make it across to the new directory: cp oldrootdir/* newrootdir/
cp oldrootdir/.* newrootdir/
4. Change to the new website root directory. cd newrootdir/ The following line needs to be changed in the wp-config.php file to reflect the new database we will create: define('DB_NAME', 'newdatabasename'); // The name of the database
5. Log into phpMyAdmin for your database server. Select the Export option, ensure the current Wordpress database is selected and that the export uses the SQL format, then export the database to a file. For safety’s sake I would recommend that you do not use the “Add DROP DATABASE” option.
6. Take a copy of the export file. Using your favourite text editor, you will need to find and replace a number of items in the file:
   

   Reason	Old Value	New Value
   Create a new database	CREATE DATABASE `olddatabasename’`	CREATE DATABASE `’newdatabasename’`
   Change directory	server/currentwordpressdir/	server/
   Update Blog Address option	’siteurl’, ‘http://server/currentwordpressdir	’siteurl’, ‘http://server’

   If you didn’t use the Wordpress Blog Address option then you can skip the last change above.

7. In phpMyAdmin go back to the home page and select the Import option. Import the file you have just edited and it will create the new database referred to in step 4), and populate it with your current Wordpress data.
8. Move up a directory level (i.e. to the parent directory for the website), then switch the swap the old and new versions of the website: cd ..
mv oldrootdir/ oldrootdir-backup/
mv newrootdir/ oldrootdir/
9. Test you blog. Make sure that:
   • Your homepage functions
   • Individual posts display correctly, including the pictures
   • Individual pages display correctly, including the pictures
   • RSS feeds are valid
   • Admin pages are accessible

   When testing pay particular attention to any plugins that rewrite URLs to make sure they are still operating OK.

10. If something is broken normal troubleshooting rules apply. Slowly disable extensions in the impacted area until things are working again, then either update the configuration for the plugin or widget, reinstall it, or find an alternative that does work. In my case my sidebar died, but after removing widgets one at a time I discovered the “Text 1″ widget was the culprit. Removing the widget then adding it again resolved the problem.

Note: If you encounter an issue you are unable to resolve, reversing the changes made in step 8 will restore your previous installation to working order,

Once you have successfully moved your Wordpress installation there are a couple of other items you will need to consider:

• If you have a robots.txt file you will need to confirm it is still valid given the changed website layout Google Webmaster Tools can help you with this.
• If you did not use the Wordpress Blog Address option to hide the previous location of your installation, your permalink structure will be broken by this move. You can either try Scott Yang’s Permalink Redirect plugin to redirect requests from the old Permalink structure, update your Permalink structure to reflect the old location of your archives, or manually update your .htaccess file to redirect old permalink requests to the new location.

There have been other posts describing how to move Wordpress between directories but these tend to be destructive processes that are difficult to back out if things go wrong.