Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. WordPress

Técnicas Ajax Mejoradas para WordPress: Programación por Procedimientos

by
Difficulty:IntermediateLength:LongLanguages:

Spanish (Español) translation by Nadia Castelli (you can also view the original English article)

Algunos años atrás, escribí una serie de posts discutiendo cómo usar Ajax en el Frontend de WordPress. El propósito de estas series es simple:

Vamos a dar una idea muy breve de lo que es Ajax, cómo funciona, cómo configurarlo, y un entendimiento de los ganchos (hooks) que provee WordPress. Además construiremos un pequeño proyecto para poner en práctica la teoría. Avanzaremos a lo largo del código fuente, y nos aseguraremos de que esté disponible en GitHub.

Hablando en general, esta serie está bien sustentada, pero como sucede con todo el software bajo desarrollo constante, las técnicas, APIs, y enfoques cambian. Además, a medida que los años van pasando y vamos refinando nuestras habilidades, nos hacemos mejores desarrollando y empleando nuevas APIs.

Debido a lo expuesto arriba, quisiera repasar el concepto de Ajax en WordPress para que puedas ver algunas de las nuevas APIs y cómo utilizarlas en tu trabajo diario, o cómo refactorizar el código en el que estés trabajando.

Una precaución a tener en cuenta antes de ahondar en este tutorial: asumo que ya has leído la serie linkeada en la introducción de este artículo, y que tienes algo de experiencia con el desarrollo de plugins para WordPress.

Definiendo el Plugin

Como con cualquier plugin para WordPress, es importante que te asegures de definir el header para que WordPress pueda leer el archivo, con el fin de introducir la nueva funcionalidad en la aplicación principal.

Estoy utilizando esta variación del plugin Simple Ajax Demo, ubicado en wp-content/plugin/wp-simple-ajax El primer archivo que estoy creando reside en el directorio raíz de wp-simple-ajax, y se denomina wp-simple-ajax.php.

Se ve así:

Este código debería darse a entender por sí mismo, especialmente si estás acostumbrado a trabajar con plugins de WordPress; sin embargo, lo más importante de entender es que toda la información que contiene es lo que luego verá el usuario en el panel de WordPress.

Es decir, los usuarios verán nombre, descripción, y versión del plugin, así como también el nombre del autor (linkeado a la URL especificada), cuando se les presente la opción del activar el plugin.

Agregando el Archivo Ajax de WordPress

En este punto, el plugin aparecerá en el panel de Plugins de WordPress, pero no hará nada, porque no hemos escrito código aún. Para que esto suceda, encararemos este plugin en particular utilizando el paradigma de programación por procedimientos en lugar del orientado a objetos que he usado en la mayoría de mis tutoriales.

Cómo Agregábamos Ajax Originalmente

Los motivos para evitar la programación orientada a objetos en este momento son dos:

  1. El plugin va a ser muy simple. Estoy más interesado en hacer hincapié en las APIs específicas provistas por WordPress para que puedas enfocarte en los aspectos más importantes de tu trabajo.
  2. La segunda parte de esta serie se enfocará en migrar este código hacia un sistema orientado a objetos, para que puedas ver cómo luce todo esto en el contexto de un sistema más grande que utilice clases.

Básicamente, este serie abarcará ambos tipos de programación soportados por PHP y WordPress.

Si has trabajado con Ajax en el pasado, es probable que hayas hecho algo así para darle a tu plugin soporte para llamadas asíncronas:

Este método en particular no es inherentemente incorrecto, pero no saca provecho de algunas de las APIs más nuevas que mostraré ahora. Además mezcla PHP, HTML, y JavaScript todo en una única función.

Cumple su función, pero existe una forma más prolija de hacerlo.

Cómo Agregamos Ajax

Primero, para asegurarnos que el plugin no pueda ser accedido directamente por nadie, agrega el siguiente condicional justo debajo del header del plugin:

Notarás que la etiqueta PHP no será necesaria ya que este código estará en un archivo PHP preexistente más tarde (aunque ahora es necesaria para el resaltado de sintaxis).

Ahora, escribamos una función para añadir soporte Ajax mediante el uso de algunas de las APIs existentes que no implican la mezcla de lenguajes.

Esto es lo que tenemos que hacer:

  1. Vamos a crear una función responsable de agregar soporte Ajax.
  2. Engancharemos la función a la acción wp_enqueue_script.
  3. Tomaremos ventaja de la API wp_localize_script para encolar el soporte a Ajax de WordPress (que viene de admin-ajax.php).

Parece ser bastante directo, ¿no? Si tienes alguna pregunta, siempre puedes consultar en los comentarios. Chequea el siguiente código para ver si puedes seguirlo:

Nuevamente, notarás que la etiqueta PHP inicial no será necesaria en la versión final de este plugin, ya que ahora está solamente para resaltar la sintaxis.

