WordPress.org

Ready to get started?Download WordPress

Codex

Attention Interested in functions, hooks, classes, or methods? Check out the new WordPress Code Reference!

fr:Utilisation des permaliens

Page d'accueil du Codex en français - Télécharger WordPress en français
Les utilisateurs francophones se retrouvent sur le site WordPress-Francophone, notamment sur son forum d'entraide.

Les permaliens sont les adresses (URL) permanentes de vos articles, ainsi que des catégories, archives, et autres pages spéciales. Le permalien permet à un autre site de référer à l'un de vos articles, ou de pointer vers votre article depuis un courriel. L'adresse URL de chaque article devrait être permanente, et ne devrait jamais changer - d'où le terme de "perma"-lien.

Les types de permaliens

Il existe trois types de permaliens dans WordPress:

mod_rewrite: "permaliens simplifiés"

En utilisant les fonctions mod_rewrite ou lighttpd de votre serveur, vous pouvez produire des permaliens agréables à la lecture (voir Pretty Permalinks). Il existe de nombreux formats possibles, mais les plus communs ressemblent à ceci :

http://exemple.fr/2012/mon-article/

ou

http://exemple.com/2012/12/30/mon-article

Les "permaliens simplifés" sont disponibles sous ces environnements :

  • Serveur web Apache avec le module mod_rewrite
  • Serveur web Microsoft IIS 7+ avec le module URL Rewrite 1.1+ module et PHP 5 en mode FastCGI
  • Microsoft IIS 6+ en utilisant ASAPI_Rewrite
  • Lighttpd en utilisant a 404 handler ou mod_rewrite (voir See Also)

PATHINFO: "semi-simplifié"

Avec PATHINFO, les liens ressemblent à ceux de mod_rewrite à une exception près : ils sont précédés d'une partie /index.php, de cette manière :

http://exemple.fr/index.php/2012/12/30/mon-article/

Mis à part ce détail, ils sont identiques aux permaliens simplifiés en mod_rewrite, et offrent la même flexibilité.

Choisir votre structure de permaliens

Dans la page de configuration Réglages → Permaliens, vous pouvez choisir l'un des "Réglages courants" proposés, ou créer une "Structure personnalisée" en utilisant les marqueurs de structure.

À noter : Ne mettez jamais le nom de domaine de votre site dans le champ Structure personnalisée. N'utilisez que les marqueurs de structure.

Pour activer les permaliens PATHINFO, votre structure devra commencer par index.php/.

permalink-settings.png

Les marqueurs de structure

À noter : Ne mettez jamais le nom de domaine de votre site dans le champ Structure personnalisée. N'utilisez que les marqueurs de structure.

Vous pouvez utiliser ces marqueurs afin de personnaliser vos permaliens "simplifiés". Quelques conseils:

  • Assurez-vous que votre structure se termine soit par %post_id%, soit par %postname% (p.ex. /%year%/%monthnum%/%day%/%postname%/) afin que chaque permalien pointe vers un article unique.
 %year%
L'année de publication l'article, en quatre chiffres, par exemple : 2012
 %monthnum%
Le numéro du mois de publication, par exemple : 05
 %day%
Le jour du mois, par exemple : 28
 %hour%
L'heure de publication, par exemple : 15
 %minute%
La minute de publication, par exemple : 43
 %second%
La seconde de publication, par exemple : 33
 %post_id%
L'identifiant unique (ID) de l'article, par exemple : 423
 %postname%
Une version simplifiée du titre de l'article (le champ Identifiant dans l'interface d'édition). Par exemple, “Voici mon premier billet !” devient voici-mon-premier-billet dans l'URL.
 %category%
Une version simplifiée du nom de la catégorie (le champ Identifiant dans l'interface d'édition des Catégories). Les sous-catégories apparaîtront comme des sous-répertoires dans l'URL.
 %author%
Une version simplifiée du nom de l'auteur de l'article.

Préfixe des catégories, Préfixe des mots-clefs

Le Préfixe des catégories et le Préfixe des mots-clefs sont utilisés pour les liens des archives par catégories ou par mots-clefs. Ces liens ressemblent à ceci:

 example.net/wp/prefixe_de_categorie/nom_de_categorie
 example.net/wp/prefixe_de_mot_cle/nom_de_mot_cle

Les valeurs par défaut pour ces préfixes sont category et tag (si vous avez installé WordPress en anglais). Vous pouvez les modifier, mais vous ne pouvez pas empêcher ces préfixes d'apparaître dans vos URLs.

Les permaliens personnalisés fonctionnent sur la majorité des systèmes sans problèmes, mais dans certaines situations des problèmes peuvent survenir.

Utilisation de %category% avec des catégories multiples

