WordPress.org

Codex

User:Malaiac/fr:Utiliser Permaliens

Début de la traduction de la page Use_Permalinks

Remarque du traducteur : une bonne partie de l'info est devenue obsolète depuis WP1.5+. => Dois je tout traduire ?

Par ailleurs, j'ajoute des infos sur le référencement, les Permaliens jouant un role important dans ce domaine.

Les Permaliens sont les URL de vos billets individuels, ainsi que des catégories et des pages de votre blog. Les autres bloggers utilisent les permaliens de vos billets pour y faire référence, les lier, et vous pouvez aussi les utiliser pour les envoyer dans un e-mail. L'URL d'un billet ne doit pas changer une fois le billet publié, puisque sa modification rendrait le lien invalide. D'où le préfixe "perma" (-nent). Note du traducteur : l'URL Rewriting permet de contourner cette limitation par modification du fichier .htaccess.


Contents

Tags de structure

Vous pouvez utiliser ces tags pour personnaliser vos permaliens.

%year% 
L'année du billet, en quatres chiffres, par exemple 2004
%monthnum% 
Le numéro de mois du billet, par exemple 05
%day% 
Le jour du mois, par exemple : 28
%hour% 
L'heure de publication du billet, par exemple : 15
%minute% 
La minute de publication, par exemple : 43
%second% 
La seconde de publication, par exemple : 33
%postname% 
Une version simplifiée du titre du billet. Par exemple, “Voici mon premier billet !” devient “voici-mon-premier-billet” dans l'URL. (see note below)
%post_id% 
L'identifiant unique (ID) du billet, par exemple : 423
%category% 
Une version simplifiée du nom de la catégorie. Les sous-catégories apparaissent comme des sous-répertoires dans l'URL.
%author% 
Une version simplifiée du nom de l'auteur du billet.

Les Permaliens marchent sur la plupart des installations, cependant quelques problèmes peuvent survenir.