Dicho esto, echemos un vistazo a wp_localize_script. Antes de examinar cada parámetro, recordemos el propósito de esta función. Según el Codex, la versión corta es la siguiente:

Localiza un script registrado con datos para una variable JavaScript.

Sin embargo, la descripción más larga es importante:

Esto te permite ofrecer traducciones correctamente localizadas de cualquier string utilizada en tu script. Esto es necesario porque WordPress actualmente sólo ofrece una API de localización en PHP, no directamente en JavaScript.
Aunque la localización es el uso primario, puede emplearse para hacer que cualquier dato que normalmente sólo puedes obtener del lado servidor de WordPress esté disponible en tu script.

Ahora veamos los parámetros que acepta:

  1. El primer parámetro se refiere al handle y se utiliza como identificador único del script que está siendo agregado.
  2. El segundo parámetro es name, y es importante ya que indentifica al script a lo largo del código. Verás esto con mucho más detalle más avanzado el tutorial.
  3. El tercer parámetro es data. Se refiere a un array que se enviará al navegador como un objeto JavaScript. Como estamos pasando la URL de una ruta a un archivo, proveeremos soporte Ajax.

Notarás que el primer parámetro es ajax-script. Ten esto en mente cuando nos dediquemos a escribir y encolar nuestro propio JavaScript, ya que utilizaremos este handle una vez más.

También debes recordar el nombre que has seleccionado para tu llamada a la API, ya que también lo usaremos cuando trabajemos con el código lado cliente más adelante.

Nota Importante Sobre Soporte Ajax

Ten en cuenta que sólo estamos usando el gancho (hook) wp_enqueue_script y no admin_enqueue_script. Esto es porque ajaxurl ya está previamente definida en el dashboard.

Esto significa que si quieres hacer peticiones Ajax en el área administrativa de WordPress, no tienes que encolar nada. Todo lo que estamos haciendo en el contexto de este tutorial es específicamente para el front-end del sitio web.

Seteando Tu Código Server-Side

Ahora es momento de escribir una función que tu JavaScript llame vía Ajax. Esto puede ser lo que tú quieras, pero para el propósito de este plugin escribiremos una función que devuelva información acerca del usuario logueado en el sitio.

El plugin hará lo siguiente:

  • Hacer una petición al servidor, pidiendo información acerca del usuario actual.
  • Si el usuario está logueado en el sitio, retornará una respuesta JSON de su información.
  • Si el usuario no está logueado, retornará un código de error.

Usaremos el objeto console disponible en la mayoría de los navegadores modernos, así que asegúrate de utilizar Chrome, Safari, o Firefox cuando tranajes con el JavaScript que escribirás.

Haciendo la Petición

Ahora que hemos descrito exactamente cómo se comportará el código cada vez que un usuario haga una petición Ajax al servidor, comencemos a escribir una función para hacerlo. La llamaremos sa_get_user_information.

La implementación de esta función vendrá más adelante en este tutorial, pero lo primero en que hay que fijarse del código anterior es que nos hemos enganchado a wp_ajax_get_current_user_info y wp_ajax_nopriv_get_current_user_info.

Estos dos ganchos están bien documentados en el Codex, pero el primer gancho permitirá acceder a esta función a aquellos logueados en el sitio. El segundo gancho permitirá acceder a esta función a aquellos no logueados.

Además, fíjate que todo lo que le digue a wp_ajax_ y wp_ajax_nopriv_ queda libre a definición de tu parte, el desarrollador. Este será el nombre de la función que llames del lado cliente, como verás más adelante.

Manejando Peticiones Erróneas

Antes de implementar la función, el archivo fuente JavaScript (que aún no escribimos) ha sido llamado, y debemos asegurarnos de poder manejar los errores que puedan ocurrir.

En nuestro caso, los errores potenciales serían:

  1. Nadie está logueado.
  2. El ID de usuario no existe en el sistema.

Es altamente improbable que el segundo caso ocurra, pero nos ayudará a aprender más acerca de las APIs de WordPress y cómo podemos aprovecharlas para manejar peticiones erróneas.

Lo primero a entender es WP_Error. Como muchas otras APIs, está disponible en el Codex:

Las instancias de WP_Error almacenan códigos y mensajes de error que representan uno o más errores, y para determinar si una variable es o no una instancia de WP_Error puede usarse la función is_wp_error().

El constructor acepta hasta tres parámetros (aunque solamente usaremos los dos primeros):

  1. El primer argumento es el código de error. Esto es lo que utilzaremos del lado cliente para determinar qué ha fallado. Además nos permite escribir información a un archivo log, entre otras cosas.
  2. El segundo argumento es un mensaje que puede acompañar al código de error. Esto es útil si deseamos mostrar un mensaje al usuario.
  3. El argumento final es un array de información, por lo general códigos y mensajes de error. De todas formas, no lo utilizaremos en nuestro código.

Ahora, enviaremos los resultados de los errores de vuelta al cliente mediante una función llamada wp_send_json_error. Es muy sencilla de usar:

Envía una respuesta JSON de vuelta a una petición Ajax, indicando error. El objeto de respuesta siempre contendrá una clave success con valor falso. Si a la función se le pasa algo en el parámetro $data, será tomado como el valor para una clave data.

Combinando WP_Error y wp_send_json_error, podemos crear funciones que nos ayuden a proveer códigos de error al JavaScript que llama al lado servidor.

Por ejemplo, supongamos que tenemos una función que devuelve error si el usuario no está logueado en el sitio. Esto puede lograrse utilizando la siguiente función:

Debes notar que la función está definida como privada aún cuando existe en el contexto global. Lleva un guión bajo como prefijo para denotar que esta función debe ser considerada privada.

Repasaremos esto en el próximo artículo.

Segundo, necesitamos manejar el caso en que el usuario no existe. Para hacerlo, podemos crear una función que haga lo siguiente:

Ahora tenemos dos funciones; cada una de ellas devolverá información al cliente si halgo falla, ¿pero qué hacemos si no falla ninguna de ellas?

Manejando Peticiones Exitosas

Si las funciones anteriores no retornan errores, tenemos que hallar una manera de regresar la respuesta al cliente con un mensaje de éxito y la información solicitada.

Concretamente, tenemos que devolver al cliente la información que contiene la información del usuario actual en formato JSON.

Para esto, podemos valernos del mensaje wp_send_json_success. Hace exactamente lo que tú piensas:

Retorna una respuesta JSON a una petición Ajax, indicando éxito. El objeto respuesta siempre contendrá una clave success con valor verdadero. Si se le pasa algún parámetro a la función será tomado como el valor para una clave data.

Combinemos el trabajo que hemos realizado para escribir una función que el JavaScript eventualmente llamará, y que haga uso de las dos funciones más pequeñas que hemos indicado arriba. De hecho, esta será la implementación de la función que hemos excluido antes de este tutorial:

Si el usuario existe y está logueado, enviaremos un mensaje de éxito al cliente que contiene la representación JSON del mismo. En este punto, es hora de escribir un poco de JavaScript.

La Petición Lado Cliente

Primero, agrega un archivo llamado frontend.js al directorio raíz de tu plugin. En principio, debería contener el siguiente código:

Veremos la implementación de la función en un momento, pero antes tenemos que asegurarnos de encolar este archivo JavaScript en el plugin. Regresa a la función sa_add_ajax_support y agrega lo siguiente antes de la llamada a wp_localize_script:

Recuerda que este script debe tener el mismo handle definido en wp_localize_script. Ahora podemos volver a nuestro archivo JavScript y hacer una llamada al código de lado servidor que hemos trabajado a lo largo de este artículo.

En frontend.js, agrega lo siguiente:

Dada la cantidad de comentarios en el código y asumiendo que estás familiarizado con los plugins de WordPress y tienes algo de experiencia en Ajax, debería ser relativamente fácil de seguir.

En resumen, el código anterior realiza una llamada al servidor cuando la página se carga y luego muestra información sobre el usuario en la consola del navegador.

Si hay un usuario logueado, sus datos se imprimen en la consola en forma de un objeto JavaScript, ya que está siendo parseado desde un JSON.

Si, por el contrario, el usuario no está logueado, entonces se muestra otro objeto que muestra un código de error junto con un mensaje, lo que podrás ver en la consola.

Conclusión

Por ahora, deberías tener buen entendimiento de las APIs que presenta WordPress para trabajar con peticiones Ajax, tanto para usuarios autenticados como no.

Nuestro propósito final será escribir el código más limpio y mantenible posible, para así ser capaces de seguir trabajándolo en el futuro. Adicionalmente, deberíamos escribir el código de esta manera, para que otros desarrolladores que pudieran utilizarlo comprendan qué intentamos hacer y utilicen las mejores prácticas para nuestro entorno.

En este tutorial, utilicé el paradigma de programación por procedimientos para todo el código compartido, demostrado y subido a GitHub. Como mencioné antes, no hay nada inherentemente malo en esto, pero pienso que vale la pena que veas cómo luce esto desde una perspectiva orientada a objetos.

En el próximo tutorial, migraremos este código al paradigma orientado a objetos que además emplee los Estándares de Código de WordPress para documentar aún más nuestro código, y que utilice una organización prolija de archivos, para que sea lo más limpio y claro posible.

Recuerda, puedes ver todos mis cursos y tutoriales en mi perfil, y puedes seguirme en mi blog y/o Twitter (@tommcfarlin), donde escribo sobre desarrollo de software en el contexto de WordPress, y disfruto de conversar con otros acerca de los mismo temas (así como otras cosas).

Mientras tanto, por favor no dudes en dejar preguntas o comentarios en el espacio debajo, e intentaré responder cada una de ellas.

¡Sé el primero en conocer las nuevas traducciones–sigue @tutsplus_es en Twitter!

Advertisement
Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.