During my previous rendezvous involving comprehensive canonicalization for WordPress, I offer my personally customized technique for ensuring consistently precise and accurate URL delivery. That particular method targets WordPress exclusively (although the logic could be manipulated for general use), and requires a bit of editing to adapt the code to each particular configuration. In this follow-up tutorial, I present a basic www-canonicalization technique that accomplishes the following:

• requires or removes the www prefix for all URLs
• absolutely no editing when requiring the www prefix
• minimal amount of editing when removing the www prefix
• minimal amount of code used to execute either technique

I have found this “universal” www-canonicalization technique extremely useful in its simplicity and elegance. Especially when requiring the www prefix, nothing could be easier: simply copy, paste, done — absolutely no hard-coding necessary!

Continue Reading

For future reference, this article covers each of the many ways to access your WordPress-generated feeds. Several different URL formats are available for the various types of WordPress feeds — posts, comments, and categories — for both permalink and default URL structures. For each example, replace “http://domain.tld/” with the URL of your blog. Note: even though your blog’s main feed is accessible through many different URLs, there are clear benefits to using a single, consistent feed URL throughout your site.

Continue Reading

How to streamline and maximize the effectiveness of your WordPress URLs by using htaccess to remove extraneous post-date information: years, months, and days..

Recently, there has been much discussion about whether or not to remove the post-date information from WordPress permalinks ¹. Way back during the WordPress 1.2/1.5 days, URL post-date inclusion had become very popular, in part due to reports of potential conflicts with post-name-only permalinks. Throw in the inevitable “monkey-see, monkey-do” mentality typical of many bloggers, and suddenly an entire wave of WordPressers had adopted the following permalink structure:

/%year%/%monthnum%/%day%/%postname%/

The benefits of using this format are primarily organizational in nature. Post-date information that is “built-in” to every URL provides immediate, “at-a-glance” knowledge of post “freshness”. Looking ahead ten, twenty or even a hundred years into the future of the blogosphere, there will be trillions of posts and articles, each with their own unique URL. Archived copies of content may or may not include creation date: dynamically archived pages require deliberate database queries, while those archived statically may no longer have access to post-date data. Including post dates in permalinks provides permanent, facilitative record of content origination. Needless to say, most adopters of dated permalinks probably jump on board because the WordPress Admin makes it super-easy to follow the crowd.

Continue Reading

Permalink URL canonicalization is automated via PHP in WordPress 2.3+, however, for those of us running sites on pre-2.3 versions or preferring to deal with rewrites directly via Apache, comprehensive WordPress URL canonicalization via htaccess may seem impossible. While there are several common methods that are partially effective, there has not yet been available a complete, user-friendly solution designed specifically for WordPress. Until now..

In this article, I share my “secret” htaccess URL canonicalization formula. I originally developed this method in July of 2007, and have been using it successfully on a variety of WordPress-powered sites since that time. Thus, having verified the effective performance of this technique, I feel confident in sharing it with the open-source community. But first, a bit of context..

Continue Reading

While planning my current site renovation project, I considered changing the format of my permalinks. Reasons for modifying the permalink structure of a site include:

• Optimizing URLs for the search engines
• Simplifying URL structure for improved readability
• Removing the implication that your site content is somehow organized chronologically
• Removing other unwanted organizational implications (e.g., categorically, topically, etc.)

Like many people who configured WordPress permalinks a couple of years ago, I chose to include the day, month, and year along with the blog URL and post title. For over two years now, Perishable Press has employed the following permalink format:

Continue Reading

WordPress users employing permalinks via htaccess to optimize their dynamic URLs transform complicated-looking links such as:

http://example.com/blog/index.php?page=33

..into search-engine friendly links such as:

http://example.com/blog/post-title/

Every rewritten URL relies on a common set of htaccess rules to transform the links. The htaccess rules for all WordPress permalinks look like this for root WP installations:

# BEGIN WordPress
<ifmodule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</ifmodule>
# END WordPress

