Share
Il s’agit de la deuxième partie d’une série consacrée à l’API Rewrite de WordPress. Dans la première partie, nous avons effectué un tour d'horizon complet des bases de l'API Rewrite de WordPress. Dans ce didacticiel, nous examinerons les paramètres de réécriture disponibles lors de l’enregistrement d’un type de message ou d’une taxonomie. Bien que les types et les taxonomies personnalisés (contrairement aux publications, catégories et balises par défaut) ne bénéficient d'aucune interface Paramètres -> Lien permanent, la configuration des réécritures pour les types personnalisés reste assez simple. Nous utiliserons également les méthodes présentées dans la première partie. Par conséquent, si vous ne l'avez pas déjà fait, je vous recommande de lire l'API Rewrite de WordPress, première partie: notions de base..
Lorsque vous enregistrez un type personnalisé, WordPress enregistre également les règles de réécriture (en réalité, pas assez, et j'expliquerai pourquoi dans la section 'Permastructures'). Comme indiqué dans la première partie, ces règles ne seront incluses qu'une fois que les règles de réécriture auront été supprimées. Les thèmes et les plug-ins peuvent forcer ce "rinçage" en appelant flush_rewrite_rules (). Cela doit et ne doit être fait qu'une fois lors de l'activation, puis à nouveau lors de la désactivation (pour nettoyer après vous-même).
Évidemment, avant de vider les règles de réécriture, vous devez les avoir ajoutées. Cependant, le init Le crochet sur les types de messages qui doivent être enregistrés a déjà été activé et quand il l'était, votre plug-in ou thème n'était pas encore actif. Par conséquent, vos types de messages et vos taxonomies ne sont pas encore enregistrés. Pour enregistrer les règles de réécriture fournies avec vos types de publications et vos taxonomies, vous devez les enregistrer "manuellement" lors de l'activation, avant de vider les règles de réécriture. Donc, cela devrait être votre mise en place:
Accentsconagua
function wptuts_register_types () // fonction qui enregistre votre type d'article et vos taxonomies personnalisés add_action ('init', 'wptuts_register_types'); function wptuts_plugin_activation () // Enregistrer les types pour enregistrer les règles de réécriture wptuts_register_types (); // Puis les flush flush_rewrite_rules (); register_activation_hook (__FILE__, 'wptuts_plugin_activation'); fonction wptuts_plugin_deactivation () flush_rewrite_rules (); register_activation_hook (__FILE__, 'wptuts_plugin_activation'); Les thèmes peuvent utiliser les crochets after_switch_theme pour l'activation et switch_theme pour la désactivation.
Lorsque vous enregistrez un type de message avec register_post_type L’un des arguments à votre disposition est l’argument de réécriture. Cela devrait être un tableau avec les clés suivantes:
limace - un slug utilisé pour identifier le type de message dans les URL. Le slug du post est ajouté à cela pour le permalien du post par exemple. www.example.com/livres/le magicien d'Oz with_front - vrai ou faux. Si la structure de lien permanent de votre message commence par une base constante, telle que "/ blog", vous pouvez également l'ajouter à la structure de lien permanent de votre type de message personnalisé en lui attribuant la valeur true, par exemple. vrai donnera www.example.com/blog/books/ et faux www.example.com/books/ les flux - vrai ou faux. Indique s'il faut générer des règles de réécriture de flux. www.example.com/books/feed/rss et www.example.com/book/rss. La valeur par défaut est la valeur de has_archive.des pages - vrai ou faux. Indique s'il faut générer une règle pour la "jolie" pagination pour l'archive de type publication. www.example.com/books/page/2 au lieu de www.example.com/books?page=2. La valeur par défaut est true.ep_mask - C'était un argument séparé: permalink_epmask. À partir de 3.4, il passera au tableau de réécriture. La valeur par défaut est EP_PERMALINK.Les touches 'feeds' et 'pages' concernent uniquement la page d'archive post-type (pour laquelle vous devez avoir défini le paramètre has_archive argument à true). À partir de ce tableau de réécriture, WordPress gère automatiquement la génération des règles de réécriture pour vos types de publication. Par exemple:
$ labels = array ('name' => __ ('Books', 'your-plugins-translation-domain'), // tableau d'étiquettes); $ args = array ('labels' => $ labels, 'has_archive' => true, 'rewrite' => array ('slug' => 'books', 'with_front' => false, 'feed' => true, 'pages' => true)); register_post_type ('book', $ args); Donnerait les règles de réécriture suivantes:
le magicien d'Oz': www.example.com/books/the-wizard-of-oz www.example.com/books (et www.example.com/books/page/2)www.example.com/books/feed/rss (et www.example.com/books/rss)le register_taxonomy () fonction offre moins d'options:
limace - une limace pour identifier la taxonomie, par exemple. www.example.com/genre/l'histoire with_front - Comme ci-dessus.hiérarchique - vrai ou faux. Si défini sur true et que la taxonomie est hiérarchique, le terme permalien reflète la hiérarchie. La valeur par défaut est false.ep_mask - Ajouté en 3.4. Voir la section masque EP ci-dessous.Les deux premières options sont similaires à celles ci-dessus. L'option hiérarchique donne au terme permaliens la même structure que les pages. Par exemple, supposons que l’histoire soit un genre et l’histoire militaire, un sous-genre. Si la hiérarchie est définie sur false, "Histoire militaire" aura un permalien:
www.example.com/genre/histoire-militaire
Considérant que, mis à true, il aura:
www.example.com/genre/military/military-history
L'enregistrement d'une taxonomie enregistre automatiquement les flux de vos termes de taxonomie:
www.example.com/genre/histoire-militaire/feed
Vous pouvez obtenir le lien permanent entre tous les termes de taxonomie avec
$ feed_link = get_term_feed_link ($ term_id, $ taxonomy, $ feed)
Par défaut, WordPress ne produit pas de "jolis" permaliens pour les archives de l'année, du mois ou du jour de votre type de message personnalisé (ni l'archive de l'auteur, mais nous la laisserons pour l'instant). Tandis que:
www.example.com/?post_type=book&year=2012&monthnum=05
Donne correctement les archives de tous les livres publiés en mai 2012:
www.example.com/books/2012/05
Donnera une erreur 404. Cependant, nous pouvons simplement ajouter des règles de réécriture supplémentaires à l'aide des méthodes d'API de réécriture disponibles, décrites dans la première partie. Une méthode consiste à ajouter la liste suivante de règles de réécriture lorsque vous enregistrez votre type de publication:
// Ajoute l'archive journalière (et la pagination) add_rewrite_rule ("books / ([0-9] 4) / 0 [9-9] 2) / ([0-9] 2) / page /? ([0-9] 1,) /? ", 'Index.php? Post_type = livre & année = $ correspondances [1] & monthnum = $ correspondances [2] & jour = $ correspondances [3] & paginé = $ correspondances [4] ','Haut'); add_rewrite_rule ("books / ([0-9] 4) / ([0-9] 2) / ([0-9] 2) /?", 'index.php? post_type = book & year = $ correspondances [1] & monthnum = $ correspondances [2] & jour = $ correspondances [3] ',' top '); // Ajouter les archives du mois (et la pagination) add_rewrite_rule ("books / ([0-9] 4) / / [[0-9] 2]) / page /? ([0-9] 1,) /?",'index.php?post_type=book&year=$matches[1]&monthnum=$matches[2]&paged=$matches[3]','top '); add_rewrite_rule ("books / ([0-9] 4) / ([0-9] 2) /?", 'index.php? post_type = book & year = $ correspond [1] & monthnum = $ correspond [2 ]','Haut'); // Ajouter les archives d'année (et la pagination) add_rewrite_rule ("books / ([0-9] 4)) / page /? ([0-9] 1,) /?", 'Index.php? Post_type = book & year = $ correspondances [1] & paginé = $ correspondances [2] ',' top '); add_rewrite_rule ("books / ([0-9] 4) /?", 'index.php? post_type = book & year = $ correspond [1]', 'top'); Cela peut facilement devenir un peu compliqué, en particulier si vous considérez qu'il vous faudrait ajouter des règles supplémentaires si vous souhaitez que vos archives prennent en charge de jolies URL pour leurs flux. Cependant, ce qui précède illustre un fait important sur l'ajout de règles personnalisées: l'ordre dans lequel les règles sont ajoutées est important..
Rappelez-vous que ces règles sont ajoutées au tableau de réécriture dans l’ordre dans lequel vous appelez add_rewrite_rule. Lors de l'analyse d'une requête, WordPress utilise le premier règle correspondante. Essayez de changer l'ordre dans lequel les règles d'archive de l'année et du mois sont ajoutées. Vous trouverez que www.example.com/books/2012/04/ vous emmène aux archives 2012. En effet, cette URL correspond aux modèles des archives de l'année et du mois, mais l'ancien a été ajouté en premier.. N'oubliez pas de toujours ajouter la règle la plus spécifique en premier.
Par contre, si vous ajoutez une règle de réécriture, dont l’expression rationnelle existe déjà en règle, cette règle sera remplacée par la nouvelle..
Il existe un moyen simple de réaliser ce qui précède: add_permastruct. WordPress utilise cette fonction pour créer des "permastructures" à partir desquelles il génère des règles de réécriture (comme ci-dessus), qui gèrent la pagination et les flux. Lorsque vous enregistrez un type de publication personnalisé, WordPress ne crée pas automatiquement toutes les règles de réécriture. Au lieu de cela, il enregistre une permastructure - et c'est uniquement lorsque les règles sont générées (c'est-à-dire lorsqu'elles sont vidées) que WordPress utilise ces permastructures pour générer les règles de réécriture réelles..
Un exemple de permastructure est celui que vous utilisez dans Paramètres -> Permaliens. Ceux-ci acceptent les slugs "codés en dur" ou les tags existants par défaut ou ajoutés avec add_rewrite_tag, que nous avons couvert dans la première partie. Par exemple, la permastructure % année% /% catégorie% /% auteur% générerait les règles de réécriture suivantes:
www.example.com/2012/url-rewriting/stephen www.example.com/2012/url-rewriting/stephen/page/2 www.example.com/2012/url-rewriting/stephen/feed/rss www.example.com/2012/url-rewriting/ www.example.com/2012/url-rewriting/page/2 www.example.com/2012/url-rewriting/feed/rss www.example.com/2012/ www.example.com/2012/page/2 www.example.com/2012/feed/rss add_permastruct Une fonctionle add_permastruct La fonction accepte quatre arguments:
prénom - Un slug unique pour identifier votre permastructurestruct - La permastructure elle-même, par exemple '% année% /% catégorie% /% auteur%'with_front - vrai ou faux. C'est le même argument que lors de l'enregistrement du type de messageep_mask - Voir la section masque EP ci-dessousQuelques avertissements sur l’utilisation de add_permastruct besoin d'être fait ici. Tout d'abord, vous devez vous assurer qu'une permastructure personnalisée ne se heurte pas aux règles de réécriture de WordPress pour les publications et les pages. Cela peut être fait en ajoutant à votre permastructure personnalisée quelque chose de codé en dur. Par exemple:
'quelque chose de codé en dur /% année% /% monthnum% /% jour%'
Deuxièmement, les règles sont ajoutées dans cet ordre. Par conséquent, si vos balises sont «trop génériques», ces dernières règles pourraient ne jamais être appliquées. Par exemple, la structure ci-dessus (que vous pouvez essayer sur votre page Paramètres -> Permaliens) fonctionne généralement bien, sauf que:
www.example.com/2012/page/2
Est interprété comme la page d'articles de l'auteur '2', dans la catégorie 'page' en 2012. Si vous souhaitez utiliser add_permastruct et que vos règles de pagination et de flux soient bien en cascade, vous devrez alors utiliser des balises qui ne sont pas «génériques» (ce qui veut dire que les expressions rationnelles ne sont pas génériques). %auteur% et %Catégorie% sont de bons exemples de balises génériques car elles correspondent généralement à tous les caractères..
Par contre, les balises year, month et day sont très spécifiques - ne faisant correspondre que des entiers positifs de longueurs quatre et deux, nous pouvons donc utiliser add_permastruct pour les archives de date de notre type de message. En raison de la nature spécifique des balises de date, nous avons besoin de ces règles pour être ajouté avant la règle permalien de type de message - ajoutez donc immédiatement ce qui suit avant enregistrer votre type de message:
// Veuillez noter que cela ne fonctionnera que sur WordPress 3.4+ http://core.trac.wordpress.org/ticket/19871 add_rewrite_tag ('% book_cpt%', '(book) s', 'post_type ='); add_permastruct ('book_archive', '% book_cpt% /% year% /% monthnum% /% day%'); Dans ce qui précède, la balise personnalisée % book_cpt% agit comme un pion codé en dur pour différencier cette permastructure des autres règles (comme indiqué dans le premier avertissement). Les règles générées ne s'appliqueront que si % book_cpt% correspond aux "livres" et, dans ce cas, la partie "livre" est capturée et interprétée comme la valeur pour Type de poste. S'il vous plaît noter que add_rewrite_tag accepte uniquement le troisième argument depuis WordPress 3.4. Cependant, vous pouvez utiliser la solution suivante:
global $ wp_rewrite; $ wp_rewrite-> add_rewrite_tag ('% book_cpt%', '(livre) s', 'post_type ='); Après avoir mis en place les archives du livre, vous pouvez également vous attendre à ce que
www.example.com/books?year=2012
Cela nous amènerait également aux archives du livre de 2012. Le test, cependant, révèle qu’il nous amène plutôt à la page d’archive de l’année suivante:
www.example.com/2012/
WordPress nous a redirigé vers une page différente en raison de quelque chose connu comme canonicalization.
En règle générale, de nombreuses URL peuvent pointer vers le même contenu sur votre site Web. Par exemple:
www.example.com/year/2012 www.example.com/year/2012/page/1 www.example.com/2012/////////page/1 www.example.com/index.php / 2012 / www.example.com/index.php////2012///page/1
Tous vous mèneront à la première page de vos archives de 2012. Du point de vue du référencement, ce n’est pas formidable. Nous ne pouvons pas supposer que les moteurs de recherche reconnaîtront ces URL comme étant la même ressource et que ces URL risquent de se faire concurrence. Google peut également activement vous pénaliser pour le contenu en double. S'il est bien placé pour déterminer si cette duplication n'est pas "malveillante", il recommande néanmoins de rediriger ces URL superflues vers une URL "canonique" (ou standard) préférée. C'est appelé canonisation.
Cela permet non seulement de consolider des notations telles que la popularité des liens, mais aide également vos utilisateurs. S'ils utilisent une URL laide ou «incorrecte», ils sont redirigés vers l'URL «correcte». Le contenu de leur barre d'adresses est celui dans lequel ils sont le plus susceptibles de revenir..
Depuis la version 2.1.0, WordPress gère la redirection canonique, prenant même une hypothèse éclairée sur le contenu recherché si la requête d'origine renvoyait un 404. Malheureusement, dans ce cas, WordPress redirige vers la mauvaise URL. En effet, l'URL que nous voulons réellement n'est pas compris de manière native par WordPress, qui a ignoré la partie "type de publication" de l'URL. Heureusement, cependant, nous pouvons utiliser le redirect_canonical filtre pour résoudre ce problème.
add_filter ('redirect_canonical', 'wptuts_redirect_canonical', 10, 2); fonction wptuts_redirect_canonical ($ redirect_url, $ required_url) global $ wp_rewrite; // Abandonne si j’utilise pas de jolis permaliens, c’est un flux, ou pas une archive pour le type de publication 'book' if (! $ Wp_rewrite-> using_permalinks () || is_feed () ||! Is_post_type_archive ('book')) return $ redirect_url; // Récupère les parties de la requête d'origine $ redirect = @parse_url ($ required_url); $ original = $ redirect_url; if (! isset ($ redirect ['query'])) $ redirect ['query'] = "; // est l'année / le mois / le jour - ajoute l'année if (is_year () || is_month () || is_day ( )) $ year = get_query_var ('year'); $ redirect ['query'] = remove_query_arg ('year', $ redirect ['query']); $ redirect_url = user_trailingslashit (get_post_type_archive_link ('book')). $ year; // If is month / day - ajoute un mois if (is_month () || is_day ()) $ month = zeroise (intval (get_query_var ('monthnum')), 2); $ redirect ['query'] = remove_query_arg ('monthnum', $ redirect ['query']); $ redirect_url. = '/'.$month; // Si is jour - ajoute un jour if (is_day ()) $ day = zeroise (intval ( get_query_var ('jour')), 2); $ redirect ['requête'] = remove_query_arg ('jour', $ redirect ['requête']); $ redirect_url. = '/'.$day; // si paginé , apppend pagination if (get_query_var ('paginé')> 0) $ paginé = (int) get_query_var ('paginé'); $ redirect ['requête'] = remove_query_arg ('paginé', $ redirect ['requête']) ; if ($ paged> 1) $ redirect_url. = user_trailingslashit ("/ page / $ paged", 'paged'); if ($ redirect_url == $ original) renvoie $ original; // cloue sur toute requête supplémentaire vars $ redirect ['query'] = preg_replace ('# ^ \ ?? & *? #', ", $ redirect ['query']); if ($ redirect_url &&! empty ($ redirect ['query'])) parse_str ($ redirect ['query'], $ _parsed_query); $ _parsed_query = array_map ('rawurlencode', $ _parsed_query); $ redirect_url = add_query_arg ($ _parsed_query, $ redirect_url); $ redirect_url; La fonction ci-dessus est longue, mais pas très compliquée. Il pourrait être amélioré et est uniquement destiné à illustrer ce que vous pouvez faire avec le redirect_canonical filtre. Il vérifie d’abord que les jolis permaliens sont activés, que nous recherchons notre archive de «livres» et que ce n’est pas un flux. Il vérifie ensuite à son tour:
www.exemple.com/books/[année] www.example.com/books/[year]/[monthnum] www.example.com/books/[year]/[monthnum]/[day] Une autre fonctionnalité qui n'est pas prise en charge pour les types de publication ou les taxonomies «clés en main» consiste à utiliser des balises dans la structure de permalien. Bien que les balises utilisées dans le 'slug' du tableau de réécriture d'un type de message (ou d'une taxonomie) soient correctement interprétées, WordPress ne remplace pas ces balises par leurs valeurs appropriées lors de la génération des permaliens - nous devons le remplacer nous-mêmes. Cependant, l'utilisation de balises comme celle-ci rompt également la page d'archivage du type de publication. Nous allons donc utiliser une méthode différente. A titre d'exemple, supposons que nous voulions que notre type de publication personnalisé 'book' ait la structure suivante:
www.example.com/books/[some-genre]/[a-book]
J'utilise l'exemple d'une taxonomie personnalisée, mais les mêmes méthodes peuvent être utilisées pour n'importe quelle permastructure (par exemple, incluant la date, l'auteur ou même un champ personnalisé). Tout d'abord, nous ajoutons la règle de réécriture:
fonction wptuts_custom_tags () add_rewrite_rule ("^ livres / ([^ /] +) / ([^ /] +) /?", 'index.php? post_type = livre & genre = $ correspond [1] & livre = $ correspond [2 ]','Haut'); add_action ('init', 'wptuts_custom_tags'); À présent, www.example.com/book/fiction/the-wizard-of-oz, par exemple, pointe vers le livre 'le magicien d'Oz'. Cependant, le permalien généré par WordPress produit toujours www.example.com/book/the-wizard-of-oz. La prochaine étape consiste à modifier le permalien produit.
Nous avons fait quelque chose de similaire dans la première partie lorsque nous avons voulu utiliser une balise personnalisée dans la structure post-permalien. Ensuite, nous avons utilisé le post_link filtre; cette fois, nous utilisons l'équivalent pour les types de publication personnalisés, le post_type_link filtre. En utilisant ce crochet, nous pouvons injecter notre structure dans les permaliens des livres.
fonction wptuts_book_link ($ post_link, $ id = 0) $ post = get_post ($ id); if (is_wp_error ($ post) || 'book'! = $ post-> type_post || vide ($ post-> nom_post)) return $ post_link; // Récupère le genre: $ terms = get_the_terms ($ post-> ID, 'genre'); if (is_wp_error ($ terms) ||! $ terms) $ genre = 'non catégorisé'; else $ genre_obj = array_pop ($ terms); $ genre = $ genre_obj-> slug; return home_url (user_trailingslashit ("books / $ genre / $ post-> post_name")); add_filter ('post_type_link', 'wptuts_book_link', 10, 2); Étendons la structure permalien ci-dessus pour atteindre les objectifs suivants:
www.example.com/books/[some-genre]/[a-book] www.example.com/books/[some-genre] www.example.com/books/ Rappelez-vous que l'ordre dans lequel les règles de réécriture sont ajoutées est important. Plus précisément, les règles ajoutées en premier ont priorité.
Donc, d’abord, nous enregistrons notre taxonomie personnalisée 'genre' avec:
$ args = array (… 'rewrite' => array ('slug' => 'books'),…) register_taxonomy ('genre', $ args); Cela ajoute la permastructure suivante:
www.example.com/books/[some-genre] Après avoir enregistré la taxonomie, nous enregistrons notre type de publication personnalisé comme suit:
$ args = array (… 'rewrite' => array ('slug' => 'books'),…) register_post_type ('book', $ args); Cela enregistrerait les règles suivantes:
www.example.com/books/ (que nous voulons)www.example.com/books/[a-book] (ce que nous ne faisons pas)Cependant, le second est en conflit avec la règle concurrente ajoutée lors de l’enregistrement de notre taxonomie et est dépassé par cette règle. La structure résultante est:
www.example.com/books/fiction/slug www.example.com/books/slug www.example.com/books/ Auparavant, lorsque nous avions envisagé d'enregistrer des types de publication, des taxonomies (ou autres, des structures), WordPress nous a permis de spécifier notre propre "ep_mask'. Alors que sont-ils?
Dans la première partie, nous avons examiné comment ajouter des points de terminaison avec add_rewrite_endpoint. Le deuxième argument de cette fonction est une constante (ou une combinaison de constantes à l'aide d'opérateurs au niveau des bits), qui détermine l'endroit où le point final est ajouté. Par exemple:
add_rewrite_endpoint ('form', EP_PAGES); Ajoute la réécriture formulaire (/(.*))?/?$ à chaque page permalien et:
add_rewrite_endpoint ('json', EP_PAGES | EP_PERMALINKS); Ajoute la réécriture json (/(.*))?/?$ à chaque poste et page permalink. Donc, ces constantes spécifient un "emplacement" (c'est-à-dire "à la fin d'un post permalien") et on les appelle masques d'extrémité (ou masques ep).
Lorsque vous enregistrez un type de publication, WordPress enregistre une permastructure - et y associe un masque de point final. Ensuite, lorsque les règles de réécriture sont générées, il ajoute également les règles de réécriture de noeud final ajoutées à ce masque de noeud final..
Par exemple, lorsque WordPress enregistre le type de publication "Page" par défaut, il associe le masque de point final. EP_PAGES avec la permastructure de la page. Ensuite, toute règle de réécriture de noeud final ajoutée à la EP_PAGES sont en fait ajoutés à cette page. Lorsque vous enregistrez un type de publication, vous pouvez spécifier votre propre masque de noeud final ou en utiliser un existant. Par défaut c'est EP_PERMALINKS - ce qui signifie que toutes les règles de réécriture de points de terminaison ajoutées à EP_PERMALINKS sont ajoutés aux règles de réécriture de votre type de message personnalisé.
Bien sûr, vous ne voudrez peut-être pas ajouter de règles de point de terminaison pour votre type de publication (auquel cas vous pouvez utiliser le masque de point de terminaison). EP_NONE), ou vous pouvez souhaiter ajouter des règles de réécriture de point final seulement à votre type de message personnalisé. Pour ce faire, vous devez d’abord créer un masque de point de terminaison, qui n’est autre chose qu’une constante qui satisfait:
La puissance requise de 2 est nécessaire car WordPress utilise une logique binaire pour déterminer où les règles de point de terminaison doivent être ajoutées. Malheureusement, comme il est presque impossible de le vérifier, le meilleur conseil est d’ajouter des masques de terminal uniquement lorsque cela est nécessaire et de lui attribuer une valeur très élevée (par exemple, 221). Au moment de l'écriture 20 jusqu'à 213 sont utilisés par Core.
Définissez votre masque de point de terminaison juste avant d’enregistrer votre type de message ou votre taxonomie:
define ('EP_BOOK', 8388608); // 8388608 = 2 ^ 23 $ args = array ('labels' => $ labels, 'has_archive' => true, 'rewrite' => array ('slug' => 'livres "with_front' => false 'flux' => true 'pages' => true 'ep_mask' => EP_BOOK)); register_post_type ('book', $ args); // Vous pouvez alors réécrire les règles du noeud final add_rewrite_endpoint ('loan', EP_BOOK); (Remarque: Ce qui précède utilise des arguments WordPress 3.4. Si vous utilisez une version plus ancienne de WordPress, vous devrez utiliser la méthode maintenant obsolète. permalink_epmask.). À partir de WordPress 3.4, vous pouvez également spécifier un masque de point final lors de l'enregistrement d'une taxonomie..
Dans ce tutoriel, j'ai abordé les bases de l'API de réécriture pour les types d'articles et les taxonomies, mais également des sujets plus avancés. Le traitement des réécritures par WordPress est (nécessairement) complexe et la meilleure façon de le comprendre est de fouiller dans le code source et de le tester à l'aide de ce que vous avez appris et d'un plug-in d'analyse de réécriture..
Il existe actuellement quelques tickets dans le développement WordPress Trac, relatifs à l’API Rewrite. À l’avenir, nous voyons un moyen beaucoup plus facile et sans conflit de manipuler des masques de points de terminaison.
