() translation by (you can also view the original English article)
Hace unos artículos, ofrecí una introducción sobre Ajax en el escritorio de WordPress, pero los comentarios condujeron a una discusión sobre cómo hacer esto mismo en el frontend de WordPress (y cómo hacerlo de la manera correcta).
Recomiendo encarecidamente revisar la serie anterior para tener una idea de hacia dónde vamos, pero en este artículo, vamos a dar una visión general muy breve de lo que es Ajax, cómo funciona, cómo configurarlo en el frontend, y entender los ganchos que proporciona WordPress.
En el siguiente artículo, en realidad vamos a construir un pequeño proyecto que pone la teoría en práctica. Recorreremos el código fuente y también nos aseguraremos de que esté disponible en GitHub.
Mientras tanto, comencemos a revisar Ajax y las facilidades que nos proporciona WordPress.
Un recordatorio sobre Ajax
Actualmente, Ajax no es algo nuevo. De hecho, es difícil encontrar un sitio web y/o una aplicación web modernos que aún no lo incluya, así que iré al grano y seré breve.
En términos generales, Ajax es lo que nos permite hacer actualizaciones parciales de página.
Esto significa que podemos actualizar una parte (o partes) de una página sin que un usuario tenga que actualizar toda la página. El ciclo de vida suele ser algo como esto:
- Un usuario desencadena una acción en el sitio web. Tal vez hacen clic en un botón, hacen clic en un enlace, o algo similar.
- Sin que se actualizace la página, los datos se envían al servidor.
- El servidor procesa los datos y devuelve datos.
- A continuación, el sitio web maneja los datos devueltos (la respuesta) y actualiza la página en consecuencia.
Relativamente fácil de entender, ¿verdad?
Ajax en WordPress
Para entender este proceso en WordPress, necesitamos echar un vistazo a algunas ideas que son más concretas que "el usuario hace algo" y "actualiza la página en consecuencia."
Dicho esto, la mayoría de nosotros estamos familiarizados con las acciones, los filtros y el sistema de ganchos general de WordPress que nos permiten, ejem, enlazar al ciclo de vida de la página de WordPress para introducir nuestra propia funcionalidad o procesar datos antes de representarla. Si no, por favor revisa los ganchos de WordPress - tanto las acciones como los filtros - ya que esta serie asume que tienes cierto nivel de familiaridad con ambos.
La introducción de Ajax en WordPress sigue un proceso de tres pasos. Es literalmente una receta que se puede seguir cada vez que desees introducir una acción asíncrona.
Antes de mirar dicha receta, permitidme definir un par de términos para los principiantes y para aquellos de vosotros que estéis familiarizándoos con Ajax:
- Evento: Esto significa que algo ha sucedido. Literalmente, podría significar que el usuario ha redimensionado la ventana del navegador, el usuario escribió algo en un campo de entrada o el hizo clic sobre un elemento.
- Solicitud: esto es lo que el navegador envía al servidor. Esto puede contener un conjunto de datos que el servidor necesita procesar; de lo contrario, puede ser sólo una señal de que el usuario activó un evento.
- Controlador de eventos: es una función que responde cuándo algo ha ocurrido. Normalmente se trata de una función que reside en el servidor y procesa los datos enviados una vez que se ha desencadenado el evento anterior.
- Respuesta: son los datos que el controlador de eventos devuelve al explorador y que se usan para actualizar la página.
Dicho esto, aquí está la receta que se utiliza para formular una solicitud Ajax en el contexto de WordPress (tanto en el escritorio como en los temas o en el frontend):
- Introducir un elemento en el que el usuario hará clic y configurará un controlador de eventos mediante JavaScript para enviar la solicitud.
- Definir el controlador de eventos en tu archivo functions.php si estás trabajando con un tema o en tu archivo plugin.php si estás trabajando con un plugin.
- Escribir JavaScript para controlar la respuesta del controlador de eventos.
Acciones y filtros requeridos
Para aquellos de vosotros que leísteis mi serie anterior sobre Ajax en el escritorio o que estéis familiarizados con Ajax en WordPress, es probable que ya estéis familiarizados con los archivos y ganchos necesarios para implementar Ajax.
En concreto:
-
ajaxurles la URL proporcionada por WordPress a la que enviamos nuestra solicitud. -
wp_ajax_my_actiones el gancho que usamos para conectar nuestro controlador de eventos.
Para obtener una actualización completa, asegúrate de consultar el proyecto en GitHub.
Implementar Ajax en el lado público es muy similar, pero requiere dos cosas:
- Importar la biblioteca Ajax de WordPress
- Dos ganchos, uno de los cuales es el mismo que se mencionó anteriormente.
En el siguiente artículo, pasaremos un tiempo explicando cómo importar la biblioteca Ajax de WordPress y cómo aprovecharla, pero lo crucial a comprender en el resto del artículo son los dos ganchos necesarios para configurar nuestros controladores de eventos.
El gancho wp_ajax_my_action
El gancho wp_ajax_my_action es el mismo que usamos cuando trabajamos con Ajax en el escritorio. Nos permite proporcionar acciones habilitadas para Ajax a los usuarios que hayan iniciado sesión en WordPress.
Esto significa que usarías este gancho si deseases introducir la funcionalidad de Ajax a usuarios que sean administradores, editores, colaboradores o miembros de un sitio.
Recuerda que no declaras wp_ajax_my_action exactamente como está. En su lugar, el sufijo 'my_action' debe reemplazarse por el nombre del método. Así que si tienes una función con la firma:
1 |
function my_custom_handler() { |
2 |
} // end my_custom_handler |
Después el gancho correspondiente se vería así:
1 |
function my_custom_handler() { |
2 |
} // end my_custom_handler |
3 |
add_action( 'wp_ajax_my_custom_handler', 'my_custom_handler' ); |
Por supuesto, no siempre es ideal restringir la funcionalidad a los usuarios que hayan iniciado sesión en el sitio web.
El gancho wp_ajax_nopriv_my_action
El gancho wp_ajax_nopriv_my_action es muy similar al gancho de wp_ajax_my_action excepto en una cosa:
Usarías este gancho si deseases introducir la funcionalidad Ajax a los usuarios sin necesidad de que hayan iniciado sesión en el sitio.
Funciona exactamente de la misma manera y está sujeto exactamente a las mismas reglas, excepto en su "público objetivo", por así decirlo. Esto significa que puedes definir tus funciones de la siguiente manera:
1 |
function my_custom_handler() { |
2 |
} // end theme_custom_handler |
3 |
add_action( 'wp_ajax_nopriv_my_custom_handler', 'my_custom_handler' ); |
Simple, ¿verdad?
Pero aquí hay un problema de seguridad: Debido a que estás abriendo ciertas funciones a los usuarios que no hayan iniciado sesión, las características de seguridad clave como los valores únicos no funcionarán necesariamente, por lo que debes ser muy selectivo en relación a lo que vas a permitir que las personas hagan si no están conectadas al sitio.
Como regla general, siempre digo que los usuarios que no hayan iniciado sesión en el sitio no deben tener acceso para modificar, es decir, cambiar, actualizar, eliminar o añadir, cualquier dato al sitio. Sí, es un poco restrictivo, pero se trata de los datos de su blog, sitio o aplicación.
¿Por qué sacrificar esto?
Un ejemplo de trabajo
En la siguiente artículo, vamos a echar un vistazo a un ejemplo de trabajo que permitirá a los usuarios que hayan iniciado sesión en el sitio web marcar las entradas que han leído.
Mientras tanto, asegúrate de ponerte al día con los siguientes artículos, ya que te ayudarán a consolidar el próximo artículo:
