¿Qué hace exactamente la máscara ep en la función de taxonomía de registro de wordpress?

3 minutos de lectura

avatar de usuario
Mohamed Omar

Estoy registrando una taxonomía personalizada para mi blog usando la función register_taxonomy que tiene un argumento rewrite

para reescribir las URL usando algunos parámetros

uno de ellos es ep_mask . WordPress afirma que debe usarse cuando desea agregar un punto final para la URL de taxonomía. Simplemente no entiendo por qué agregar un punto final y cuál es su beneficio. Por favor, si hay un ejemplo con un resultado disponible, será mejor.

Gracias por adelantado

El valor de la máscara de punto final se usa para decirle a WordPress qué tipo de adiciones de punto final admite un determinado elemento registrado, y a las que un desarrollador puede agregar puntos finales a través de add_rewrite_endpoint().

Por defecto, las taxonomías (que yo sepa) no ofrecen ep_mask (predeterminado en EP_NONE), pero para taxonomías personalizadas puede usar una máscara EP personalizada o una de las integradas (p. ej. EP_PAGES) para hacer que la estructura de enlace permanente funcione de manera similar a otra cosa.

Suponiendo que establezca el ep_mask valor a EP_PERMALINK | EP_PAGESluego podría registrar un nuevo punto final usando

add_rewrite_endpoint('json', EP_PERMALINK | EP_PAGES);

Lo que a su vez le permitiría agregar el sufijo de las URL de su taxonomía con json y el valor json estaría disponible como una variable de consulta en $wp_query. Luego puede usar el valor como una verificación para modificar la consulta, las plantillas y otras cosas relacionadas cuando se carga la página.

Puede leer más sobre puntos finales aquí: https://make.wordpress.org/plugins/2012/06/07/rewrite-endpoints-api/ (Un poco antiguo, pero aún debe reflejar cómo funciona el núcleo con los puntos finales).

  • Entiendo la declaración literalmente, pero no puedo imaginar qué sucede exactamente cuando, por ejemplo, usé EP_DATE, con mi taxonomía registrada. . Por favor, necesito un ejemplo con un antes y un después de los resultados si puede

    – Mohamed Omar

    06/09/2016 a las 20:37

  • EP_DATE, EP_PAGES y así sucesivamente son constantes que se refieren a valores enteros. Antes de aplicar la máscara EP, sus URL de impuestos funcionarán normalmente, pero agregando una variable de consulta (por ejemplo, json) dará como resultado un 404 (ya que WP no sabe qué hacer con dicha estructura de URL), pero después de agregar la máscara EP, puede asignar el punto final y WP no arrojará errores por elementos adicionales en la URL. Si utiliza EP_DATE, todos los puntos finales registrados para esa máscara EP estarían disponibles en las estructuras de URL de la taxonomía. Intentaré escribir un mejor ejemplo pronto si tengo tiempo.

    – ojrask

    7 sep 2016 a las 7:51

  • Pero si agregué el json, ahora debería tener ambos enlaces disponibles como www.example.com/custom-taxonomy/ y www.example.com/custom-taxonomy/json/ y ambos funcionarán sin problemas

    – Mohamed Omar

    7 sep 2016 a las 8:47

  • Sí, ambos funcionarían como el otro. pero con el json versión, podría crear algunas alteraciones en el complemento o el código del tema cuando sea necesario.

    – ojrask

    9 de septiembre de 2016 a las 11:28

  • add_rewrite_endpointno add_rewrite_rule. De lo contrario, esa es la forma en que debería funcionar, sí. 🙂

    – ojrask

    12 de septiembre de 2016 a las 9:59

El beneficio es que puede usar el punto final con bonitos enlaces permanentes.

Si no especifica EP_MASK, los enlaces permanentes bonitos no funcionarán

los descripción de ep_mask en la documentación de register_taxonomy() contiene una enlace a un artículo que lo explica en detalle.

Una cita de ese artículo:

Si quisiéramos agregar nuestro punto final a todos los enlaces permanentes de publicaciones, usaríamos EP_PERMALINK. Tanto para publicaciones como para páginas: EP_PERMALINK | EP_PAGES. Para publicaciones, páginas y categorías: EP_PERMALINK | EP_PAGES | EP_CATEGORIES.

Hay ejemplos específicos en ese artículo:
https://make.wordpress.org/plugins/2012/06/07/rewrite-endpoints-api/

¿Ha sido útil esta solución?