Le serveur web ne comprend nativement que des chemins de fichiers, pas des adresses comme /produit/chaise-en-bois/ ; il faut donc un mécanisme qui traduise ce genre d’URL en instructions compréhensibles par WordPress avant qu’il ne construise la requête correspondante.
Fonctionnement dans WordPress
WordPress maintient un tableau ordonné de motifs regex associés à des variables de requête, généré automatiquement selon la structure des permaliens et les taxonomies ou types de contenu personnalisés déclarés. Une extension peut ajouter ses propres règles avec add_rewrite_rule(), mais celles-ci ne prennent effet qu’après une régénération complète du tableau, déclenchée par flush_rewrite_rules() — jamais à chaque chargement de page, une opération trop coûteuse.
Exemple
add_rewrite_rule(
'^catalogue/([^/]+)/?$',
'index.php?post_type=produit&name=$matches[1]',
'top'
);Pièges fréquents
Oublier d’appeler flush_rewrite_rules() après l’ajout d’une règle — ou pire, l’appeler à chaque chargement au lieu de le réserver à l’activation du plugin — sont les deux erreurs les plus courantes autour de cette fonctionnalité.
Bon à savoir
L’ordre de priorité (top ou bottom) détermine si une règle personnalisée est testée avant ou après les règles natives de WordPress ; placer une règle trop générique en tête peut intercepter par erreur des URL destinées à un autre type de contenu.
La commande WP-CLI wp rewrite list permet d’inspecter le tableau complet des règles actives sur une installation, un outil de diagnostic précieux quand un permalien renvoie une page 404 inattendue sans erreur explicite dans les journaux serveur.