Share
Questa è la seconda parte di una serie che esamina l'API Rewrite di WordPress. Nella prima parte abbiamo fatto un giro di prova sulle basi dell'API Rewrite di WordPress. In questo tutorial vedremo le impostazioni di riscrittura disponibili per la registrazione di un tipo di post o di tassonomia. Mentre i tipi di post personalizzati e le tassonomie (a differenza dei post, delle categorie e dei tag predefiniti) non traggono alcun beneficio da qualsiasi interfaccia Impostazioni -> Permalink, la configurazione delle riscritture per i tipi personalizzati è ancora abbastanza semplice. Useremo anche i metodi introdotti nella prima parte, quindi se non lo hai già ti consiglio di leggere WordPress 'Rewrite API Part One: The Basics.
Quando registri un tipo personalizzato, WordPress registra anche le regole di riscrittura (in realtà, non proprio, e spiegherò perché nella sezione "Permastrutture"). Come menzionato nella prima parte, queste regole saranno incluse solo una volta che le regole di riscrittura saranno "svuotate". Temi e plug-in possono forzare questo "flushing" chiamando flush_rewrite_rules (). Questo deve e deve essere fatto solo una volta all'attivazione e poi di nuovo alla disattivazione (per ripulire dopo te stesso).
Ovviamente, prima di svuotare le regole di riscrittura, è necessario averle aggiunte. Comunque, il dentro agganciati su quali tipi di post devono essere registrati, è già stato attivato e quando lo era, il tuo plug-in o tema non era ancora attivo e quindi i tuoi tipi di post e le tassonomie non sono ancora registrati. Per registrare le regole di riscrittura associate ai tuoi tipi di post e tassonomie, ciò significa che devi "manualmente" registrarle all'attivazione, prima di svuotare le regole di riscrittura. Quindi, questo dovrebbe essere il tuo set up:
Accentsconagua
function wptuts_register_types () // funzione che registra il tuo tipo di post personalizzato e le tassonomie add_action ('init', 'wptuts_register_types'); function wptuts_plugin_activation () // Registra i tipi per registrare le regole di riscrittura wptuts_register_types (); // Quindi svuotali flush_rewrite_rules (); register_activation_hook (__FILE__, 'wptuts_plugin_activation'); function wptuts_plugin_deactivation () flush_rewrite_rules (); register_activation_hook (__FILE__, 'wptuts_plugin_activation'); I temi possono utilizzare i ganci after_switch_theme per attivazione e switch_theme per la disattivazione.
Quando registri un tipo di messaggio con register_post_type uno degli argomenti a tua disposizione è l'argomento di riscrittura. Questo dovrebbe essere un array con i seguenti tasti:
lumaca - una lumaca utilizzata per identificare il tipo di messaggio negli URL. Lo slug del post è aggiunto a questo per il permalink del post, ad es. www.example.com/libri/il mago di Oz with_front - vero o falso. Se la struttura del permalink del tuo post inizia con una base costante, come "/ blog", questa può anche essere aggiunta alla struttura del permalink del tuo tipo di post personalizzato impostandola su true ad es. il vero darà www.example.com/blog/books/ e falso www.example.com/books/ feed - vero o falso. Se generare regole di riscrittura dei feed, ad es. www.example.com/books/feed/rss e www.example.com/book/rss. Il valore predefinito è il valore di has_archive.pagine - vero o falso. Se generare regole per l'impaginazione "carina" per l'archivio del tipo di post, ad es. www.example.com/books/page/2 invece di www.example.com/books?page=2. Il valore predefinito è true.ep_mask - Questo era un argomento separato: permalink_epmask. A partire dal 3.4 passerà alla matrice di riscrittura. L'impostazione predefinita è EP_PERMALINK.I tasti "feed" e "pagine" riguardano solo la pagina di archivio di tipo post (per la quale è necessario aver impostato il file has_archive argomento vero). Da questo array di riscrittura, WordPress gestisce automaticamente la generazione delle regole di riscrittura per i tuoi tipi di post. Come esempio:
$ labels = array ('name' => __ ('Books', 'your-plugins-translation-domain'), // array di etichette); $ args = array ('labels' => $ labels, 'has_archive' => true, 'rewrite' => array ('slug' => 'libri', 'with_front' => false, 'feed' => true, 'pages' => true)); register_post_type ( 'libro', $ args); Darebbe le seguenti regole di riscrittura:
il mago di Oz': www.example.com/books/the-wizard-of-oz www.example.com/books (e www.example.com/books/page/2)www.example.com/books/feed/rss (e www.example.com/books/rss)Il register_taxonomy () la funzione offre meno opzioni:
lumaca - una lumaca per identificare la tassonomia, ad es. www.example.com/genere/storia with_front - Come sopra.gerarchica - vero o falso. Se impostato su true e la tassonomia è gerarchica, il termine permalink riflette la gerarchia. Il valore predefinito è falso.ep_mask - Aggiunto in 3.4. Vedere la sezione Maschera EP di seguito.Le prime due opzioni sono simili alle precedenti. L'opzione gerarchica conferisce al termine permalink la stessa struttura delle pagine. Ad esempio, lascia che 'Storia' sia un genere e 'Storia militare' un sotto-genere. Con l'impostazione gerarchica su false, "Storia militare" avrà il permalink:
www.example.com/genre/military-history
Considerando che, impostato su true, avrà:
www.example.com/genre/military/military-history
La registrazione di una tassonomia registra automaticamente i feed dei tuoi termini tassonomici:
www.example.com/genre/military-history/feed
Puoi ottenere il collegamento del feed-link a qualsiasi termine di tassonomia con
$ feed_link = get_term_feed_link ($ term_id, $ taxonomy, $ feed)
Per impostazione predefinita, WordPress non produce permalink "carini" per gli archivi dell'anno, del mese o del giorno del tipo di post personalizzato (né l'archivio dell'autore - ma lasceremo quello per ora). Mentre:
www.example.com/?post_type=book&year=2012&monthnum=05
Fornisce correttamente un archivio di tutti i libri pubblicati nel maggio 2012:
www.example.com/books/2012/05
Darà un errore 404. Tuttavia, possiamo semplicemente aggiungere regole di riscrittura aggiuntive usando i metodi disponibili dell'API di riscrittura che abbiamo trattato nella prima parte. Un metodo consiste nell'aggiungere il seguente elenco di regole di riscrittura quando si registra il tipo di post:
// Aggiungi archivio giorno (e impaginazione) add_rewrite_rule ("books / ([0-9] 4) / ([0-9] 2) / ([0-9] 2) / page /? ([0-9] 1,) /?", 'index.php? post_type = libro & anno = $ matches [1] & monthnum = $ matches [2] e giorno = $ matches [3] e di paging = $ matches [4] ','superiore'); add_rewrite_rule ( "libri / ([0-9] 4) / ([0-9] 2) / ([0-9] 2) /?", 'index.php? post_type = book & anno = $ matches [1] & monthnum = $ matches [2] e giorno = $ matches [3]', 'top'); // Aggiungi archivio mese (e impaginazione) 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 ( "libri / ([0-9] 4) / ([0-9] 2) /?", 'index.php? post_type = libro & anno = $ matches [1] & monthnum = $ matches [2 ]','superiore'); // Aggiungi archivio annuale (e impaginazione) add_rewrite_rule ("books / ([0-9] 4) / page /? ([0-9] 1,) /?", 'Index.php? Post_type = book & anno = $ matches [1] e di paging = $ matches [2]', 'top'); add_rewrite_rule ( "libri / ([0-9] 4) /?", 'index.php post_type = libro & anno = $ matches [1]?', 'top'); Questo può facilmente diventare un po 'complicato, soprattutto se si considera che è necessario aggiungere regole aggiuntive se si desidera che gli archivi supportino URL piuttosto per i propri feed. Tuttavia, quanto sopra illustra un fatto importante sull'aggiunta di regole personalizzate: l'ordine in cui vengono aggiunte le regole è importante.
Ricordiamo che queste regole vengono aggiunte alla matrice di riscrittura nell'ordine in cui si chiama add_rewrite_rule. Durante l'analisi di una richiesta, WordPress utilizza il primo regola di corrispondenza. Prova a cambiare l'ordine in cui vengono aggiunte le regole di archiviazione anno e mese. Lo troverai www.example.com/books/2012/04/ ti porta all'archivio 2012. Questo perché quell'URL corrisponde ai pattern sia per gli archivi dell'anno che per quelli del mese, ma il primo è stato aggiunto per primo. Ricorda di aggiungere sempre prima la regola più specifica.
D'altra parte, se si aggiunge una regola di riscrittura, la cui espressione regolare esiste già di regola, tale regola deve essere sovrascritta da quella nuova.
C'è un modo semplice per ottenere quanto sopra: add_permastruct. Questa funzione è utilizzata da WordPress per creare "permastrutture", da cui genera regole di riscrittura (come sopra), che gestiscono l'impaginazione e i feed. Quando registri un tipo di messaggio personalizzato, WordPress non crea automaticamente tutte le regole di riscrittura. Invece registra una permostruttura - e solo quando vengono generate le regole (cioè quando vengono svuotate) WordPress usa quelle permaste per generare le regole di riscrittura reali.
Un esempio di permostruttura è quello che usi in Impostazioni -> Permalink. Questi accettano slug 'hardcoded' o qualsiasi tag esistente per impostazione predefinita o con cui sono stati aggiunti add_rewrite_tag, di cui abbiamo parlato nella prima parte. Ad esempio, la permastruttura % All'anno% / Categoria%% /% autore% genererebbe le seguenti regole di riscrittura:
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 FunzioneIl add_permastruct la funzione accetta quattro argomenti:
nome - Una lumaca unica per identificare la tua permastrutturastruct - La permastruttura stessa ad es. '% All'anno% / Categoria%% /% autore%'with_front - vero o falso. Questo è lo stesso argomento di quando si registra il tipo di postep_mask - Vedere la sezione Maschera EP di seguitoUn paio di avvertenze sull'uso add_permastruct bisogno di essere fatto qui Primo: vorrai assicurarti che una permostruttura personalizzata non sia in conflitto con le regole di riscrittura di WordPress per post e pagine. Questo può essere fatto anteponendo la permostruttura personalizzata a qualcosa di hard-coded. Per esempio:
'% /% Monthnum% /% day% qualcosa-hard-coded /% l'anno'
In secondo luogo, le regole vengono aggiunte in questo ordine, quindi se i tuoi tag sono "troppo generici", le ultime regole potrebbero non essere mai applicate. Ad esempio, la struttura di cui sopra (che puoi provare nelle tue Impostazioni -> pagina Permalinks), generalmente funziona bene, tranne che:
www.example.com/2012/page/2
Viene interpretato come la pagina dei post dell'autore '2', nella categoria 'pagina' nel 2012. Se si desidera utilizzare add_permastruct e le vostre regole di impaginazione e feeds si sovrappongono bene, quindi dovrete usare tag che non sono "generici" (con ciò intendo dire che le espressioni regex non sono generiche). %autore% e %categoria% sono buoni esempi di tag generici in quanto generalmente corrispondono a qualsiasi carattere.
I tag dell'anno, del mese e del giorno sono molto specifici, corrispondenti solo ai numeri interi positivi delle lunghezze quattro e due, quindi possiamo usare add_permastruct per l'archivio delle date del nostro tipo di post. A causa della natura specifica dei tag data, è necessario aggiungere queste regole prima la regola di permalink del tipo di post - quindi aggiungi immediatamente quanto segue prima registrando il tuo tipo di messaggio:
// Si noti che questo funziona solo su 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%'); In quanto sopra, il tag personalizzato % Book_cpt% agisce da slug hardcoded per differenziare questa permeabilità da altre regole (come da primo avvertimento). Le regole generate si applicheranno solo se % Book_cpt% corrisponde a 'libri' e, nel qual caso la parte 'libro' viene catturata e interpretata come il valore per post_type. Si prega di notare che add_rewrite_tag accetta solo il terzo argomento da WordPress 3.4. Tuttavia, è possibile utilizzare il seguente work-around:
globale $ wp_rewrite; $ Wp_rewrite-> add_rewrite_tag ( '% book_cpt%', '(libro) s', 'post_type =');
Avendo creato gli archivi del libro, potresti anche aspettarti questo
www.example.com/books?year=2012
Ci porterebbe anche all'archivio del libro del 2012. Provarlo, tuttavia, rivela che invece ci porta alla pagina di archivio post anno:
www.example.com/2012/
WordPress ci ha reindirizzato a una pagina diversa a causa di qualcosa noto come canonicalizzazione.
In genere ci sono molti URL che potrebbero puntare allo stesso contenuto sul tuo sito web. Per esempio:
www.example.com/anno2008 www.esempio.it/anno200/page/1 www.esempio.com/2012/////////page/1 www.esempio.it/index.php / 2012 / www.example.com/index.php////2012///page/1
Ti porteranno tutti alla prima pagina del tuo archivio 2012. Da un punto di vista SEO questo non è eccezionale - non possiamo presumere che i motori di ricerca riconosceranno questi URL come la stessa risorsa, e questi URL potrebbero finire in competizione gli uni contro gli altri. Google potrebbe inoltre penalizzarti attivamente per contenuti duplicati e, sebbene sia utile per determinare quando questa duplicazione non è "dannosa", raccomanda comunque di reindirizzare questi superflui URL a un URL "canonico" (o standard) preferito. Questo è chiamato canonica.
Fare così non solo aiuta a consolidare le valutazioni come la popolarità dei link, ma aiuta anche gli utenti. Se utilizzano un URL brutto o "errato", vengono portati all'URL "corretto" e ciò che è nella loro barra degli indirizzi è ciò che è più probabile che ritorni a.
Dal momento che 2.1.0 WordPress ha gestito il reindirizzamento canonico, anche prendendo una supposizione istruita sul contenuto ricercato se la query originale ha restituito un 404. Sfortunatamente, in questo caso, WordPress reindirizza all'URL sbagliato. Questo perché l'URL che vogliamo veramente non è compreso in modo nativo da WordPress e ha ignorato la parte "post type" dell'URL. Fortunatamente, tuttavia, possiamo usare il redirect_canonical filtro per risolvere questo problema.
add_filter ('redirect_canonical', 'wptuts_redirect_canonical', 10, 2); function wptuts_redirect_canonical ($ redirect_url, $ requested_url) global $ wp_rewrite; // Interrompi se non usi dei permalink piuttosto, è un feed, o non un archivio per il tipo di post 'libro' se (! $ Wp_rewrite-> using_permalinks () || is_feed () ||! Is_post_type_archive ('book')) return $ REDIRECT_URL; // Ottieni le parti della query originale $ redirect = @parse_url ($ requested_url); $ originale = $ redirect_url; if (! isset ($ redirect ['query'])) $ redirect ['query'] = "; // Se è year / month / day - append year 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')). $ anno; // Se è mese / giorno - append mese if (is_month () || is_day ()) $ month = zeroise (intval (get_query_var ('monthnum')), 2); $ redirect ['query'] = remove_query_arg ('monthnum', $ redirect ['query']); $ redirect_url. = '/'.$month; // Se è giorno - append day if (is_day ()) $ day = zeroise (intval ( get_query_var ('day')), 2); $ redirect ['query'] = remove_query_arg ('day', $ redirect ['query']); $ redirect_url. = '/'.$day; // Se cercapersone , accodare l'impaginazione if (get_query_var ('paged')> 0) $ paged = (int) get_query_var ('paged'); $ redirect ['query'] = remove_query_arg ('paged', $ redirect ['query']) ; if ($ paged> 1) $ redirect_url. = user_trailingslashit ("/ page / $ paged", "paged"); if ($ redirect_url == $ originale) restituisce $ originale; // tack su qualsiasi query aggiuntiva 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); ritorno $ redirect_url; La funzione di cui sopra è lunga, ma non molto complicata. Potrebbe essere migliorato, ed è solo inteso come un esempio di ciò che si può fare con il redirect_canonical filtro. Prima controlla che siano attivati i permalink piuttosto belli, che stiamo cercando il nostro archivio "libro" e non è un feed. Quindi controlla a turno:
www.example.com/books/[year] www.example.com/books/[year]/[monthnum] www.example.com/books/[year]/[monthnum]/[day] Un'altra caratteristica che non è supportata per i tipi di post o le tassonomie 'out of the box' è quella di utilizzare i tag nella struttura permalink. Mentre i tag utilizzati nella "slug" dell'array di riscrittura di un tipo di post (o della tassonomia) sono interpretati correttamente, WordPress non sostituisce questi tag con i loro valori appropriati quando generano i permalink - dobbiamo sostituirlo noi stessi. Tuttavia, l'utilizzo di tag come questo interrompe anche la pagina di archivio del tipo di post, quindi utilizzeremo un metodo diverso. Ad esempio, supponiamo di volere che il nostro tipo di post personalizzato "libro" abbia la struttura:
www.example.com/books/[some-genre]/[a-book]
Sto utilizzando l'esempio di una tassonomia personalizzata, ma gli stessi metodi possono essere utilizzati per qualsiasi permostruttura (ad esempio, tra cui la data, l'autore o persino un campo personalizzato). Prima di tutto, aggiungiamo la regola di riscrittura:
function wptuts_custom_tags () add_rewrite_rule ("^ books / ([^ /] +) / ([^ /] +) /?", 'index.php? post_type = book & genere = $ corrisponde a [1] & book = $ corrisponde a [2 ]','superiore'); add_action ('init', 'wptuts_custom_tags'); Adesso, www.example.com/book/fiction/the-wizard-of-oz, per esempio, indica il libro 'il mago di Oz'. Tuttavia il permalink generato da WordPress produce ancora www.example.com/book/the-wizard-of-oz. Il prossimo passo è modificare il permalink prodotto.
Abbiamo fatto qualcosa di simile nella prima parte quando volevamo utilizzare un tag personalizzato nella struttura post permalink. Quindi abbiamo usato il post_link filtro; questa volta utilizziamo l'equivalente per i tipi di post personalizzati, il post_type_link filtro. Usando questo gancio possiamo iniettare la nostra struttura nei permalink dei libri.
function wptuts_book_link ($ post_link, $ id = 0) $ post = get_post ($ id); if (is_wp_error ($ post) || 'book'! = $ post-> post_type || empty ($ post-> post_name)) restituisce $ post_link; // Ottieni il genere: $ terms = get_the_terms ($ post-> ID, 'genere'); if (is_wp_error ($ terms) ||! $ terms) $ genre = 'uncategorised'; else $ genre_obj = array_pop ($ termini); $ genere = $ genre_obj-> slug; return home_url (user_trailingslashit ("books / $ genre / $ post-> post_name")); add_filter ('post_type_link', 'wptuts_book_link', 10, 2); Estendiamo la struttura del permalink di cui sopra per ottenere quanto segue:
www.example.com/books/[some-genre]/[a-book] www.example.com/books/[some-genre] www.example.com/books/ Ricorda che l'ordine in cui le regole di riscrittura vengono aggiunte importa. Nello specifico, le regole aggiunte prima hanno la priorità.
Quindi, per prima cosa registriamo il nostro "genere" di tassonomia personalizzata con:
$ args = array (... 'rewrite' => array ('slug' => 'libri'), ...) register_taxonomy ('genere', $ args); Questo aggiunge la seguente permastruttura:
www.example.com/books/[some-genre] Dopo aver registrato la tassonomia, registriamo il nostro tipo di post personalizzato come segue:
$ args = array (... 'rewrite' => array ('slug' => 'libri'), ...) register_post_type ('book', $ args); Questo registrerebbe le seguenti regole:
www.example.com/books/ (che vogliamo)www.example.com/books/[a-book] (che non lo facciamo)Tuttavia il secondo conflitto con (ed è "battuto" da) la regola in competizione aggiunta quando abbiamo registrato la nostra tassonomia. La struttura risultante è:
www.example.com/books/fiction/slug www.example.com/books/slug www.example.com/books/ In precedenza, quando abbiamo esaminato la registrazione di tipi di post, tassonomie (o altrimenti, perostrutture), WordPress ci ha permesso di specificare il nostro "ep_mask'. Quindi cosa sono?
Nella prima parte abbiamo visto come possiamo aggiungere endpoint add_rewrite_endpoint. Il secondo argomento in quella funzione è una costante (o una combinazione di costanti che utilizzano operatori bit a bit), che determinano dove viene aggiunto l'endpoint. Per esempio:
add_rewrite_endpoint ('form', EP_PAGES); Aggiunge la riscrittura forma (/(.*))?/?$ a ogni pagina permalink e:
add_rewrite_endpoint ('json', EP_PAGES | EP_PERMALINKS); Aggiunge la riscrittura JSON (/(.*))?/?$ ad ogni post e pagina permalink. Quindi queste costanti specificano una "posizione" (ad esempio "alla fine di un post permalink") e vengono chiamate maschere di endpoint (o maschere ep).
Quando registri un tipo di post, WordPress registra una permastruttura e ad essa è associata una maschera endpoint. Quindi, quando vengono generate le regole di riscrittura, aggiunge anche le regole di riscrittura degli endpoint che sono state aggiunte a quella maschera dell'endpoint.
Ad esempio, quando WordPress registra il tipo di post "Pagina" predefinito, associa la maschera dell'endpoint EP_PAGES con la permutazione della pagina. Quindi, qualsiasi regola di riscrittura endpoint aggiunta a EP_PAGES vengono effettivamente aggiunti alla permostruttura di quella pagina. Quando registri un tipo di post, puoi specificare la tua maschera di endpoint o usarne una esistente. Di default lo è EP_PERMALINKS - il che significa che tutte le regole di riscrittura degli endpoint vengono aggiunte EP_PERMALINKS vengono aggiunti alle regole di riscrittura del tipo di post personalizzato.
Ovviamente potresti non voler aggiungere le regole degli endpoint per il tuo tipo di post (nel qual caso puoi usare la maschera dell'endpoint EP_NONE), oppure potresti voler aggiungere alcune regole di riscrittura degli endpoint solo al tuo tipo di post personalizzato. Per fare ciò, devi prima creare una maschera per endpoint, che non è altro che una costante che soddisfa:
La potenza del requisito 2 è necessaria perché WordPress utilizza la logica binaria per determinare dove aggiungere le regole dell'endpoint. Sfortunatamente, questo è quasi impossibile da controllare, quindi il consiglio migliore è di aggiungere maschere di endpoint solo quando necessario e dargli un valore molto alto (ad esempio 221). Al momento di scrivere 20 fino a 213 sono usati da Core.
Definisci la tua maschera di endpoint appena prima di registrare il tuo tipo di post o la tua tassonomia:
define ('EP_BOOK', 8388608); // 8388608 = 2 ^ 23 $ args = array ('labels' => $ labels, 'has_archive' => true, 'rewrite' => array ('slug' => 'libri "with_front' => falso 'feed' => true 'pages' => true 'ep_mask' => EP_BOOK)); register_post_type ('book', $ args); // Quindi puoi terminare le regole di riscrittura su questa maschera endpoint add_rewrite_endpoint ('loan', EP_BOOK); (Nota: quanto sopra utilizza gli argomenti di WordPress 3.4. Se utilizzi una versione precedente di WordPress, dovrai utilizzare l'ormai deprecato permalink_epmask.). A partire da WordPress 3.4 è possibile specificare una maschera endpoint anche quando si registra una tassonomia.
In questo tutorial ho trattato le basi dell'API di riscrittura per i tipi di post e le tassonomie, ma anche alcuni argomenti più avanzati. La gestione delle riscritture di WordPress è (necessariamente) complessa e il modo migliore per comprenderlo è approfondire il codice sorgente e testarlo utilizzando ciò che hai imparato e un plug-in dell'analizzatore di riscrittura.
Al momento ci sono un paio di ticket che si stanno facendo strada attraverso lo sviluppo di WordPress Trac, relativi all'API Rewrite. In futuro vedremo un modo molto più semplice e senza conflitti di passare le maschere degli endpoint.
