Share
Esta es la segunda parte de una serie que analiza la API de Rewrite de WordPress. En la primera parte hicimos un recorrido por los aspectos básicos de la API de Rewrite de WordPress. En este tutorial veremos la configuración de reescritura disponible para nosotros al registrar un tipo de publicación o taxonomía. Si bien los tipos de publicaciones personalizadas y las taxonomías (a diferencia de las publicaciones, categorías y etiquetas predeterminadas) no se benefician de ninguna Configuración -> Interfaz de enlace permanente, la configuración de las reescrituras para los tipos personalizados sigue siendo bastante sencilla. También utilizaremos los métodos presentados en la primera parte, por lo que si aún no lo he recomendado, lea la Parte 1 de la API de Rewrite de WordPress: Conceptos básicos.
Cuando registra un tipo personalizado, WordPress también registra reglas de reescritura (en realidad, no exactamente, y explicaré por qué en la sección 'Permastructures'). Como se mencionó en la primera parte, estas reglas solo se incluirán una vez que se "borren" las reglas de reescritura. Los temas y los complementos pueden forzar este 'lavado' llamando flush_rewrite_rules (). Esto debe y solo debe hacerse una vez que se active y luego otra vez que se desactive (para limpiar después de usted).
Obviamente, antes de borrar las reglas de reescritura, debe haberlas agregado. Sin embargo, el en eso enganche en qué tipos de publicaciones se deben registrar, ya se ha activado y, cuando lo estaba, su complemento o tema aún no estaba activo y, por lo tanto, sus tipos de publicaciones y taxonomías aún no están registradas. Para registrar las reglas de reescritura que vienen con sus tipos de publicaciones y taxonomías, esto significa que necesita registrarlas manualmente en la activación, antes de vaciar las reglas de reescritura. Por lo tanto, esta debe ser su configuración:
Accentsconagua
función wptuts_register_types () // función que registra su tipo de publicación personalizada y taxonomías add_action ('init', 'wptuts_register_types'); function wptuts_plugin_activation () // Registrar tipos para registrar las reglas de reescritura wptuts_register_types (); // Luego enjuáguelos flush_rewrite_rules (); register_activation_hook (__FILE__, 'wptuts_plugin_activation'); función wptuts_plugin_deactivation () flush_rewrite_rules (); register_activation_hook (__FILE__, 'wptuts_plugin_activation'); Los temas pueden usar los ganchos. after_switch_theme para la activación y cambiar_tema para la desactivación.
Cuando se registra un tipo de publicación con register_post_type uno de los argumentos disponibles para usted es el argumento de reescritura. Esto debería ser una matriz con las siguientes claves:
babosa - un slug utilizado para identificar el tipo de publicación en las URL. La barra de la publicación se adjunta a esto para el enlace permanente de la publicación, por ejemplo,. www.example.com/libros/El mago de Oz with_front - verdadero o falso. Si la estructura de enlace permanente de su publicación comienza con una base constante, como '/ blog', esto también se puede agregar a la estructura de enlace permanente de su publicación personalizada configurándola en verdadero, p. Ej. verdadero dará www.example.com/blog/books/ y falso www.example.com/books/ alimenta - verdadero o falso. Ya sea para generar reglas de reescritura de noticias. www.example.com/books/feed/rss y www.example.com/book/rss. El valor predeterminado es el valor de has_archive.páginas - verdadero o falso. Ya sea para generar una regla para la paginación 'bonita' para el archivo de tipo de publicación, por ejemplo,. www.example.com/books/page/2 en lugar de www.example.com/books?page=2. Por defecto es verdadero.ep_mask - Esto solía ser un argumento separado: permalink_epmask. A partir de 3.4 se moverá a la matriz de reescritura. El valor predeterminado es EP_PERMALINK.Las teclas 'feeds' y 'páginas' se refieren solo a la página de archivo posterior al tipo (para la cual necesita establecer la has_archive argumento a la verdad). Desde esta matriz de reescritura, WordPress maneja la generación de las reglas de reescritura para sus tipos de publicaciones automáticamente. Como ejemplo:
$ labels = array ('name' => __ ('Books', 'your-plugins-translation-domain'), // array of labels); $ args = array ('labels' => $ labels, 'has_archive' => true, 'rewrite' => array ('slug' => 'books', 'with_front' => false, 'feed' => true, 'páginas' => verdadero)); register_post_type ('book', $ args); Daría las siguientes reglas de reescritura:
El mago de Oz': www.example.com/books/the-wizard-of-oz www.example.com/books (y www.example.com/books/page/2)www.example.com/books/feed/rss (y www.example.com/books/rss)los register_taxonomy () La función ofrece menos opciones:
babosa - una bala para identificar la taxonomía, por ejemplo,. www.example.com/género/historia with_front - Como anteriormente.jerárquico - verdadero o falso. Si se establece en true y la taxonomía es jerárquica, el término permalink refleja la jerarquía. Por defecto es falso.ep_mask - Añadido en 3.4. Ver la sección de Máscara de EP a continuación..Las dos primeras opciones son similares a las anteriores. La opción jerárquica le da al término enlaces permanentes la misma estructura que las páginas. Por ejemplo, deje que 'Historia' sea un género y 'Historia Militar' un subgénero. Con el conjunto jerárquico en falso, 'Historia militar' tendrá el enlace permanente:
www.example.com/genre/military-history
Considerando que, establecido en verdadero, tendrá:
www.example.com/genre/military/military-history
El registro de una taxonomía registra automáticamente los feeds de los términos de su taxonomía:
www.example.com/genre/military-history/feed
Puede obtener el enlace permanente a cualquier término de taxonomía con
$ feed_link = get_term_feed_link ($ term_id, $ taxonomy, $ feed)
De forma predeterminada, WordPress no produce los enlaces "bonitos" para los archivos de año, mes o día del tipo de publicación personalizada (ni el archivo del autor, pero lo dejaremos por ahora). Mientras:
www.example.com/?post_type=book&year=2012&monthnum=05
Proporciona correctamente un archivo de todos los libros publicados en mayo de 2012:
www.example.com/books/2012/05
Dará un error 404. Sin embargo, podemos simplemente agregar reglas de reescritura adicionales utilizando los métodos de API de reescritura disponibles que cubrimos en la primera parte. Un método es agregar la siguiente lista de reglas de reescritura cuando registra su tipo de publicación:
// Agregar el archivo del día (y la paginación) add_rewrite_rule ("books / ([0-9] 4) / ([0-9] 2) / ([0-9] 2) / page /? ([0-9] 1,) /? ", 'Index.php? Post_type = libro y año = $ coincidencias [1] y monthnum = $ coincidencias [2] & day = $ coincidencias [3] & paged = $ coincidencias [4] ','parte superior'); add_rewrite_rule ("books / ([0-9] 4) / ([0-9] 2) / ([0-9] 2) /?", 'index.php? post_type = book & year = $ coincidencias [1] y monthnum = $ coincidencias [2] y día = $ coincidencias [3] ',' top '); // Agregar el archivo del mes (y la paginación) 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 = $ matches [1] & monthnum = $ matches [2 ]','parte superior'); // Agregar archivo de año (y paginación) add_rewrite_rule ("books / ([0-9] 4) / page /? ([0-9] 1,) /?", 'Index.php? Post_type = book & year = $ matches [1] & paged = $ matches [2] ',' top '); add_rewrite_rule ("books / ([0-9] 4) /?", 'index.php? post_type = book & year = $ matches [1]', 'top'); Esto puede ensuciarse un poco, especialmente si considera que necesitaría agregar reglas adicionales si desea que sus archivos admitan URL bonitas para sus feeds. Sin embargo, lo anterior ilustra un hecho importante acerca de agregar reglas personalizadas: el orden en que se agregan las reglas es importante.
Recuerde que estas reglas se agregan a la matriz de reescritura en el orden en que llama add_rewrite_rule. Al analizar una solicitud, WordPress utiliza el primero regla de juego Intente cambiar el orden en el que se agregan las reglas de archivo de año y mes. Encontraras que www.example.com/books/2012/04/ te lleva al archivo de 2012. Esto se debe a que la URL coincide con los patrones de los archivos de año y mes, pero el primero se agregó primero. Recuerda siempre agregar primero la regla más específica..
Por otro lado, si agrega una regla de reescritura, cuya expresión regular ya existe como una regla, esa regla será anulada por la nueva.
Hay una manera fácil de lograr lo anterior: add_permastruct. WordPress utiliza esta función para crear "permastructures", desde donde genera reglas de reescritura (como las anteriores), que manejan la paginación y las fuentes. Cuando registra un tipo de publicación personalizada, WordPress no crea automáticamente todas las reglas de reescritura. En su lugar, registra una estructura de infraestructura, y solo cuando se generan las reglas (es decir, cuando se vacían), WordPress usa esas estructuras para generar las reglas de reescritura reales..
Un ejemplo de una estructura de infraestructura es la que utiliza en Configuración -> Permalinks. Estos aceptan cualquier tipo de código "rígido" o cualquier etiqueta que exista de forma predeterminada o que se haya agregado con add_rewrite_tag, que cubrimos en la primera parte. Por ejemplo, la estructura permeable % año% /% categoría% /% autor% generaría las siguientes reglas de reescritura:
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 Funciónlos add_permastruct La función acepta cuatro argumentos:
nombre - Una babosa única para identificar tu estructura.estructura - La propia estructura, por ejemplo. '% año% /% categoría% /% autor%'with_front - verdadero o falso. Este es el mismo argumento que al registrar el tipo de publicación.ep_mask - Ver la sección de Máscara de EP a continuación.Un par de advertencias sobre el uso add_permastruct hay que hacer aquí. Primero: querrá asegurarse de que una estructura de infraestructura personalizada no coincida con las reglas de reescritura de WordPress para publicaciones y páginas. Esto se puede hacer anteponiendo su estructura personalizada con algo codificado. Por ejemplo:
'algo codificado /% año% /% mes%% /% día%'
En segundo lugar, las reglas se agregan en ese orden; por lo tanto, si sus etiquetas son "demasiado genéricas", es posible que estas últimas reglas nunca se apliquen. Por ejemplo, la estructura anterior (que puede probar en su página Configuración -> Permalinks), generalmente funciona bien, excepto que:
www.example.com/2012/page/2
Se interpreta como la página de publicaciones del autor '2', en la categoría 'página' en 2012. Si desea utilizar add_permastruct y haga que las reglas de paginación y de fuentes de información estén bien conectadas en cascada, entonces deberá usar etiquetas que no sean "genéricas" (por lo que quiero decir que las expresiones de expresiones regulares no son genéricas). %autor% y %categoría% son buenos ejemplos de una etiqueta genérica, ya que estos normalmente coincidirán con cualquier carácter.
Las etiquetas de año, mes y día, por otro lado, son muy específicas: coinciden solo con enteros positivos de longitudes de cuatro y dos, por lo que podemos usar add_permastruct para el archivo de fecha de nuestro tipo de publicación. Debido a la naturaleza específica de las etiquetas de fecha, necesitamos que se agreguen estas reglas antes de la regla de permalink de tipo de publicación, así que agregue lo siguiente inmediatamente antes de registrando tu tipo de publicación:
// Tenga en cuenta que esto solo funcionará en 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%'); En lo anterior, la etiqueta personalizada. % book_cpt% actúa como un slug codificado para diferenciar esta estructura de otras reglas (según la primera advertencia). Las reglas generadas solo se aplicarán si % book_cpt% coincide con 'libros' y, en cuyo caso, la parte de 'libro' se captura e interpreta como el valor de tipo de mensaje. Tenga en cuenta que add_rewrite_tag Solo acepta el tercer argumento desde WordPress 3.4. Sin embargo, puede utilizar la siguiente solución:
global $ wp_rewrite; $ wp_rewrite-> add_rewrite_tag ('% book_cpt%', '(book) s', 'post_type ='); Una vez que haya configurado los archivos de libros, también puede esperar que
www.example.com/books?year=2012
Nos llevaría al archivo de libros de 2012 también. Sin embargo, probarlo revela que, en cambio, nos lleva a la página de archivo posterior al año:
www.example.com/2012/
WordPress nos ha redirigido a una página diferente debido a algo conocido como canonicalización.
Normalmente, hay muchas URL que podrían apuntar al mismo contenido en su sitio web. Por ejemplo:
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
Todos te llevarán a la primera página de tu archivo de 2012. Desde una perspectiva de SEO, esto no es bueno: no podemos asumir que los motores de búsqueda reconocerán estas URL como el mismo recurso, y estas URL pueden terminar compitiendo entre sí. Google también puede penalizarlo activamente por el contenido duplicado, y si bien es bueno para determinar cuándo esta duplicación no es "maliciosa", todavía recomienda redirigir estas URL superfluas a una URL "canónica" (o estándar) preferida. Se llama canonicalización.
Al hacerlo, no solo ayuda a consolidar calificaciones como la popularidad de enlaces, sino que también ayuda a sus usuarios. Si usan una URL fea o "incorrecta" (se les lleva a la URL "correcta") y lo que está en su barra de direcciones, es lo que tienen más probabilidades de volver a.
Desde la versión 2.1.0, WordPress ha manejado la redirección canónica, incluso teniendo en cuenta el contenido buscado si la consulta original obtuvo un 404. Lamentablemente, en este caso, WordPress está redirigiendo a la URL incorrecta. Esto se debe a que la URL que realmente queremos no es entendida de forma nativa por WordPress, y ha ignorado la parte de "tipo de publicación" de la URL. Afortunadamente, sin embargo podemos usar el redirect_canonical filtro para arreglar esto.
add_filter ('redirect_canonical', 'wptuts_redirect_canonical', 10, 2); función wptuts_redirect_canonical ($ redirect_url, $ required_url) global $ wp_rewrite; // Abortar si no usa los enlaces permanentes, es un feed o no un archivo para el tipo de publicación 'book' si (! $ Wp_rewrite-> using_permalinks () || is_feed () ||! Is_post_type_archive ('book')) return $ redirect_url; // Obtenga las partes de la consulta original $ redirect = @parse_url ($ request_url); $ original = $ redirect_url; if (! isset ($ redirect ['query'])) $ redirect ['query'] = "; // Si es año / mes / día: añada el año 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')). $ año; // Si es mes / día, agregue mes si (es_monto () || es_día ()) $ mes = cero (intval (get_query_var ('monthnum')), 2); $ redirect ['query'] = remove_query_arg ('monthnum', $ redirect ['query']); $ redirect_url. = '/'.$month; // Si es día - agregar día if (is_day ()) $ day = zeroise (intval ( get_query_var ('day')), 2); $ redirect ['query'] = remove_query_arg ('day', $ redirect ['query']); $ redirect_url. = '/'.$day; // Si está paginado , aplique la paginación 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 == $ original) devuelve $ original; // agregue cualquier consulta adicional 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; La función anterior es larga, pero no muy complicada. Se podría mejorar y solo pretende ser un ejemplo de lo que puede hacer con el redirect_canonical filtrar. Primero verifica que los enlaces permanentes estén activados, que estemos detrás de nuestro archivo de "libros" y que no sea un feed. A continuación, comprueba a su vez:
www.example.com/books/[year] www.example.com/books/[year◆ /[monthnum] www.example.com/books/[year◆/[monthnum◆/[day] Otra característica que no se admite para tipos de correos o taxonomías "fuera de la caja" es usar etiquetas en la estructura de enlace permanente. Mientras que las etiquetas utilizadas en el 'slug' de la matriz de reescritura de un tipo de publicación (o taxonomía) se interpretan correctamente, WordPress no reemplaza estas etiquetas con sus valores apropiados al generar los enlaces permanentes, debemos reemplazarlos nosotros mismos. Sin embargo, el uso de etiquetas como esta también rompe la página de archivo del tipo de publicación, por lo que usaremos un método diferente. Como ejemplo, supongamos que queremos que nuestro tipo de publicación personalizado 'libro' tenga la estructura:
www.example.com/books/[some-genre◆/[a-book]
Estoy usando el ejemplo de una taxonomía personalizada, pero se pueden usar los mismos métodos para cualquier estructura (por ejemplo, incluyendo la fecha, el autor o incluso un campo personalizado). En primer lugar, agregamos la regla de reescritura:
function wptuts_custom_tags () add_rewrite_rule ("^ books / ([^ /] +) / ([^ /] +) /?", 'index.php? post_type = book & genre = $ matches [1] & book = $ matches [2 ]','parte superior'); add_action ('init', 'wptuts_custom_tags'); Ahora, www.example.com/book/fiction/the-wizard-of-oz, por ejemplo, apunta al libro 'El mago de Oz'. Sin embargo, el enlace permanente generado por WordPress todavía produce www.example.com/book/the-wizard-of-oz. El siguiente paso es alterar el enlace permanente producido..
Hicimos algo similar en la primera parte cuando queríamos usar una etiqueta personalizada en la estructura de publicación permanente. Luego usamos el post_link filtrar; esta vez usamos el equivalente para tipos de correos personalizados, el post_type_link filtrar. Usando este gancho podemos inyectar nuestra estructura en los enlaces permanentes de los libros..
función wptuts_book_link ($ post_link, $ id = 0) $ post = get_post ($ id); if (is_wp_error ($ post) || 'book'! = $ post-> post_type || vacío ($ post-> post_name)) devuelve $ post_link; // Obtenga el género: $ términos = get_the_terms ($ post-> ID, 'género'); if (is_wp_error ($ términos) ||! $ términos) $ género = 'sin categorizar'; else $ genre_obj = array_pop ($ términos); $ genre = $ genre_obj-> slug; return home_url (user_trailingslashit ("books / $ genre / $ post-> post_name")); add_filter ('post_type_link', 'wptuts_book_link', 10, 2); Extendamos la estructura de enlace permanente anterior para lograr lo siguiente:
www.example.com/books/[some-genre◆/[a-book] www.example.com/books/[some-genre] www.example.com/books/ Recuerde que el orden en que se agregan las reglas de reescritura es importante. Específicamente, las reglas agregadas primero toman prioridad..
Entonces, primero registramos nuestro 'género' de taxonomía personalizada con:
$ args = array (... 'rewrite' => array ('slug' => 'books'), ...) register_taxonomy ('genre', $ args); Esto agrega la siguiente estructura:
www.example.com/books/[some-genre] Después de registrar la taxonomía, registramos nuestro tipo de publicación personalizada de la siguiente manera:
$ args = array (... 'rewrite' => array ('slug' => 'books'), ...) register_post_type ('book', $ args); Esto registraría las siguientes reglas:
www.example.com/books/ (lo que queramos)www.example.com/books/[a-book] (lo cual no hacemos)Sin embargo, el segundo conflicto con (y es "vencido" por) la regla de competencia agregada cuando registramos nuestra taxonomía. La estructura resultante es:
www.example.com/books/fiction/slug www.example.com/books/slug www.example.com/books/ Anteriormente, cuando observamos el registro de tipos de publicaciones, taxonomías (o de otro modo, estructuras), WordPress nos permite especificar el nuestro 'ep_mask'. Entonces, ¿qué son??
En la primera parte vimos cómo podemos agregar puntos finales con add_rewrite_endpoint. El segundo argumento en esa función es una constante (o combinación de constantes que usa operadores a nivel de bits), que determina dónde se agrega el punto final. Por ejemplo:
add_rewrite_endpoint ('form', EP_PAGES); Agrega la reescritura forma (/(.*))?/?$ a cada página enlace permanente y:
add_rewrite_endpoint ('json', EP_PAGES | EP_PERMALINKS); Agrega la reescritura json (/(.*))?/?$ a cada publicación y página enlace permanente. Así que estas constantes especifican una 'ubicación' (es decir, 'al final de un post en enlace permanente') y se llaman máscaras de punto final (o máscaras ep).
Cuando registra un tipo de publicación, WordPress registra una estructura de infraestructura, y le asocia una máscara de punto final. Luego, cuando se generan las reglas de reescritura, también agrega cualquier regla de reescritura de punto final que se haya agregado a esa máscara de punto final..
Por ejemplo, cuando WordPress registra el tipo de publicación 'Página' predeterminado, asocia la máscara de punto final EP_PAGES Con la estructura de la página. Entonces, cualquier regla de reescritura de punto final agregada al EP_PAGES En realidad se agregan a la estructura de esa página. Cuando registra un tipo de publicación, puede especificar su propia máscara de punto final o usar una existente. Por defecto es EP_PERMALINKS - lo que significa que cualquier regla de reescritura de punto final que se agregue a EP_PERMALINKS se agregan a las reglas de reescritura de tu tipo de publicación personalizada.
Por supuesto, es posible que no desee agregar reglas de punto final para su tipo de publicación (en cuyo caso puede usar la máscara de punto final). EP_NONE), o quizás desee agregar algunas reglas de reescritura de punto final solamente a su tipo de mensaje personalizado. Para hacer esto, primero debe crear una máscara de punto final, que no es más que una constante que satisface:
El requisito de poder de 2 es necesario porque WordPress utiliza lógica binaria para determinar dónde se deben agregar las reglas de punto final. Desafortunadamente, esto es casi imposible de verificar, por lo que el mejor consejo es agregar máscaras de punto final solo cuando sea necesario y darle un valor muy alto (por ejemplo, 221). En el momento de escribir 2.0 hasta 213 son utilizados por Core.
Defina su máscara de punto final justo antes de registrar su tipo de publicación o taxonomía:
define ('EP_BOOK', 8388608); // 8388608 = 2 ^ 23 $ args = array ('labels' => $ labels, 'has_archive' => true, 'rewrite' => array ('slug' => 'books "with_front' => false 'feed' => true 'pages' => true 'ep_mask' => EP_BOOK)); register_post_type ('book', $ args); // Luego puede reescribir las reglas a este punto final. add_rewrite_endpoint ('loan', EP_BOOK); (Nota: lo anterior usa los argumentos de WordPress 3.4. Si está usando una versión anterior de WordPress, tendrá que usar el ahora en desuso permalink_epmask.). A partir de WordPress 3.4, también puede especificar una máscara de punto final al registrar una taxonomía..
En este tutorial he cubierto los conceptos básicos de la API de reescritura para tipos de publicaciones y taxonomías, pero también algunos temas más avanzados. El manejo de las reescrituras de WordPress es (necesariamente) complejo y la mejor manera de entenderlo es ahondar en el código fuente y probarlo usando lo que ha aprendido y un complemento del analizador de reescritura.
Hay un par de tickets que se están abriendo paso a través del Trac de desarrollo de WordPress en este momento, relacionado con la API Rewrite. En el futuro, veremos una forma mucho más fácil y sin conflictos de administrar las máscaras de punto final..
