I wanted each page to communicate its true purpose. That meant replacing the site name from the H1 heading element, and replacing it with the actual page or blog entry title. It doesn’t mean I got rid of the site name altogether on sub-pages. Instead, I relegated it to the top of the sidebar.

The HTML is maximumly optimized. The sidebar and navigation is now secondary to the content. Semantic elements, like header, footer, section, nav, and article, are also more properly implemented.

There are still key elements from the first version of the Modest WordPress theme that I kept. For example, the general layout is still the same, and the attention to forcing a minimal list of categories and pages remains (thanks to the fixed position used in the CSS).

The CSS is greatly reduced, and as always, I gave some attention to the print stylesheet.

Yahoo!, Not Minimalist

Bing, Not Minimalist

Ask.com, Not Minimalist

Google, Minimalist

I finally found the solution for enabling GZIP compression on Pair. All I had to do was add one simple line of PHP code to the top of my header.php file in my WordPress theme.

<?php ob_start("ob_gzhandler"); ?>

After you add the code, use the HTTP Compression Test to make sure the GZIP compression is working. If you want more tips on how to speed up your site, check out my article on how to speed up your site for Google.

Enable "Upgrade Automatically" in WordPress on Pair Networks

If you use the (best) Web hosting provider Pair, and you run WordPress, then you have undoubtedly found out that you can’t upgrade automatically new versions of WordPress or updates for your plugins. The reason for that is because by default, the System CGI: php-cgiwrap is not configured. Fortunately, it’s not too difficult to enable.

Enabling Automatic Upgrades on WordPress

To use PHP 5 with php-cgiwrap, you must first copy php5.cgi to your own Web directory’s (public_html) cgi-bin directory by SSH.

Step 1

Create the cgi-bin folder in your public_html folder, if it doesn’t exist already.

Step 2

Copy and paste in your terminal connection:
cp /usr/www/cgi-bin/php5.cgi ~/public_html/cgi-bin/

Step 3

Copy and paste in your terminal connection:
chmod 755 ~/public_html/cgi-bin/php5.cgi

Step 4

Add the following lines to your WordPress .htaccess file. Make sure you change [username] with your actual Pair account username (remove the brackets.)

Action application/x-pair-sphp5 /cgi-sys/php-cgiwrap/[username]/php5.cgi/
AddType application/x-pair-sphp5 .php

That’s it. Assuming you did it correctly, you’ll now be able to automatically upgrade WordPress and your plugins. If you need more details or help with this process, view Pair’s Knowledge Base article, “Authoring/Development – System CGI: php-cgiwrap.”

• /%category%/%postname%
• /%postname%
• /category/%postname%-%post_id%
• /%postname%-%post_id%

All of those options work well, but I actually prefer to do mine as /%post_id%/%postname%/. At first glance, that choice may seem less than ideal. For example, why would I want to exclude my category name, and what purpose does it serve having the post ID in the URL?

Category Name

While having the category name in the URL is not a bad idea, I don’t think it’s necessary. Google can easily understand that a blog entry is related to a particular category by simply mapping the linking structure. It will also be reinforced by the page title and internal link structure on the entry.

It’s also not desirable, because an entry can have multiple categories, and it can take up a lot of space in the SERPs. I prefer to show the the title of the blog entry, instead of the category name. In fact, showing the category name before a long title may cut off the title in the SERPs.

Not including the category in the URL of the entry also allows you to rename the category at a later time without having too much of a negative impact. I would much prefer to rename a category list page (which most people will not link to) than to change the URL of a post. If I’m really concerned about losing a list page, then I can go out of my way and set up a simple redirect in my .htaccess file.

Post ID

Most people consider displaying the post ID mainly because they’re concerned they might write a blog entry one day that uses the same title, causing an issue with resolving to the correct destination content. While that certainly factors into my decision to use a post ID before the post name, it’s not my main reason. I like using the post ID, because it handles changes to the blog entry gracefully.

If you change the page title and the permalink of a blog entry – like /id/original-blog-title to /id/new-blog-title – the old link will still resolve (correctly redirect to the new permalink.) That’s because WordPress reverts to the post ID when something goes wrong. In fact, you can go to just the post id (like the one for this entry: http://henshaw.me/423/) and it will bring up the correct blog entry. It won’t bring up the full permalink, but there’s no need to worry about duplicate content, that is, as long as you’re specifying the canonical URL in the HEAD area.