Posts in the Software category are about software applications for which I’ve gained experience either using, troubleshooting, or configuring.

Bulk HTML Validation

/1 Comment/in , , /by

I’ve recently been working on a WordPress project in which I made the mistake of starting with a commercial theme that, while beautiful and feature-rich, was a complete mess in terms of code quality. HTML validation is always a requirement on my projects, but a poorly-written WordPress theme combined with WordPress’ own tendency to butcher code by inserting poorly nested <p>’s (more on that later) can make validation a real chore.

The W3C’s Validator is a great tool and the Web Developer Toolbar‘s quick access to it makes the process go even faster.  But with nearly 100 static pages to validate in addition to several hundred imported blog posts written by nontechnical authors, I needed something better.

Enter the Web Design Group’s HTML Validator. This validator isn’t that different from the W3C validator, but it provides an additional key feature: the “validate entire site” option.  By checking this box the validator will spider the URL you provide and validate the first 100 pages that it finds within the same domain.

Moving Posts Between Categories in WordPress

/in , , /by

At some point or another, you may want to adjust the structure of categories in your WordPress blog.  I just ran into such a situation when a client who was previously managing two blogs (one for “News” and one for industry “Ramblings”) wanted to merge their two blogs into a single blog.  Using WordPress and a little bit of SQL, I’m going to teach you how to move posts in bulk to a new category. This tutorial assumes that you are using the default “wp_” table prefix, so make adjustments as neccessary; and as always, create a backup of your database before trying any of the steps below.

Step 1: Create the New Category

This step is easy.  Simply create the new category as you normally would from within WordPress.  After the category has been created, issue the following SQL against your WordPress database to determine the ID of the new category:

SELECT * FROM WP_Terms WHERE category_name = "New Category";

For me, this command told me that the id of my new category was 46, so I’ll remember that and continue to the next step.

Step 2: Find the ID of the Old Category

Now we need to do the same thing, but for the old category.  In my case I am moving all Uncategorized posts to the category I just created, so I need to find the unique ID of the “Uncategorized” category:

SELECT * FROM WP_TERMS WHERE CATEGORY_NAME = "Uncategorized";

This command tells me that “Uncategorized” has a unique id of “1”, so I’ll remember this value and continue.

Step 3: Update the Post/Category Relationship

In this step we’re finally modifying our database, so make sure you have a backup of your WordPress database before you continue.  We’re now going to update the relationship between the posts and the category.  The WP_TERM_RELATIONSHIPS table contains a list of post-to-category relationships.  The OBJECT_ID field specifies the unique id of the posts, the TERM_TAXONOMY_ID field specifies the unique ID of the category. So what we need to do is update any record with TERM_TAXONOMY_ID equal to the value from Step 2 to the ID of the table we created in Step 1:

UPDATE WP_TERM_RELATIONSHIPS SET TERM_TAXONOMY_ID = 46 WHERE TERM_TAXONOMY_ID = 1;

And voila! Your posts will now be treated as members of the new category.

Resetting Your WordPress Password

/in , , , /by

Bloggers: have you ever forgotten the password for one of your WordPress blogs?  Or attempted to take over or maintain a blog setup by someone else who doesn’t know the admin password?  This is your lucky day!

Assuming you have access to the database containing the WordPress blog’s data, resetting the password is easy. Assuming that the blog is using the default “wp_” table prefix, the user account is named “admin,” and the new password is being reset to “password”:

UPDATE wp_users SET user_pass = MD5("password") WHERE user_login = "admin";

For more information about resetting a lost WordPress password, see the official page on the subject at the WordPress Codex.

Creating a Child Theme in WordPress

/in /by

A couple of days ago I updated Lightword, the theme that I’ve been using on this blog for quite a while now. Unfortunately when I did the update I lost all of my customizations, including my logo and Adsense code.  So I went looking for a solution.

Little did I know, WordPress has supported a feature called “child themes” for some time now.  The idea is that you create a new theme, which is as simple as creating a new directory with a single CSS file called style.css, and add a comment to the new CSS file specifying the name of the parent theme.  You can read all about how to create a child theme here.

PHP On Windows 7

/2 Comments/in , , /by

Last week I decided to take the plunge and install the release candidate of Windows 7 on my office workstation where I happen to do a lot of web development and testing.  My development stack consists of Netbeans IDE, PHP 5.2.8, and IIS 7.  There are plenty of other quality tutorials out there explaining how to get PHP working on IIS 7 so I won’t bother beating that particular dead horse.  However there was one quirky difference between installing PHP on Vista and installing PHP on IIS 7 that developers may want to be aware of before they follow my lead.

The Problem : Editing php.ini as a Standard User

During the process of installing PHP on Windows 7 you will be required to copy php.ini into the C:\Windows directory, and  later point you’ll most likely need to edit this file to suit your needs.

On Windows Vista I simply wasn’t allowed to edit files under the \Windows directory (specifically php.ini) when logged in as a Standard User. Windows 7 was more than happy to allow me to modify and save this file in the same location, logged in with the same credentials. But even after restarting IIS my configuration changes never took effect.

The problem was caused by something called the Virtual Store, an application compatibility feature that existed in Windows Vista but works a little bit differently in Windows 7.  Where Vista wouldn’t let me edit this file at all, Windows 7 happily lets me modify it but transparently saves the changes in a different location. The updated php.ini was stored in %UserProfile%\AppData\Local\VirtualStore\Windows\php.ini.  The service account which IIS runs under can’t see this updated file

The Solution: Run As Administrator

When editing php.ini, don’t simply double-click it and make changes.  You must run your text editor as an administrator to edit the file, otherwise the changes will be saved to the Virtual Store.