..and like this for subdirectory WP installations:

Continue Reading

I recently performed a series of tests on a fresh installation of WordPress 2.8.6 to determine the exact htaccess rewrite rules that WordPress writes to its htaccess file for various permalink configurations. Under the WP admin option menu, WordPress lists four choices for permalink structure:

1. Default: http://perishablepress.com/press/?=123
2. Date and name based: http://perishablepress.com/press/index.php/2006/06/14/sample-post/
3. Numeric: http://perishablepress.com/press/index.php/archives/123
4. Custom: /%year%/%monthnum%/%day%/%postname%/

The "default" option is to not use permalinks. The "date and name based" setting invokes the /index.php/%year%/%monthnum%/%day%/%postname%/ rule pattern. The "numeric" setting invokes the /index.php/archives/%post_id% rule pattern. And the "custom" setting invokes whatever pattern is specifically chosen. For our "custom" option, we chose the /%category%/%author%/%postname%/ pattern.

For the test, we began with the common "date and name based" permalink configuration. Then, after invoking the chosen permalink structure, the htaccess file was downloaded and the new WP rules were recorded. After this, the admin permalink settings were switched back to the "default" configuration. Finally, we deleted the new rules and uploaded the htaccess file. This process was diligently repeated for each different permalink configuration. It should also be noted that blog performance was checked during each round of testing.

The results indicate conclusively that WordPress uses the exact same set of htaccess rules for all permalink configurations. Surely this information is available elsewhere on the internet, however we were experiencing several inconsistencies related to permalink structure that inspired us to determine for ourselves the precise htaccess rules for WordPress permalinks.

Without further ado, the htaccess rules for all WordPress permalinks¹ are precisely either #1 or #2:

[ #1 ] If WordPress installed in the root directory »

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

[ #2 ] If WordPress installed in a subdirectory called "foo" »

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /foo/
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /foo/index.php [L]
</IfModule>
# END WordPress

¹ Note: These results are valid for standard permalink structures invoked via a standard WordPress install and may not operate effectively for non-standard or highly specialized configurations. We assume that if you are hard at work hacking and tweaking, you must know what you are doing.

If you are running WordPress 2.0.2 and have enabled permalinks, you may have had problems creating a new category or page to your site. I recently encountered this dilemma and devised the following strategy for adding, editing, or even deleting WordPress categories and pages. Note: this tutorial assumes you are running Apache.

First, open wp-includes/vars.php and find (around line #39):

$is_apache = ( strstr($_SERVER['SERVER_SOFTWARE'], 'Apache') || strstr($_SERVER['SERVER_SOFTWARE'], 'LiteSpeed') ) ? 1 : 0;

Comment out that line and add the following:

$is_apache = 1;

Save the file and upload it to your server.

Next, check the file attributes of your htaccess file(s). Ensure that the file is writable with a setting of either 666 or even 777 (or whatever works best on your server).

Finally, create or edit the necessary category or categories, publish a post or two under the new/edited category, and then double-check that everything is working as expected.

Now that you are a big winner with your new category, be sure to change the htaccess file permissions back to 644 or equivalent. Also, comment out the new line in the vars.php file and uncomment out (i.e., comment in) the original line of code.

I recently enabled the permalinks feature for a fresh WordPress 2.0.2 upgrade. The process required several hours of research and approximately 90 minutes to fully implement. This brief article summarizes the process and applies to at least the following setup:

1. WordPress 2.0.2
2. Apache Server with mod_rewrite enabled
3. The ability to access/modify your .htaccess file(s)
4. You have decided to use the /%year%/%monthnum%/%day%/%postname%/ permalink format (actually, any format will work; simply swap your preferred format for the one mentioned here)
5. You may also be using any of the plugins listed in the dungeon (actually, most plugins are compatible — only a few cause problems)

Permalinks are important for several reasons: search engines love them, people can understand them, and links (theoretically) become permanent because of them. Plus, all of the cool kids are using them, so you should too. They really add the finishing touches to your site and provide a sense of unity and sophistication that the “http://ugly-domain.com/blog/index.php?page_id=66” format just can’t match.

Before you begin any changes it is highly recommended to backup everything: WordPress files, database(s), notes, edited files, image files, htaccess file(s), etcetera. Just a friendly reminder.

Then, if you are seriously considering jumping into permalinks, do some research. Search Google, Ask, WordPress, and dig through a few blogs for terms such as “WordPress permalinks”, “permalink tips”, “permalink guide”, etc. As you learn, copy and paste any important notes, code, or links that seem important and may be useful later on. You may also wish to anticipate certain scenarios by searching for “permalink nightmare” or “permalink success”, for example.

Now that you have studied the process, you realize that certain conditions produce errors or other problems. For example, if you are planning on using the %postname% in your permalinks, very long post titles may cause problems in emails, posts, and chats. Although such an issue may be fixed after the fact, it is wise to scan through your posts and edit the post slug of any posts with excessively long titles. Regardless of the post title name, it is the post slug that is used when implementing the %postname% in permalinks. If possible, I recommend manually checking every post title and slug and editing (if needed) with permalinks %postname% in mind. Don’t forget to check your pages as well.

Now for the fun stuff. Well, almost. WordPress 2.0.2 has a problem writing to .htaccess files even when their CHMOD is set to 666 or 777. To fix this, open wp-includes/vars.php and replace the following line of code:

$is_apache = ( strstr($_SERVER['SERVER_SOFTWARE'], 'Apache') || strstr($_SERVER['SERVER_SOFTWARE'], 'LiteSpeed') ) ? 1 : 0;

..with this one:

$is_apache = 1;

This is a change that should be needed only during the establishment of permalinks. After you have permalinks flying high, you should revert the previous replacement and restore order to the galaxy.

Now create your htaccess file(s). Open a text editor and save a blank document as “htaccess” in the root of your site. Then rename it to “.htaccess” (i.e., put a dot before the name). Upload this file and change its CHMOD setting to 666. Again, this change should only endure until permalinks are functioning. So remember to change it back to its default setting (typically 644).

Okay, get ready to party. First restart your computer (for good measure). Then, open your WordPress Admin and navigate to the Permalinks submenu (under Options). Read everything carefully and then select the “Date and name based” option under the “Common options” menu. Make sure that WordPress automatically added /%year%/%monthnum%/%day%/%postname%/ (or that of your preferred format) to the “Custom structure” field. Now click the “Update Permalink Structure” button and wait for the “success” message to appear. At this point, permalinks should work throughout your WordPress-powered website.

Almost done. Check everything. First download your htaccess file and check that WordPress automatically added the htaccess directives required to create permalinks:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /press/
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /press/index.php [L]
</IfModule>
# END WordPress

If you don’t see it, then copy and paste it into your htaccess file manually. If your htaccess file is blank, permalinks will not work. Once your htaccess file is good to go, clear your browser cache and surf your entire site — pages, posts — everything. Check internal links and external links. If possible, check links pointing to your site from elsewhere online. Every page or post should now be addressed by its corresponding and unique permalink, as displayed in your browser’s address field. If all is looking smooth, great. Remember to check the functionality of everything: commenting, posting, tagging, and editing posts. Also check your calendar, archives, search function, different themes, and plugin features (if any).

One problem I encountered (besides those inherently addressed in this article) involved an unwanted index.php statement included before the date in all permalinks. To fix this, you must access the wp_options table in your WordPress database. Once there, find the index field called option_name and search for the record rewrite_rules and clear the contents of the option_value. This will force WordPress to generate new permalink values based on current user settings. Read more via this thread at the WordPress Support Forums.

Don’t forget to reverse any changes made during the permalink conversion process.

References & Resources

• The htaccess Rules for all WordPress Permalinks
• WordPress Permalinks
• Enforce www-Preference
• WP 2.0 Plugin Compatibility
• A mod_rewrite Tutorial