Mise en garde pour les bloggeurs qui voudraient utiliser %postname% seulement 
Si vous ne gardez que le titre du billet comme élément de Permalien, par exemple pour avoir monblog.fr/titre-du-billet, les règles de réécriture (gérées par WordPress) peuvent vous empêcher d'accéder directement à certains fichiers, comme votre feuille de style ou le répertoire wp-admin. Il est préférable d'utiliser une donnée numérique (par exemple l'ID du billet ou la date) dans le Permalien pour éviter ce problème.

De plus, pour WordPress v1.2.x, certaines fonctions - comme le calendrier, nécessitent l'utilisation d'un tag de date dans le Permalien pour fonctionner correctement. /%year%/%monthnum%/%day%/%postname%/ est une structure de permalien couramment utilisée.

Mise en garde pour l'utilisation de %category% 
%category% ne fonctionne pas correctement avec certaines implémentations du module mod_rewrite dans les version d'Apache antérieures à la version 2. Si vous ou votre hébergeur utilise Apache 1 et que vous avez des soucis avec l'utilisation de %category%, vous devez : ne pas utiliser ce tag, ou bien utiliser Schlueterica's plugin.
Mise en garde pour l'utilisation de %category% avec les billets à catégories multiples 
Quand vous publiez un billet dans plusieurs catégories, une seule peut apparaître dans le Permalien. WordPress choisit automatiquement la catégorie avec l'ID le plus bas (voir Manage Categories). Le billet sera cependant accessible dans toutes les catégories.
Utiliser des suffixes propres dans les permaliens. 
Il est important de s'assurer que les Permaliens référent à des billets individuels ... ?
It's important to guarantee permalinks lead to individual posts within your custom URI,

Assurez vous donc de terminer votre structure de liens avec, soit %post_id% soit %postname%

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

Où est mon fichier .htaccess ?

Le fichier .htaccess devrait être dans la racine de votre installation Wordpress, dans le même répertoire que les fichiers WordPress. Le nom du fichier commençant par un ".", le fichier peut ne PAS apparaître dans certains clients FTP. Vous pouvez changer les options de votre client FTP pour voir "tous les fichiers", y compris les fichiers cachés. Si vous n'avez pas de .htaccess, créez-le. Si vous avez un accès ssh ou un shell sur le serveur, un simple touch .htaccess suffira à créer le fichier. Si vous utilisez un client FTP, créez un fichier htaccess.txt sur votre répertoire local (disque dur), uploadez-le dans le répertoire racine de WordPress, et renommez-le .htaccess. La section qui suit vous aidera à éditer ce fichier.

Modifier les règles de réécriture : l'URL Rewriting (.htaccess)

Les versions 1.5+ de WordPress gèrent l'URL Rewriting directement. Vous n'aurez probablement pas besoin d'éditer le fichier .htacces directement.

Votre serveur doit le mod_rewrite activé pour permettre l'utilisation de Permaliens propres. Créez un fichier .htaccess à la racine de votre répertoire WordPress (le même répertoire qui contient le fichier index.php). Par exemple, si votre site est installé sur monsite.fr/wordpress/, le fichier .htaccess doit être placé sur monsite.fr/wordpress/.htaccess. Ajout à la traduction : il est recommandé de ne pas mélanger les .htaccess et les différents répertoires de votre site. En particulier si vous avez un forum sur votre site, il est recommandé d'utiliser deux répertoires distincts monsite.fr/blog/ pour WordPress et monsite.fr/forum pour le forum. Si vous préférez garder WordPress à la racine, utilisez un fichier monsite.fr/forum/.htaccess pour les règles de réécriture du forum.

When you create a permalink structure, WordPress will generate rewrite rules for you to copy and paste into your .htaccess file.

A few cautions about creating and editing your .htaccess file:

  • You must have FTP access to create the .htaccess file
  • You must chmod the .htaccess file to 666 to edit it with the WordPress template editor. Do not leave your file's permissions set to 666 as it may be accessible by anyone. After applying the permalinks, change the permissions to something stronger, like 660, to protect it.
  • If you leave whitespace at the end of your .htaccess file, it may make all pages on your site unavailable (though they will still exist, and your data will not be harmed). If this happens, delete the .htaccess file and create a new one.
  • If your .htaccess file contains errors that bring down your site, you will need to use FTP or your host's control panel to delete the rogue .htaccess file. Once a fatal change has been saved in the WordPress editor, the editor (along with the rest of your site) will not be available until the problem is fixed.
  • You may also be able to use your host's control panel to create and edit the .htaccess file. If so, it is likely you will still be able to edit the .htaccess file through this method, even if errors in the file have brought down your site itself.

Using Permalinks Without mod_rewrite

For permalinks in general, you must use 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. If you put a filename at the beginning, WordPress will attempt to use that to pass the arguments and bypass the necessity for mod_rewrite.

/index.php/%year%/%monthnum%/%day%/%postname%/

If you use this option, you can ignore the rewrite rules (that is, you can ignore .htaccess).

  • 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:
cgi.fix_pathinfo = 1
cgi.force_redirect = 0

This reference from Cem via http://blog.taragana.com/index.php/archive/wordpress-tip-on-permalink-options/

Fixing Permalink Problems

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.
    1. 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.
    2. Look for $is_apache = strstr($_SERVER['SERVER_SOFTWARE'], 'Apache') ? 1 : 0;, once you find it replace it with // $is_apache = strstr($_SERVER['SERVER_SOFTWARE'], 'Apache') ? 1 : 0;
    3. Add a new line under // $is_apache = strstr($_SERVER['SERVER_SOFTWARE'], 'Apache') ? 1 : 0; and type in $is_apache = 1;

Long Permalinks

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.

http://yourdomain.example.com/2005/10/4/article-about-joe-fred-sally-and-bog

Can result in:

http://yourdomain.example.com/2005/10/4/article-about-joe-fred-sally-and-bog

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 and save the file:

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:

Read my blog post at <http://yourdomain.example.com/2005/10/4/article-about-joe-fred-sally-and-bog>


Fixing Other Issues

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.

AllowOverride Not Enabled 
Your server may not have the AllowOverride directive enabled. If the AllowOverride directive is set to None in your Apache httpd.config file, then .htaccess files are completely ignored. In this case, the server will not even attempt to read .htaccess files in the filesystem. When this directive is set to All, then any directive which has the .htaccess Context is allowed in .htaccess files. Example of enabled AllowOverride directive in httpd.config:
<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>
You may also have to change the AllowOverride settings for the site. This is surely the case when using Mac Osx Server, but might be likewise with other systems. Usually you can find the site configuration files in /etc/httpd/sites/
If you don't want to set AllowOverride to all (as it is above) then your AllowOverride list must include the FileInfo directive. You must restart your Apache server for any httpd.config file changes to take effect. For more information on which overrides are allowed, read about Apache Core Features.
Paged Navigation Doesn't Work 
Sometimes navigation to second (and subsequent) pages of posts does not work as expected. Your page may generate a link to a page with one of these URIs:
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/
The result of clicking one of those links is that the page loads with all the surroundings (header, footer, sidebar), but instead of a page of posts, there is an error message: "Sorry, no posts match that criteria."
This is due to a glitch in the .htaccess file that WordPress generates. To fix it, delete the contents of your .htaccess file and re-create it.
  1. In the Control Panel, go to Manage > Files (More Info on Editing Files)
  2. Click the link to your .htaccess file to edit its contents
  3. Copy the contents of the file and paste it to a text file in a text editor
    This is a precaution in case your .htaccess file has manual entries for redirects, denials or other handy htaccess tricks
  4. Delete all contents from your .htaccess file and click the Update File button.
  5. In the Control Panel, go to Options > Permalinks.
  6. Click the Update Permalink Structure button to freshly generate new rewrite rules for your permalinks.
  7. Test the results using a link that had previously broken.
  8. Add any manual htaccess entries back in your file
    (Place manual htaccess entries before the # BEGIN WordPress or after # END WordPress lines.)
You may also perform similar steps by deleting the .htaccess files from the server, creating a fresh empty .htaccess file, changing its permissions to 666, and then in Options > Permalinks generate a new set of htaccess rules by clicking the Update Permalinks Structure button.
If that still doesn't work, take a look at the wordpress support forums, specifically, this support post.
Permalinks to pages don't work 
If you've tried to navigate to a newly created Page and encounter an error, you likely need to update your Permalink structure. Remember, each time you add a new static Page to WordPress, new rules must be generated and updated to .htaccess
Permalinks work but no pages are returned 
Some versions of PHP 4.4.x and 5.x have a bug that causes mod_rewrite to fail when used with some versions of Apache 2.x. More details at http://bugs.php.net/bug.php?id=35096 and http://bugs.php.net/bug.php?id=35059.

More Help

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.


Using Permalinks Without mod_rewrite

For permalinks in general, you must use 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. If you put a filename at the beginning, WordPress will attempt to use that to pass the arguments and bypass the necessity for mod_rewrite.

/index.php/%year%/%monthnum%/%day%/%postname%/

If you use this option, you can ignore the rewrite rules (that is, you can ignore .htaccess).

  • 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:
cgi.fix_pathinfo = 1
cgi.force_redirect = 0

This reference from Cem via http://blog.taragana.com/index.php/archive/wordpress-tip-on-permalink-options/


Fixing Permalink Problems

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.
    1. 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.
    2. Look for $is_apache = strstr($_SERVER['SERVER_SOFTWARE'], 'Apache') ? 1 : 0;, once you find it replace it with // $is_apache = strstr($_SERVER['SERVER_SOFTWARE'], 'Apache') ? 1 : 0;
    3. Add a new line under // $is_apache = strstr($_SERVER['SERVER_SOFTWARE'], 'Apache') ? 1 : 0; and type in $is_apache = 1;

Long Permalinks

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.

http://yourdomain.example.com/2005/10/4/article-about-joe-fred-sally-and-bog

Can result in:

http://yourdomain.example.com/2005/10/4/article-about-joe-fred-sally-and-bog

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 and save the file:

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:

Read my blog post at <http://yourdomain.example.com/2005/10/4/article-about-joe-fred-sally-and-bog>


Fixing Other Issues

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.

AllowOverride Not Enabled 
Your server may not have the AllowOverride directive enabled. If the AllowOverride directive is set to None in your Apache httpd.config file, then .htaccess files are completely ignored. In this case, the server will not even attempt to read .htaccess files in the filesystem. When this directive is set to All, then any directive which has the .htaccess Context is allowed in .htaccess files. Example of enabled AllowOverride directive in httpd.config:
<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>
You may also have to change the AllowOverride settings for the site. This is surely the case when using Mac Osx Server, but might be likewise with other systems. Usually you can find the site configuration files in /etc/httpd/sites/
If you don't want to set AllowOverride to all (as it is above) then your AllowOverride list must include the FileInfo directive. You must restart your Apache server for any httpd.config file changes to take effect. For more information on which overrides are allowed, read about Apache Core Features.
Paged Navigation Doesn't Work 
Sometimes navigation to second (and subsequent) pages of posts does not work as expected. Your page may generate a link to a page with one of these URIs:
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/
The result of clicking one of those links is that the page loads with all the surroundings (header, footer, sidebar), but instead of a page of posts, there is an error message: "Sorry, no posts match that criteria."
This is due to a glitch in the .htaccess file that WordPress generates. To fix it, delete the contents of your .htaccess file and re-create it.
  1. In the Control Panel, go to Manage > Files (More Info on Editing Files)
  2. Click the link to your .htaccess file to edit its contents
  3. Copy the contents of the file and paste it to a text file in a text editor
    This is a precaution in case your .htaccess file has manual entries for redirects, denials or other handy htaccess tricks
  4. Delete all contents from your .htaccess file and click the Update File button.
  5. In the Control Panel, go to Options > Permalinks.
  6. Click the Update Permalink Structure button to freshly generate new rewrite rules for your permalinks.
  7. Test the results using a link that had previously broken.
  8. Add any manual htaccess entries back in your file
    (Place manual htaccess entries before the # BEGIN WordPress or after # END WordPress lines.)
You may also perform similar steps by deleting the .htaccess files from the server, creating a fresh empty .htaccess file, changing its permissions to 666, and then in Options > Permalinks generate a new set of htaccess rules by clicking the Update Permalinks Structure button.
If that still doesn't work, take a look at the wordpress support forums, specifically, this support post.
Permalinks to pages don't work 
If you've tried to navigate to a newly created Page and encounter an error, you likely need to update your Permalink structure. Remember, each time you add a new static Page to WordPress, new rules must be generated and updated to .htaccess
Permalinks work but no pages are returned 
Some versions of PHP 4.4.x and 5.x have a bug that causes mod_rewrite to fail when used with some versions of Apache 2.x. More details at http://bugs.php.net/bug.php?id=35096 and http://bugs.php.net/bug.php?id=35059.

More Help

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.

Tips and Tricks

Having your posts ending on .html

There's an easy way to having your posts end in an 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 true html pages. For an outsider it only looks like it is a genuine html page.


External Resources