Using Permalinks

Permalinks are the permanent URLs to your individual weblog posts, as well as categories and other lists of weblog postings. A permalink is what another weblogger will use to link to your article (or section), or how you might send a link to your story in an e-mail message. The URL to each post should be permanent, and never change — hence permalink.

There are three basic types of WordPress permalinks:

Default: “Ugly” Default: “Ugly”

The default looks like

http://example.com/?p=N

where N is the Post ID number. It works on all server environments, but it doesn’t look as nice as some of the other options.

Top ↑

Using mod_rewrite or lighttpd you can produce much nicer permalinks (see Pretty Permalinks). There are many different formats, but the most common, and most versatile looks like

http://example.com/2012/post-name/

or

http://example.com/2012/12/30/post-name

Pretty permalinks are available under:

Top ↑

PATHINFO: “Almost Pretty” PATHINFO: “Almost Pretty”

PATHINFO permalinks look very much like mod_rewrite permalinks but for one exception: they have /index.php inserted before them, like so:

http://example.com/index.php/yyyy/mm/dd/post-name/

Otherwise, they are the same as the “pretty” mod_rewrite permalinks, and are similarly flexible. Anything that mod_rewritepermalinks can do, PATHINFO permalinks can do, with the help of that /index.php part.

Top ↑

In the Settings → Permalinks Screen, you can choose one of the more common permalink structures or enter your own in the “Custom structure” field using the structure tags.

Please note: You do not put your site url in the permalinks fields. You only use one of the structure tags, or a combination of tags.

To activate PATHINFO permalinks, start your permalink structure with index.php/.

Top ↑

Structure Tags Structure Tags

You can use these tags to customize your “Pretty” or “Almost Pretty” permalinks. A few hints:

  • You do not put your site url in the permalinks fields. You only use one of the structure tags, or a combination of tags.
  • Make sure to end your structure with either %post_id% or %postname% (e.g. /%year%/%monthnum%/%day%/%postname%/) so that each permalink points to an individual post.
 %year%
The year of the post, four digits, for example 2018
 %monthnum%
Month of the year, for example 05
 %day%
Day of the month, for example 28
 %hour%
Hour of the day, for example 15
 %minute%
Minute of the hour, for example 43
 %second%
Second of the minute, for example 33
 %post_id%
The unique ID # of the post, for example 423
 %postname%
A sanitized version of the title of the post (post slug field on Edit Post/Page panel). So “This Is A Great Post!” becomes this-is-a-great-post in the URI.
 %category%
A sanitized version of the category name (category slug field on New/Edit Category panel). Nested sub-categories appear as nested directories in the URI.
 %author%
A sanitized version of the author name.

Top ↑

Category base and Tag base Category base and Tag base

The Category base and Tag base are prefixes used in URLs for category and tag archives, which look like this:

 example.net/wp/category_base/category_name
 example.net/wp/tag_base/tag_name

The default values for these are category and tag. You can change them, but you can’t remove them from the URLs altogether.

Custom permalinks work on most systems without any problems, but there are still some conditions where problems occur.

Top ↑

Using %category% with multiple categories on a post Using %category% with multiple categories on a post

When you assign multiple categories to a post, only one can show up in the permalink. The categories are ordered alphabetically. In each group of sub-categories the order will also be alphabetical. (see Manage Categories). The post will still be accessible through all the categories as normal.

Try the WP Category Permalink plugin if you want to choose which category shows up in the permalink.

Top ↑

Requirements:

  • Apache web server with the mod_rewrite module installed
  • In WordPress’s home directory,
    • The FollowSymLinks option enabled
    • FileInfo directives allowed (e.g. AllowOverride FileInfo or AllowOverride All)
    • An .htaccess file (if this file is missing, WordPress will try to create it when you activate “pretty” permalinks)
    • If you want WordPress to update the .htaccess file automatically, WordPress will need write access to the file.
  • For nginx, a web server aimed at high concurrency, high performance and low memory usage, add the following location block within the server block:
location / {
            try_files $uri $uri/ /index.php?$args; 
}
  • For Hiawatha, a web server with a strong focus on security, use the following UrlToolkit rule:
UrlToolkit {
    ToolkitID = wordpress
    RequestURI exists Return
    Match .*\?(.*) Rewrite /index.php?$1
    Match .* Rewrite /index.php
}
  • Mac Users running WordPress locally must edit their httpd.conf file editing the AllowOverride line to read AllowOverride All in theDirectory “/Library/WebServer/Documents” host instructions. For Mac OS X 10.5.x and up this file is located in/private/etc/apache2/users/[your-username].conf, otherwise it is located at /etc/httpd/httpd.conf.

When you create or update a “pretty” permalink structure, WordPress will generate rewrite rules and attempt to insert them into the proper .htaccess file. If it can’t, it will say something like You should update your .htaccess now and print out the rules for you to copy and paste into the file (put them at the end).

You’ll probably need to do this only once, because WordPress does the rewriting internally. If you ever move your WordPress home directory (Site address), you’ll need to repeat this step.

