La API de reescritura Lo básico

Esta es la primera parte de una serie de dos partes que analiza la API de Rewrite de WordPress. En este tutorial veremos cómo funcionan las reescrituras y los métodos básicos disponibles para crear reglas de reescritura personalizadas..

Lo que es reescritura?

WordPress, como todos los sistemas de administración de contenido, decide qué contenido mostrar según las variables (generalmente llamadas variables de consulta) que se le pasan. Por ejemplo: http://example.com/index.php?category=3 le dice a WordPress que buscamos publicaciones en una categoría con un ID de 3 y http://example.com/index.php?feed=rss le dice a WordPress que queremos el feed del sitio en formato RSS.

Desafortunadamente, esto nos puede dejar con URLs bastante feos:

http://example.com/index.php?post_type=portfolio&taxonomy=wordpress&portfolio=my-fancy-plugin

Aquí es donde interviene la reescritura de WordPress. Nos permite reemplazar lo anterior con:

http://example.com/portoflio/wordpress/my-fancy-plugin

Lo que ahora no solo es mucho más legible (y memorable) sino también más amigable para SEO. Esto es, en pocas palabras, lo que reescribe.

Como funciona?

Ahora http://example.com/portoflio/wordpress/my-fancy-plugin No existe como un directorio o un archivo. Entonces, ¿cómo sirve WordPress el contenido correcto? Cuando WordPress recibe un 'bonito enlace permanente' como el anterior, necesita convertirlo en algo que entienda, es decir, un objeto de consulta. Más simplemente, tiene que tomar la bonita URL y asignar las partes apropiadas a la variable de consulta correcta. Así que para nuestro ejemplo:

http://example.com/portoflio/wordpress/my-fancy-plugin

tipo de mensaje se establece en 'cartera'
cartera-taxonomía se establece en 'wordpress'
portafolio se establece en 'my-fancy-plugin' (el nombre de la publicación)

Entonces WordPress sabe que estamos detrás de publicaciones de tipo 'portafolio', en el 'wordpress"cartera-taxonomía'término taxonomía con nombre'my-fancy-plugin'. (Como habrás adivinado, los dos primeros son en realidad redundantes). WordPress luego realiza esa consulta, elige la plantilla apropiada con la cual mostrar los resultados y luego sirve eso al espectador. Pero claramente, WordPress no solo adivina cómo interpretar las URL, sino que debe ser dicho ...

Comienza con .htaccess

Suponiendo que puede y ha habilitado bastante enlaces permanentes en su página de Configuración -> Permalinks (consulte el Codex para conocer los requisitos mínimos) para WordPress en servidores Nginx, existe este complemento) - entonces las cosas comienzan con el .htaccess expediente. Juega un papel simple pero significativo. WordPress incluye algo similar a lo siguiente en este archivo:

 # COMENZAR WordPress  RewriteEngine On RewriteBase / RewriteRule ^ index \ .php $ - [L] RewriteCond% REQUEST_FILENAME! -F RewriteCond% REQUEST_FILENAME! -D RewriteRule. /index.php [L]  # FIN WordPress

Esto simplemente verifica si el archivo o directorio existe realmente, y si lo hace, simplemente lo llevan allí. Por ejemplo:

http://example.com/blog/wp-content/uploads/2012/04/my-picture.png

Simplemente te llevaría el archivo adjunto PNG 'my-picture.png'. Pero, como en el caso de:

http://example.com/blog/portoflio/wordpress/my-fancy-plugin

Donde el directorio no existe, lo llevan a su WordPress ' index.php expediente. Es este archivo el que arranca WordPress..

Interpretando la URL

En este punto, WordPress todavía no sabe lo que estás buscando. Después de una carga inicial de WordPress y su configuración, se dispara el parse_request método de la WP clase (ubicada en el clase-wp.php expediente). Es este método el que toma la / portoflio / wordpress / my-fancy-plugin y lo convierte en un objeto de consulta comprensible para WordPress (casi, en realidad establece el consultas_vares array y despues $ wp-> query_posts convierte esto en una consulta).

