Codex tools: Log in / create account
Contents |
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:
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.
These are the holy grail of permalinks (see Pretty Permalinks). There are many different formats, but the most common, and most versatile looks like
http://example.com/category/post-name/ or http://example.com/year/month/day/post-name
Some people eliminate some or all of the date elements (day, month, year) to have a shorter permalink format. mod_rewrite permalinks require Apache's mod_rewrite module.
For lighttpd, see External sources.
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_rewrite permalinks can do, PATHINFO permalinks can do, with the help of that /index.php part.
There is a helpful plugin that displays the type of permalinks being used and detailed information on the internal rewrite rules used by WordPress.
In the Options → Permalinks panel, you can choose one of the "common" structures or enter your own in the "Custom structure" field using the structure tags.
To activate PATHINFO permalinks, start your permalink structure with index.php/.
You can use these tags to customize your "Pretty" or "Almost Pretty" permalinks. 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.
The Category base is a prefix used in category permalinks, which always take the form
category_base/category_name
The default category base is category.
Custom permalinks work on most systems without any problems, but there are still some conditions where problems occur.
If you use postname as the only element in your permalinks to create a structure such as example.com/post-title, the rewrite rules may make it impossible to access pages such as your stylesheet (which has a similar format) or the /wp-admin/ folder [is this true in WordPress 2.0+ versions?]. It's best to include some numeric data (e.g. the post ID or date) in the permalink to prevent this from happening. Additionally, WordPress v1.2.x requires the use of a date structure in order for some features, such as the calendar, to function properly. /%year%/%monthnum%/%day%/%postname%/ is always a good start.
When you assign multiple categories to a post, only one can show up in the permalink. This will be the lowest numbered category (see Manage Categories). The post will still be accessible through all the categories as normal.
Requirements:
AllowOverride FileInfo, AllowOverride All)
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).
In WordPress 2.0+ versions, you'll probably need to do this only once, because WordPress does the rewriting internally. If you ever move your WordPress home directory (Blog 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.
Wordpress's index.php and .htaccess files should be together in the directory indicated by the Blog address (URI) 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.
If you do not already have a .htaccess file, create one. If you have shell or ssh access to the server, a simple touch .htaccess command 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.
If your .htaccess file contains errors that bring down your site ("Internal Server Error (500)"), you will need to use FTP or your host's control panel to delete the rogue .htaccess file.
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 Options → Permalinks panel.
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.
"Pretty" permalinks require mod_rewrite, and IIS (common on Windows servers) does not support mod_rewrite. (If you are using Apache 2.0.54, on Windows, mod_rewrite may work, provided it is enabled in apache\conf\httpd.conf.) But you can try PATHINFO permalinks; put index.php/ at the start of your custom permalink structure:
/index.php/%year%/%monthnum%/%day%/%postname%/
This option may not always work, especially in cases of WordPress running on IIS 6. To make this option work on IIS, add these 2 lines to a php.ini file and store that file in your webroot (http://blog.taragana.com/index.php/archive/wordpress-tip-on-permalink-options):
cgi.fix_pathinfo = 1 cgi.force_redirect = 0
Another solution exists using IIS' custom 404 redirects. It requires that your web host allows you to add a custom 404 redirect, but it doesn't require you to install any 3rd party mod_rewrite software and it also doesn't require that your permalink structure begin with /index.php/.
If you have administrator privileges on your server, you may be interested in these solutions:
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.
$is_apache = strstr($_SERVER['SERVER_SOFTWARE'], 'Apache') ? 1 : 0;and replace it with
// $is_apache = strstr($_SERVER['SERVER_SOFTWARE'], 'Apache') ? 1 : 0;
// $is_apache = strstr($_SERVER['SERVER_SOFTWARE'], 'Apache') ? 1 : 0;and type in
$is_apache = 1;
A note about Microsoft Frontpage: many servers (shared and dedicated) maintained and built by various hosting companies come with mod_frontpage compiled with the apache build, and in many cases with the Frontpage Server Extensions installed, on each virtual server. This is more common than not, many/most binary distributions used in the server build process at most hosting companies these days include both mod_fronpage and the server extensions. Even if you're not using Frontpage, because of the way that the extensions interact with apache (and the httpd.conf file) you'll likely get something like a 500 error or blank white page when trying to view your WP install (although the admin panel may operate correctly) simply because extensions/mod_frontpage exist on your server.
Wordpress will operate correctly with the Frontpage Extensions installed, however permalinks will not function at all and ANY change to the permalinks section from the Wordpress admin interface will cause corruption of the Frontpage server extensions due to the addition of the mod_rewrite rules to the .htaccess file. There is however now a fix for this situation.
Frontpage Extensions Fix: If you don't care about permalinks and just want to make the MS Frontpage server extensions work again, simply edit your .htaccess file and remove the WordPress section with the rewrite rules.
To Use Permalinks: If you don't care about Frontpage(but your hosting company has the extensions installed)
You will need to remove (or have your hosting company do so) the MS Frontpage server extensions, or simply edit the .htaccess file to removed all of the Frontpage Lines, leaving only the WordPress mod_rewrite code.
Finally, A solution.
There have been a number of threads on this issue in the support forums, and until now, no solution to the problem.
Normally, on a Unix server with the Microsoft FrontPage Server extensions installed WordPress works just fine and you are able to edit and publish pages (with Microsoft FrontPage) — until — you make a change to the permalinks (for example to the date based kind that I like /2005/04/etc). I often suggest that type of URI to folks asking about permalinks etc, as that is the method recommended by the w3c (see http://www.w3.org/Provider/Style/URI ).
Now, the problem is that FrontPage uses the .htaccess file (which the WordPress mod_rewrite rules must access) for its "publishing" and "web authoring" configuration. As soon as the WordPress mod_rewrite code is added to the file, two things happen — the permalinks don't work and the Frontpage Server extensions become corrupt.
I have tried countless ways to get around this, including trying to use rewrite rules that "ignore" the %{HTTP_USERAGENT)% used by FrontPage, to using a second AccessFilename .wpaccess to the httpd.conf file, and a host of other things, and nothing worked to allow use of FrontPage and management and use of permalinks in WordPress at the same time.
The solution is actually simple, and I figured it out by accident.
If you are using, or wish to use FrontPage (or if your hosting package is pre-configured that way) along with WordPress, you'll need to take the following simple steps on your server or have your hosting company do them for you.
Microsoft FrontPage creates the following directory
_vti_binNested within that it creates both
_vti_admand
_vti_aut
In addition to in your site (or WordPress) root folder in all of those directories you will find additional .htaccess files.
In all three of these directories AND in the root directory, at the top of ALL of the .htaccess files you simply need to add one line:
Options +FollowSymlinks
There may or may not already be a line in each like
Options None
Edit and save each .htaccess file and you're done. Now everything works perfectly, including FrontPage, AND the permalinks of your choosing.
When using extra long permalinks in email and posting in comments and chats, some long permalinks are "chopped off" or only the first section is actually recognized as a link and the end seen as text. Here is an example.
Can result in:
To click on the lower link, the user would get a 404 Page Not Found Error. If you have a tendency to use very long permalink post titles, take these steps to prevent this problem.
1. Check that you are indeed using Permalinks.
2. Edit your .htaccess file and add the following:
RewriteRule ^post/([0-9]+)?/?([0-9]+)?/?$ /index.php?p=$1&page=$2 [QSA]
3. Test it. Find a post's ID number and type the following (with your information) in your browser and you should be redirected to your post:
http://yourdomain.example.com/post/(the ID #)
It is also worth noting that most email software will not cut off URLs that have been delineated with angle-brackets (< and >), so when pasting URLs into emails, you should write them as so:
Additionally, some decent email clients offer a "preformat" option when composing plain-text emails. Using the "preformat" option when pasting links will force the email client not to insert linebreaks inside the links.
If your .htaccess file is being generated correctly, but Permalinks still do not function, the following might be a problem. If problems persist, post a note in the WordPress Forum's How To section.
<Directory />
Options FollowSymLinks
AllowOverride All
</Directory>
You may also have to enable the AllowOverride directive in your DocumentRoot:
<Directory /var/www/html>
# ... other directives...
AllowOverride All
</Directory>
http://www.example.com/page/2/ http://www.example.name/category/categoryname/page/2/ http://www.example/year/month/day/page/2/ http://www.example/year/month/page/2/
If these steps do not work, search for your problem in the Codex, Troubleshooting, or in the Support Forum. As a last resort, file a bug report.
There's an easy way to having your posts end in a .html extension, using the structure tags above. Following the example used on properly terminating permalinks, you could have a page like http://yoursite.com/2006/01/01/happy-newyear.html with this rule:
/%year%/%monthnum%/%day%/%postname%.html
Note that this does not generate static .html files. It only adds the .html extension, pages are still being dynamically generated. The SEO benefit to this is debatable, but it can be useful should you need to migrate away from WordPress, since the pages can easily be made static and retain their URL structure.
WordPress versions prior to 2.3 lacked canonical URLs, making .html something very beneficial to add (forcing the URL to be canonical). Now it only provides limited, if any SEO benefits (see External Resources for further analysis).