Si un article est classé dans plusieurs catégories, seules l'une d'entre elles s'affichera dans le permalien. Ce sera la catégorie dont l'identifiant est le plus petit (voir Manage Categories en anglais). L'article sera toujours accessible en navigant par les autres catégories.

À partir d'ici, tout reste à traduire...

Utilisation des "permaliens simplifés"

Configuration requise:

  • Un serveur web Apache avev le module mod_rewrite installé
  • Pour le répertoire racine de WordPress,
    • l'option FollowSymLinks doit être active
    • la directive FileInfo doit être autorisée (p.ex. avec AllowOverride FileInfo, ou AllowOverride All)
    • un fichier .htaccess doit être présent (si ce fichier est absent, WordPress va tenter de le créer lorsque vous activez les "permaliens simplifiés")
    • Afin que WordPress puisse mettre à jour le fichier .htaccess automatiquement, WordPress doit avoir un accès en écriture sur ce fichier.
  • Avec un serveur web lighttpd, voir les informations ci-dessous.
  • Les utilisateurs de Mac OS X qui ont une installation WordPress en local sur leur machine devront éditeur leur fichier httpd.conf, et modifier la ligne the AllowOverride en AllowOverride All dans les instructions de l'environnement hôte Directory "/Library/WebServer/Documents". Pour Mac OS X 10.5.x et au-delà ce fichier est situé dans /private/etc/apache2/users/[votre-utilisateur].conf, pour les systèmes plus anciens, il est sous /etc/httpd/httpd.conf.

Lorsque vous créez ou mettez à jour une structure de permaliens "simplifiée", WordPress va génerer de nouvelles règles d'écriture d'URL, et va essayer de les insérer dans le fichier .htaccess file. Si cette opération échoue, un message vous indiquera que vous devez mettre à jour votre fichier .htaccess et vous indiquera le code que vous devrez copier et insérer dans ce fichier (en le plaçant tout à la fin).

Si le répertoire racine de votre installation WordPress venait à changer (dans le champ Adresse du site), vous devrez répéter cette procèdure.

WordPress va respecter un fichier .htaccess déjà existant, et n'effacera pas les régles d'écriture ("RewriteRules") déjà présentes. Si votre .htaccess comporte d'autres règles mod_rewrite, places celles de WordPress tout à la fin.

Où est mon fichier .htaccess ?

Les fichiers index.php et .htaccess de WordPress devraient se trouver au même endroit, dans le répertoire racine indiqué dans le champ Adresse web du site (URL) sur la page des Réglages Généraux. Puisque le nom du fichier débute par un point, certains clients FTP peuvent le masquer, à moins que vous ne changiez les préférences pour forcer l'affichage des fichiers invisibles. Certians hébergeurs (p.ex. Godaddy) peuvent masquer ce fichier, ou vous interdire de le modifier, si vous installez WordPress par la procédure automatique Godaddy Hosting Connection.

Créer et modifier votre .htaccess

Si ce fichier .htaccess n'existe pas, créez-le. Si vous avez accès au serveur en mode terminal (shell ou ssh), une simple commande touch .htaccess va créer ce fichier. Si vous utilisez un client FTP pour transférer vos fichiers, créez un fichier texte sur votre ordinateur, nommez-le 1.htaccess, téléversez-le à la racine de votre installation WordPress, et renommez-le en .htaccess.

Vous pouvez modifier le fichier .htaccess via votre client FTP, votre terminal shell, ou (éventuellement) par un gestionnaire de fichiers fourni par votre hébergeur .

Voici le code de réécriture de permaliens qui devrait être inclus dans votre fichier .htaccess (depuis WordPress 3.0):

# 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

Si votre fichier .htaccess contient des erreurs qui rendent votre site inaccessible ("Internal Server Error (500)"), vous devrez utiliser un accès FTP (ou le gestionnaire de fichiers de l'hébergeur) pour effacer le fichier .htaccess fautif.

Mise à jour automatique du fichier .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 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.

Utiliser les permaliens sans mod_rewrite

Non traduit, veuillez vous référer à la documentation en anglais.

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.
    • 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.

Permalinks, .htaccess, and MS Frontpage

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.

Quick Fixes, Frontpage or Permalinks

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.

Using FrontPage AND Permalinks Together

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_bin
Nested within that it creates both
_vti_adm
and
_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.

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:

 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>

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.

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 OS X 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 (WordPress 1.X) or to the internal rewrites array (WordPress 2.X).
Permalinks to Ultimate Tag Warrior tag pages don't work 
If you get 404 errors on local tag URLs when using the UltimateTagWarrior plugin on WordPress 2.X, it's because the internal rewrites generated by WordPress are being overly greedy and getting invoked before UTW's rewrite rules have a chance. This usually occurs only when using a custom permalink structure (like /%postname%/). To fix it, either switch your Permalink structure to "Date and name based" or hack the UTW plugin to place the UTW rewrites at the top of the internal rewrites array.
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.