En resumen, esta función compara la URL recibida (/ portoflio / wordpress / my-fancy-plugin) con una matriz de 'expresiones regulares'. Este es el reescribir la matriz - y se verá algo como esto:

 category /(.+?)/ page /? ([0-9] 1,) /? $ => index.php? category_name = $ matches [1] & paged = $ matches [2] category /(.+ ?) /? $ => index.php? category_name = $ coincide con [1] tag / ([^ /] +) / page /? ([0-9] 1,) /? $ => index.php ? tag = $ coincide [1] & paged = $ coincide [2] tag / ([^ /] +) /? $ => index.php? = = $ match [1] ([0-9] 4) / ([0-9] 1,2) / ([0-9] 1,2) /? $ => Index.php? Year = $ coincidencias [1] y monthnum = $ coincidencias [2] y día = $ coincidencias [3] (. +?) (/ [0-9] +)? /? $ => index.php? pagename = $ coincidencias [1] & página = $ coincidencias [2]

Las claves de esta matriz son expresiones regulares y la URL recibida se compara con cada una de ellas hasta que coincida con el patrón de la URL recibida. El valor correspondiente es cómo se interpreta la URL. los $ partidos la matriz contiene los valores capturados (indexados de 1) de la coincidencia.

Por ejemplo, visitando www.example.com/blog/tag/my-tag, WordPress buscará el primer patrón que coincida 'etiqueta / my-tag'. Con la matriz anterior, coincide con el tercer patrón: etiqueta / ([^ /] +) /? $. Esto le dice a WordPress que interprete la URL como www.example.com/blog/index.php?tag=my-tag y en consecuencia el 'mi etiqueta'archivo está servido.

Por supuesto, WordPress le permite personalizar esta matriz, y el resto de este tutorial está dedicado a mostrarle cómo.

Personalizando las Reglas de Reescritura

Configuraciones -> Permalinks

Su primer puerto de llamada debe ser la página de configuración 'Permalink'. Esta página le permite alterar las reglas para el predeterminado 'enviar'tipo de publicación, y'categoría'y'etiquetas'taxonomías. La opción 'predeterminada' tiene bastante permalinks deshabilitados, pero puede seleccionar de una lista de estructuras preestablecidas o crear una estructura personalizada. Tenga en cuenta que las estructuras personalizadas no deben contener la URL de su sitio.. WordPress le permite modificar su estructura de enlace permanente agregando etiquetas provistas como %Nombre del puesto% (el nombre del post), %año% (el año en que se publicó el post) y %autor% (El autor del post). Una estructura de enlace permanente tal como:

/% año% /% autor% /% postname% /

Produciría un enlace de publicación como:

www.example.com/2012/stephen/my-post

La documentación de estas opciones se puede encontrar en el Códice de WordPress. (Más adelante te mostraré cómo crear tus propias etiquetas personalizadas).

Sin embargo, las opciones proporcionadas son bastante limitadas. En este tutorial me centraré en las funciones proporcionadas por WordPress que ofrecen un mayor control sobre las estructuras de enlace permanente y cómo se interpretan. No cubriré las opciones de reescritura disponibles para tipos de correos personalizados o taxonomías, ya que esto se tratará en la parte 2.

Por qué limpiar las reglas de reescritura?

Después de cualquier modificación de las reglas de reescritura (por ejemplo, utilizando uno de los siguientes métodos o registrando un tipo de publicación personalizado o taxonomía), es posible que las nuevas reglas no entren en vigor. Esto se debe a que necesita vaciar las reglas de reescritura. Esto se puede hacer de una de dos maneras:

Simplemente visite la página de Configuración -> Permalink
Llamada flush_rewrite_rules () (cubierto en la parte 2)

¿Qué hace esto? Recordar que el parse_request método compara la solicitud contra una matriz de reescritura. Esta matriz vive en la base de datos. El vaciado de las reglas de reescritura actualiza la base de datos para reflejar sus cambios, y hasta que lo haga, no se reconocerán. Pero parse_request además escribe al .htaccess expediente. Esto hace que sea una operación costosa. Entonces, aunque no cubriré el uso de flush_rewrite_rules () Hasta la parte 2, te daré esta advertencia: No llames flush_rewrite_rules en cada carga de la página. Los complementos solo deben llamar a esto cuando el complemento está activado y desactivado.

