La diferencia fundamental es:
- El
add_rewrite_rule()
añade una regla particular que se interpreta
- El
add_rewrite_tag()
añade un marcador de posición para su uso en estructuras de URL. Este marcador de posición se usa para generar múltiples reglas.
Por ejemplo, suponga que es un agente de viajes que anuncia hoteles en varios países. Es posible que desee que la url de un hotel sea como
www.example.com/hotels/UK/Balmoral
Donde el país (Reino Unido en este ejemplo) es un término de taxomonía personalizado y Balmoral es un hotel (tipo de publicación). Podríamos agregar reglas de reescritura para esto, pero luego tendríamos que generar una regla para:
- el hotel en sí
- los archivos adjuntos del hotel
- Una regla para hoteles (publicaciones) donde se extiende por varias páginas, etc.
Generar estas reglas puede volverse complicado. Además, probablemente competiremos con las propias reglas de WordPress para ese tipo de publicación, generadas a partir de la estructura permanente que establecemos al registrar el tipo de publicación. (En cualquier caso, deje que WordPress haga el trabajo).
Esta 'permastructura', similar a lo que establece para las publicaciones en la configuración de enlaces permanentes, determina las reglas de reescritura que genera WordPress. Pero dado que queremos una estructura que contenga algo desconocido (el país), que queremos interpretar, debemos proporcionar un marcador de posición del formulario %country%
. (Es casi idéntico a las %category%
publicaciones).
Por ejemplo:
add_action_init('init','wpse71305_register_types');
function wpse71305_register_types(){
//You'll need to register the country taxonomy here too.
//Add 'country' tag.
add_rewrite_tag('%country%', '([^&/]+)'));
//Register hotel post type with %country$ tag
$args = array(
...
'has_archive'=>true,
'rewrite' => array(
'slug'=>'hotels/%country%',
'with_front'=> false,
'feed'=> true,
'pages'=> true
)
...
);
register_post_type('hotel',$args);
}
Nota: WordPress no sabe cómo generar la URL desde%country%
etiqueta; debe indicarle que haga eso. (Cubro esto en un artículo que he vinculado a continuación).
Finalmente, WordPress también almacenará el valor coincidente para que pueda recuperarlo a través de get_query_var()
(algo que no lo hace con una regla de reescritura estándar).
También puede crear etiquetas para usar en la estructura permanente de las publicaciones (configúrelo en la página de configuración de Enlace permanente).
Al agregar una etiqueta, podemos usarla en permastructures. WordPress entonces sabe
- Que esperar
- Cómo interpretar la url (verifique que coincida)
- Cómo interpretar el valor (es decir, 'Reino Unido')
(Como referencia, vea este artículo que escribí: http://wp.tutsplus.com/tutorials/creative-coding/the-rewrite-api-the-basics/ ).
Editar
Como se señaló en los comentarios, el ejemplo anterior es pobre, como register_taxonomy()
de hecho llamaadd_rewrite_tag()
.
Con respecto a la documentación del Codex sobre su uso 'en combinación': esto puede ser engañoso, ya que ambos se pueden usar de forma independiente. Sin embargo, como se señaló anteriormente, add_rewrite_tag()
agrega el nombre de la etiqueta a las "variables de consulta" de WordPress. En la práctica, esto le permite recuperar el valor con get_query_var()
. Por lo tanto, cuando add_rewrite_rule()
se usa con add_rewrite_tag()
, la variable será almacenada por WordPress. Pero hay otras formas de hacerlo (vea esta respuesta ; tenga en cuenta también el comentario de Rob Vermeer).
También relacionado: ¿Cómo recuperar variables $ _GET de URL reescritas?
add_rewrite_tag()
se puede usar para hacer marcadores de posición para usarSettings->Permalinks
. Sobre el uso de una taxonomía, ¿es un requisito para usaradd_rewrite_tag()
? Mi impresión de la página Codex es que no lo es, pero parece que se usa comúnmente. Expandí mi pregunta con respecto al usoadd_rewrite_tag()
en conjunto conadd_rewrite_rule()
lo sugerido en la página del Codex .