WordPress will play nice with an existing .htaccess and will not delete any existing RewriteRules or other directives. If you have other mod_rewrite rules, put yours before WordPress’s.

Top ↑

Where’s my .htaccess file? Where’s my .htaccess file?

WordPress’s index.php and .htaccess files should be together in the directory indicated by the Site address (URL) setting on your General Options page. Since the name of the file begins with a dot, the file may not be visible through an FTP client unless you change the preferences of the FTP tool to show all files, including the hidden files. Some hosts (e.g. Godaddy) may not show or allow you to edit .htaccess if you install WordPress through the Godaddy Hosting Connection installation.

Top ↑

Creating and editing .htaccess Creating and editing .htaccess

If you do not already have a .htaccess file, create one. If you have shell or ssh access to the server, a simple touch .htaccesscommand will create the file. If you are using FTP to transfer files, create a file on your local computer, call it 1.htaccess, upload it to the root of your WordPress folder, and then rename it to .htaccess.

You can edit the .htaccess file by FTP, shell, or (possibly) your host’s control panel.

The following permalink rewrite code should be included in your .htaccess file:

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

If your .htaccess file contains errors that bring down your site (“Internal Server Error (500)”), you will need to use FTP or your host’scontrol panel to delete the rogue .htaccess file.

Top ↑

Automatically updating .htaccess Automatically updating .htaccess

If WordPress can’t update your .htaccess file automatically, it will tell you something like If your .htaccess file were writable, we could do this automatically, but it isn’t… near the bottom of the Settings → Permalinks Screen.

If you want to let WordPress do this, you’ll need to give WordPress write access to the .htaccess file. The exact permissions necessary depend on your server setup. Try adding write permissions for the owner, then group, then world, testing after each change; once WordPress has edited the file successfully, don’t add any further write permissions.

After applying the permalinks, you should change the permissions to something stronger like 660 or 644 to prevent others on the server from potentially having access to it.

Top ↑

Top ↑

Fixing .htaccess Generation Issues Fixing .htaccess Generation Issues

If your installation of WordPress does not generate a .htaccess file or if it does not write the new rules onto your existing .htaccess file then there are a couple reasons that could be causing this. Work step by step and continue to the next step only if the previous step does not work.

  1. Change File Permissions: You must chmod the .htaccess file to 666 to edit it with the WordPress template editor, but this is not recommended, since if you do that, any user of your blog, who can edit templates will be able to edit it. You can change the permissions to 660 to make it server-writable, which again will have the same limitation.
  2. Server Blockage: Your host might have blocked the SERVER_SOFTWARE variable and this will cause WordPress’ .htaccess generation to fail. If you are sure that your server is running Apache, you can force WordPress to believe that your server is running Apache by changing your wp-includes/vars.php file. Follow the steps below to implement these changes.
    • Open the wp-includes/vars.php file using the built in file editor in your WordPress Admin panel. To navigate to this panel, login to WordPress, click on “Manage”, then on “Files”, scroll to the bottom and type in wp-includes/vars.php into the text box under the “Other Files” title. Look for
      $is_apache = strstr($_SERVER['SERVER_SOFTWARE'], 'Apache') ? 1 : 0;

      and replace it with

      // $is_apache = strstr($_SERVER['SERVER_SOFTWARE'], 'Apache') ? 1 : 0;
    • Add a new line under
      // $is_apache = strstr($_SERVER['SERVER_SOFTWARE'], 'Apache') ? 1 : 0;

      and type in

      $is_apache = 1;
  3. Users of XAMPP (Windows): Some versions of XAMPP do not enable mod_rewrite by default (though it is compiled in Apache). To enable it — and thus enable WordPress to write the .htaccess file needed to create pretty permalinks — you must open apache/conf/httpd.conf and uncomment the line LoadModule rewrite_module modules/mod_rewrite.so(i.e., delete the hash/pound sign at the front of the line).
  4. Users of WAMP (Windows): Some versions of WAMP (all versions?) do not enable mod_rewrite or permit following SymLinks by default. To enable the required functionality navigate to the apache/conf/httpd.conf file, open with a text editor and uncomment the line LoadModule rewrite_module modules/mod_rewrite.so (i.e., delete the hash/pound sign at the front of the line). Then further down in the same file there is a section that starts with the line "Options FollowSymlinks". Change the second line in that section from "AllowOverride none" to AllowOverride all. Save edited httpd.conf and restart all WAMP modules. Your permalinks should now work.

Top ↑

Tips and Tricks Tips and Tricks

Top ↑

Note that even though one might never make more than one posting a day, and thus wishes to use e.g., %year%%monthnum%%day%, links so generated will however be interpreted as the archive of all posts for that day. One needs at least %year%%monthnum%%day%%hour% to target an individual post.

Top ↑

A way to check if the blog has a permalink structure is:

<?php if ( get_option('permalink_structure') ) { echo 'permalinks enabled'; } ?>

Top ↑

See Also See Also