Añadir regla de reescritura

los add_rewrite_rule le permite agregar reglas adicionales a la matriz de reescritura. Esta función acepta tres argumentos:

regla - una expresión regular con la que comparar la URL de solicitud con
volver a escribir - La cadena de consulta utilizada para interpretar la regla. los $ partidos array contiene las coincidencias capturadas y comienza desde el índice '1'.
posición - 'parte superior'o'fondo'. Dónde colocar la regla: en la parte superior de la matriz de reescritura o en la parte inferior. WordPress escanea desde la parte superior de la matriz hasta la parte inferior y se detiene tan pronto como encuentra una coincidencia. Para que sus reglas tengan prioridad sobre las reglas existentes, querrá establecer esto en 'parte superior'. El valor predeterminado es 'fondo'.

Nota: si utiliza add_rewrite_rule varias veces, cada una con posiciónparte superior' - la primero La llamada tiene prioridad sobre las llamadas subsiguientes.

Supongamos que nuestras publicaciones tienen una fecha de evento asociada a ellos y queremos tener esta estructura: www.example.com/blog/the-olympics-begin/2012-07-27 interpretado como www.example.com/blog/index.php?postname=the-olympics-begin&eventdate=2012-07-27 Entonces podemos agregar esta regla de la siguiente manera:

 función wptuts_add_rewrite_rules () add_rewrite_rule ('^ ([^ /] *) / ([0-9] 4 - [0-9] 2 - [0-9] 2) /? $' / / String seguido de una barra, seguido de una fecha en el formulario '2012-04-21', seguido de otra barra 'index.php? Pagename = $ matches [1] & eventdate = $ matches [2]', 'top' );  add_action ('init', 'wptuts_add_rewrite_rules');

Lo siguiente interpretaría www.example.com/olympics/2012/rowing como www.example.com/index.php?p=17&olymyear=2012&game=rowing

 add_rewrite_rule ('^ olympics / ([0-9] 4) / ([^ /] *)', 'index.php? p = 17 & olymyear = $ matches [1] & game = $ matches [2]', ' parte superior' );

Si no está seguro de sus expresiones regulares, puede encontrar útil esta introducción y esta herramienta..

Añadir etiqueta de reescritura

Usted puede pensar que el valor de Fecha del evento (2012-07-27 en el ejemplo anterior), olymyear y juego Puede ser accesible desde los internos de WordPress a través de get_query_var (de la misma manera que get_query_var ('paginado') obtiene el número de página que está en). Sin embargo, WordPress no reconoce automáticamente la variable Fecha del evento a pesar de que se interpreta como una variable GET. Hay un par de maneras de hacer que WordPress reconozca variables personalizadas. Una es usar el consultas_vares filtre como se muestra en la sección 'Agregar punto final personalizado' a continuación. Alternativamente, podemos ir un paso más allá y usar add_rewrite_tag para registrar una etiqueta personalizada como la predeterminada %Nombre del puesto% y %año%

Esta función acepta tres argumentos:

nombre de etiqueta - (con% inicial y final) por ejemplo: %Fecha del evento%
expresiones regulares - Expresión regular para validar el valor, p. Ej. '([0-9] 4 - [0-9] 2 - [0-9] 2)'
consulta - (opcional) Cómo se interpreta la etiqueta, por ejemplo, 'eventdate ='. Si se proporciona, debe terminar con un '='.

 función wptuts_register_rewrite_tag () add_rewrite_tag ('% eventdate%', '([0-9] 4 - [0-9] 2 - [0-9] 2)');  add_action ('init', 'wptuts_register_rewrite_tag');

No solo lo hará get_query_var ('eventdate') devuelve el valor de la fecha en la URL, pero puedes usar la etiqueta %Fecha del evento% en la Configuración -> Enlace permanente (junto con el predeterminado %año%, %Nombre del puesto% etc.) y WordPress lo interpretará correctamente.. Desafortunadamente Al generar el enlace permanente de una publicación, WordPress no sabe cómo reemplazar %Fecha del evento% con el valor apropiado: para que nuestros post permalinks terminen como:

www.example.com/the-olympics-begin/%eventdate%

Necesitamos reemplazar %Fecha del evento% con un valor apropiado, y podemos hacerlo utilizando el post_link filtrar. (En este ejemplo, asumiré que el valor se almacena en un campo personalizado 'Fecha del evento').

 function wp_tuts_filter_post_link ($ permalink, $ post) // Compruebe si la etiqueta% eventdate% está presente en la url: if (false === strpos ($ permalink, '% eventdate%')) return $ permalink; // Obtener la fecha del evento almacenada en la publicación meta $ event_date = get_post_meta ($ post-> ID, 'eventdate', true); // Desafortunadamente, si no se encuentra una fecha, debemos proporcionar un 'valor predeterminado'. $ event_date = (! empty ($ event_date)? $ event_date: '2012-01-01'); $ event_date = urlencode ($ event_date); // Reemplace '% eventdate%' $ permalink = str_replace ('% eventdate%', $ event_date, $ permalink); devuelve $ permalink;  add_filter ('post_link', 'wp_tuts_filter_post_link', 10, 2);

En la parte 2 de esta serie, cubriré etiquetas personalizadas para tipos de correos personalizados.

Agregar punto final personalizado

Los puntos finales son etiquetas que se adjuntan a la URL (/ trackback / [valor] es el más común). Tiene varios otros usos potenciales: mostrar diferentes plantillas según el conjunto de valores, notificaciones personalizadas y mostrar publicaciones en diferentes 'formatos' (imprimible, XML, JSON, etc.).

Puede crear puntos finales con add_rewrite_endpoint. Esta función acepta dos argumentos:

nombre - El nombre del punto final, p. 'json','formar', etc.
dónde - Máscara de punto final que especifica dónde se debe agregar el punto final. Esta debe ser una de las constantes EP_ * enumeradas a continuación (o una combinación que use operadores a nivel de bits). Cuando registra tipos de publicación personalizados, puede crear una máscara para ese tipo de publicación:

Las máscaras de punto final predeterminadas son:

EP_PERMALINK - para post permalinks
EP_ATTACHMENT - para adjuntos
EP_DATE - para archivos de fecha
EP_YEAR - por año archivos
EP_MONTH - por mes archivos
EP_DAY - para archivos de 'día'
EP_ROOT - para la raíz del sitio
EP_COMENTOS - para comentarios
EP_SEARCH - para búsquedas
EP_CATEGORÍAS - para categorias
EP_TAGS - para etiquetas
EP_AUTHORS - para el archivo de publicaciones del autor
EP_PAGES - para paginas
EP_ALL - para todo

Los puntos finales son extremadamente flexibles, puede usarlos con operadores bitwise, por ejemplo, puede agregar un punto final a los enlaces de publicación y de página con EP_PERMALINK | EP_PAGES.

 función wptuts_add_endpoints () add_rewrite_endpoint ('myendpoint', EP_PERMALINK); // Agrega un punto final a los enlaces permanentes add_rewrite_endpoint ('anotherendpoint', EP_AUTHORS | EP_SEARCH); // Agrega el punto final a las URL para los autores o resultados de búsqueda add_action ('init', 'wptuts_add_endpoints');

Como un breve ejemplo, los puntos finales pueden ser útiles para los envíos de formularios. Supongamos que tenemos una página de formulario de contacto con nombre Formulario de contacto y con permalink: www.example.com/contact y quiere las URLs:

www.example.com/contact/submission/success - para reflejar una forma de presentación exitosa
www.example.com/contact/submission/error - para reflejar una presentación de formulario sin éxito

Esto se puede hacer con puntos finales. El siguiente es un ejemplo muy simple de cómo usar los puntos finales, por lo que el formulario es increíblemente básico en sus comprobaciones (y de hecho no hace nada con los datos). Normalmente, un formulario como este funcionaría mejor en un complemento, utilizando códigos cortos, pero a los efectos de este ejemplo, cree una página con la siguiente plantilla y el resto del código que puede poner en su funciones.php

  Mi formulario de contacto simple 
   Tu mensaje ha sido enviado! 
   Ups! Parece que ha habido un error ... 
     Tu mensaje:        Confirmación de correo electrónico:

(En caso de que se lo pregunte, la miel se está refiriendo a este método muy básico para atrapar el spam descrito aquí. Ciertamente no es infalible, pero el procesamiento adecuado de formularios y la protección contra el spam no está en este tema). Ahora creamos nuestro punto final:

 función wptuts_add_endpoint () add_rewrite_endpoint ('form', EP_PAGES);  add_action ('init', 'wptuts_add_endpoint');

A continuación añadimos nuestro 'formar'variable a la matriz de variables reconocidas:

 function wptuts_add_queryvars ($ query_vars) $ query_vars [] = 'form'; devuelve $ query_vars;  add_filter ('query_vars', 'wptuts_add_queryvars');

Finalmente, proporcionamos un controlador de formulario, que procesará los datos, enviará el formulario y, a continuación, redirigirá a la página de contacto con el valor de punto final relevante adjunto..

 function wptuts_form_handler () // ¿Queremos procesar el formulario si (! isset ($ _POST ['action']) || 'wptuts_send_message'! = $ _POST ['action']) devuelve; // ID de la página de formulario de contacto $ form_id = 2163; $ redirect = get_permalink ($ form_id); // Check nonces $ data = $ _POST ['wptuts_contact']; if (! isset ($ _ POST ['wptuts_contact_nonce']) ||! wp_verify_nonce ($ _ POST ['wptuts_contact_nonce'], 'wptuts_send_message')) // Failed nonce check check redirect. = 'form / error'; wp_redirect ($ redirect); salida();  si (! vacío ($ datos ['confirmación'])) // Abejas en la miel ... $ redirección. = 'forma / error'; wp_redirect ($ redirect); salida();  // Santificar y validar datos, etc. // Entonces, haga algo con los datos desinfectados // ¡Con éxito! $ redirect. = 'form / success'; wp_redirect ($ redirect); salida();  add_action ('init', 'wptuts_form_handler');

Por supuesto, incluso este ejemplo podría mejorarse enormemente al proporcionar mensajes de error más detallados que expresan el motivo del error.

Añadiendo un feed personalizado

Con los permalinks bonitos habilitados, WordPress genera automáticamente URL bonitas para el feed de su sitio: www.example.com/feed/rss. los add_feed La función le permite crear un feed personalizado, que si los enlaces permanentes están habilitados, también tendrá una URL "bonita". Esta función acepta dos argumentos:

nombre de la alimentación - El nombre del feed tal y como aparecerá en feed / [nombre del feed]
devolución de llamada de alimentación - La función encargada de visualizar los contenidos del feed..

Lo siguiente es un ejemplo de add_feed, y proporciona un feed personalizado muy básico.

 función wptuts_events_feed_callback () $ custom_feed = new WP_Query (array ('meta_key' => 'eventdate')); encabezado ('Content-Type:'. feed_content_type ('rss-http'). '; charset = ". get_option (" blog_charset'), true); eco ''; ?>   Mi feed personalizado     have_posts ()):?> have_posts ()): $ custom_feed-> the_post (); ?>  <?php the_title_rss() ?>    ]]>       Después de limpiar los permalinks, la alimentación estará disponible en www.example.com/feed/events.
 
 Comprobando las Reglas de Reescritura
 Una vez que haya agregado algunas de sus propias reglas de reescritura (y las haya borrado), probablemente querrá verificar si están funcionando correctamente y, si no lo están, averigüe qué está mal. Para esto, recomiendo el complemento Monkeyman Rewrite Analyzer, un complemento gratuito disponible en el repositorio de WordPress. Una vez activado, este complemento agrega una página a su sección 'Herramientas', que enumera todas sus reglas de reescritura.
  También puede probar las reglas dándole una URL de ejemplo, y el complemento filtrará las reglas para mostrar solo los patrones coincidentes e indicará cómo WordPress interpretaría la URL.
  Diviértete y mantente atento a la Parte 2, próximamente!
  Tenga en cuenta: hay un error actualmente en nuestro resaltador de sintaxis que muestra "vacío()" como "vacío ()". No te olvides de ajustar tu código en consecuencia.
 



		
			
	   
	




Código