Desarrollo de plugins con WordPress Boilerplates: Por qué son importantes los Boilerplates

A lo largo de los últimos cinco a diez años, la construcción de sitios y aplicaciones para la web se ha vuelto mucho más compleja que gran parte de las cosas que la gente construía en los años 90. Hace mucho que han pasado los tiempos en los que se creaban sitios manualmente usando HTML en mayúsculas, diseños basados en tablas y horroroso JavaScript para crear algún tipo de bonita animación en una página.

Ahora tenemos una variedad de tecnologías, frameworks y lenguajes, todos los cuales trabajan juntos para ayudarnos a construir completamente aplicaciones de software que se ejecutan dentro de un navegador.

Es un momento increíble para ser un desarrollador.

Debido a que hay tantas tecnologías diferentes con las que podemos trabajar, los boilerplates son cada vez más populares. Para aquellos que estéis familiarizados, los boilerplates son básicamente código fundacional que ayuda a los desarrolladores a iniciar proyectos sin tener que escribir código o ciertos componentes que son comunes en todos los sitios o aplicaciones.

Por supuesto, se pueden ampliar hasta el punto de ser más voluminosos y más complicados de lo necesario, pero todos los que son buenos están destinados a sentar las bases, es decir, a proporcionar una especie de andamiaje para ayudarte a que te centres en la escritura de tus algoritmos principales, tu código y tus funciones, todo aquello que es único en tus proyectos y necesidades.

Hace más de un año, comencé a trabajar en dos proyectos, el WordPress Plugin Boilerplate y el WordPress Widget Boilerplate, cada uno de los cuales tiene como objetivo proporcionar una base a partir de la cual los desarrolladores puedan construir plugins usando las mejores prácticas de WordPress. Afortunadamente, los proyectos han recibido una serie de otras contribuciones de la comunidad de código abierto para ayudar a que sean lo más sólidos posible.

Uno de los aspectos del mantenimiento de estos proyectos es que a menudo recibo preguntas de por qué he establecido las cosas tal y como lo he hecho. Así que en esta serie de dos partes, vamos a examinar los Boilerplates, las razones (y ventajas) de organizarlos de la manera en la que lo he hecho, y luego construiremos un sencillo plugin usando uno de estos Boilerplates para dar un ejemplo de cómo usarlos en tus proyectos futuros.

Organización de archivos

Uno de los componentes clave de la creación de cualquier aplicación de software, independientemente de lo grande o lo pequeño que sea, es cómo se organiza el programa. Esto no se limita solo a cómo se relacionan las clases y/o funciones (ese es un tema para otro artículo), sino también cómo se organizan los archivos.

Idealmente, los archivos no deben ser simplemente volcados en un directorio y luego dejados para que otros desarrolladores se cuelen con el fin de mantener el proyecto. En su lugar, deben estar organizados lógicamente en directorios coherentes, claramente, no inteligentemente, nombrados, y deben requerir a cualquier desarrollador que esté contribuyendo al proyecto muy poco esfuerzo para entender dónde se encuentran ciertos archivos y dónde poner sus propias aportaciones.

Es como el viejo adagio:

Un lugar para cada cosa y todo en su lugar.

Al crear ambos los Boilerplates, no sólo traté de seguir este principio en particular, sino que también traté de seguir la inspiración de cómo Ruby on Rails modela su diseño. Específicamente, favorecen la "convención sobre la configuración".

Obviamente, WordPress no es Rails, ni es un framework MVC, ni estoy tratando de hacer que lo sea. Simplemente estoy tratando de tomar prestadas buenas ideas de otros desarrolladores con el fin de hacer nuestras vidas un poco más fáciles en el contexto de nuestro entorno.

Archivo principal del plugin

Independientemente de lo simple o complejo que sea tu plugin, debes incluir al menos un solo archivo PHP. Este archivo sirve como el archivo de plugin principal donde todo el código, la lógica y la funcionalidad que dan vida a tu plugin están contenidos.

Si miras a través del espectro de plugins, notarás que los desarrolladores tienen diferentes prácticas:

• Algunos incluyen todo en un solo archivo
• Algunos dividen la funcionalidad relacionada en archivos separados y utilizan el archivo principal del plugin simplemente para incluir cada uno de ellos
• Algunos separan parte del código front-end del código del lado del servidor

No estoy aquí para debatir el por qué cualquiera de estos métodos (incluso los mencionados) es mejores que los otros; por qué los Boilerplates están dispuestos en la forma en que lo están y cómo pueden funcionar para ti.

La página de inicio del plugin basada en el archivo README.

Además de un archivo de plugin principal, los plugins de WordPress requieren un archivo README con el fin de proporcionar al usuario final algunas instrucciones sobre cómo utilizar el plugin, y para además, cumplimentar la página en el repositorio de plugins de WordPress.

En el nivel más básico, esto es todo lo que se requiere de un plugin de WordPress: un archivo de plugin principal y un archivo README. Puedes salirte con la tuya y construir con éxito algunos plugins significativamente complejos usando solo estos dos archivos; sin embargo, podrían llegar a ser increíblemente difíciles de mantener, especialmente si otros desarrolladores comienzan a contribuir, lo que en última instancia podría resultar en errores no deseados.

Por tanto, soy un gran fan de separar lógicamente los componentes del código.

Vistas

Vistas es una palabra que tomé prestada del patrón MVC (además de inspirarme en Rails).

Las vistas se pueden definir como el marcado de front-end que representa elementos en la pantalla tanto para los administradores como para los visitantes del sitio.

Es todo. Sencillo, ¿verdad?

Claro, debido a que estamos trabajando en PHP, estamos obligados a que haya etiquetas PHP menores colocadas en todo el código, pero gran parte de un archivo de vista debe estar constituido por HTML con atributos de clase e ID.

Dentro de los Boilerplates, hay dos vistas:

1. admin.php es la vista que se utiliza para representar los elementos para los usuarios en el escritorio
2. widget.php o plugin.php es la vista que se utiliza para representar los elementos para los visitantes del sitio

Naturalmente, los plugins pueden no tener una vista para el escritorio o para los visitantes del sitio. En ese caso, el directorio views se eliminaría y el código responsable de incluirlos dentro del archivo de plugin principal también sería eliminado.

Hojas de estilo

Este es un componente trivial de los Boilerplates como cualquier persona que hace cualquier tipo de desarrollo frontend ya sabe cómo administrar hojas de estilo y probablemente tiene su propio enfoque para organizarlas.

Pero para ser consistentes, vale la pena mencionar que el directorio css es donde se guardan todas las hojas de estilo. Los archivos también siguen la misma convención de nomenclatura que sus correspondientes vistas asociadas.

Concretamente

1. admin.css es la vista que se utiliza para aplicar estilo a los elementos de los usuarios en el escritorio
2. widget.css o plugin.css es la vista que se utiliza para dar estilo a los elementos que visualizarán los visitantes del sitio

He jugado con la idea de introducir una estructura de directorios para LESS o SASS, pero creo que es demasiado dogmático para el desarrollo y no es la dirección en la que quiero que vayan los Boilerplates. Prefiero que los desarrolladores elijan su propio estilo y que lo incorporen.

Con ese fin, la forma en que normalmente organizo mis hojas de estilo en mis propios proyectos consiste en introducir un directorio dev en el directorio css y luego introducir un archivo admin.less y plugin.less que luego se compila y minimiza en el directorio css raíz.

Esto sigue el ejemplo de organización de los Boilerplates y al mismo tiempo también me permite incluir mis archivos LESS.

JavaScript

Al igual que las hojas de estilo, los archivos JavaScript son un componente trivial para los Boilerplates ya que la mayoría de las personas que han trabajado con WordPress y hayan desarrollado un tema o plugins ya habrán utilizado JavaScript.

Desafortunadamente, una de las partes más frustrantes del uso de JavaScript en WordPress, como usuario y desarrollador, es que los desarrolladores no suelen seguir las mejores prácticas.

En términos generales, los desarrolladores siempre deben hacer lo siguiente:

1. Utilizar la versión de jQuery que se incluye en WordPress
2. Evitar conflictos con la función jQuery '$' obteniendo acceso a ella con una función anónima
3. No anular el registro de jQuery ya que otros plugins y el propio tema podrían estar utilizándolo

Dicho esto, los Boilerplates, al igual que las hojas de estilo y las vistas, se organizan de la siguiente manera:

1. admin.js es el JavaScript que se utiliza para administrar el comportamiento de los elementos para los usuarios en el escritorio
2. widget.js o plugin.js es el JavaScript que se utiliza para gestionar el comportamiento de los elementos para los visitantes

Al igual que con las hojas de estilo, los desarrolladores también pueden optar por limpiar y/o minificar su JavaScript antes de lanzar su plugin. Para evitar ser demasiado cabezota con respecto a cómo se gestionan los archivos JavaScript, no hay subdirectorios incluidos en el Boilerplate, pero a menudo creo un directorio dev en el directorio js con el fin de administrar mi JavaScript "pre-linted", y preminificado.

Idiomas

Uno de los aspectos de la creación de plugins consiste en asegurarse de que sean accesibles y puedan ser traducidos por aquellos que hablen otros idiomas. Para que esto sea lo más sencillo posible, los Boilerplates también incluyen un directorio lang y un archivo esqueleto plugin.po.

Este archivo está diseñado para usarse junto con POEdit para que una vez que se haya completado el desarrollo, puedas procesar todas las cadenas localizadas fácilmente.

¿Qué pasa con las imágenes y otros recursos?

Aparte de las hojas de estilo y los archivos JavaScript, los Boilerplates no proporcionan directorios ni convenciones para administrar otros activos, como puedan ser las imágenes.

Una vez más, es un equilibrio de tratar de evitar ser demasiado dogmático, al mismo tiempo que proporcionas suficiente andamiaje para que los desarrolladores comiencen a centrarse en su funcionalidad principal. Aunque no todos los plugins incluirán CSS, JavaScript o vistas para el área de administración, son mucho más comunes que la inclusión de imágenes y otros recursos.

Aun así, la convención que se ha proporcionado dictaría que puedes crear un directorio de recursos, un directorio de imágenes, un directorio de iconos o cualquier otro tipo de archivo con el que vayas a trabajar.

¿Por qué molestarse?

WordPress Widget Boilerplate

Entonces, ¿qué sentido tiene todo esto? ¿No sería tan sencillo como abrir un único archivo y empezar a escribir todo el código? Definitivamente. Pero recuerda, la mayor parte del desarrollo viene después de que un producto ha sido lanzado, y si te tomas en serio el desarrollo de plugins, significa que estás en el negocio de la creación de productos.

Por tanto, necesitas comenzar teniendo el final en mente. Usando un esquema consistente para organizar tus archivos, nombrando tus archivos, y así sucesivamente:

• Facilita el desarrollo a largo plazo, de modo que tú y los desarrolladores que contribuyan sepan cómo gestionar los archivos, dónde colocar los nuevos y dónde buscar dependencias en caso de que las necesiten
• Facilita el mantenimiento al proporcionar una organización y un patrón comunes a partir de los cuales se puede mejorar el plugin
• Mejora la capacidad de escalar el proyecto más allá de la primera versión sin necesidad de hacer una cantidad significativa de refactorización una vez que el código base se vuelve difícil de manejar

Por encima de todo, el andamiaje debe proporcionar a los desarrolladores la capacidad de comenzar a trabajar fácilmente en la lógica del negocio principal de tu producto sin interponerse en su camino.

Conclusión

En este artículo, revisamos el "Por qué" de la organización de los Boilerplates, pero en realidad no hemos revisado el "Cómo" de los Boilerplates, así que en el siguiente artículo vamos a echar un vistazo precisamente a eso.

Específicamente, trabajaremos paso a paso la construcción de un plugin usando uno de los Boilerplates para que podamos identificar los pasos típicos necesarios para tomar una copia del Boilerplate e iniciar el desarrollo.