Widgets de WordPress: Refactorización, Parte 1

La última publicación incluía mucha información sobre cómo configurar herramientas de calidad de código en su entorno de desarrollo de WordPress, pero son necesarias si vamos a realizar muchas refactorizaciones.

Pero como mencioné al comienzo de esta publicación, colocar herramientas de calidad de código primero nos brinda una base que podemos usar a medida que refactorizamos el modelo (lo que claramente debemos hacer dada la cantidad de rojo que muestra GrumPHP).

Honestamente, los veo necesarios si va a realizar algún tipo de desarrollo, de ahí la necesidad de mostrar cómo configurarlos.

De todos modos, la publicación anterior muestra cuánto trabajo nos hemos ahorrado, ¿verdad?

Ahora vamos a comenzar con la refactorización de WordPress Widget Boilerplate.

Esto no solo mejorará la calidad del código, sino que también nos guiará a través de algunos principios orientados a objetos que podemos aplicar al crear nuestros widgets y que podemos aplicar en futuros esfuerzos de desarrollo de WordPress.

El modelo de widget de WordPress: refactorización, parte 1

Quizás lo más emocionante para mí es llevar este repositorio a los estándares modernos. Si observa la rama maestra en GitHub en el momento de esta publicación (o el historial del repositorio más adelante), verá que tiene seis años.

Esta cosa tiene seis años (en el momento de esta publicación).

Eso es mucho tiempo en los años de Internet, ¿no?

De todos modos, en nuestros esfuerzos de refactorización, vamos a hacer algunas cosas:

• crear una rama a partir de la cual trabajar antes de fusionarla nuevamente con la rama maestra,
• implementar una forma más cohesiva de organizar archivos,
• actualizar los estándares de codificación para seguir lo que está más en línea con PSR,
• y más.

Expongo esto ahora porque es probable que no lleguemos a todo en esta publicación, pero cubriremos mucho terreno. Así que dicho esto, comencemos.

1 Creación de una rama de desarrollo

Suponiendo que tiene una copia del repositorio en su máquina local, que debería tener después de la última publicación, lo primero que debemos hacer es crear una rama desde la cual hacer nuestro trabajo.

Es una buena práctica no trabajar en la rama principal. En su lugar, el maestro siempre debe usarse para implementar la última versión estable del código.

Para ello, introduce el siguiente comando en tu terminal:

$ git checkout -b develop

Esto creará una nueva sucursal local. Todavía no se ha enviado a GitHub o a su repositorio remoto (donde sea que lo guarde).

A continuación, ingrese el siguiente comando:

$ git push --set-upstream origin develop

Esto impulsará la rama de desarrollo hasta el repositorio remoto. Una vez hecho esto, debería poder ver todos los cambios que implementamos en la última publicación en su repositorio remoto.

Si está utilizando GitHub, debería verse así:

Si está utilizando otro servicio, aún debería verse similar. Es decir, la estructura del directorio debe ser la misma, pero la forma en que se ve en el navegador variará.

Una nota sobre la rama

Recuerde, el propósito de esta sucursal es que hagamos todo nuestro trabajo. De esta manera, no estamos interfiriendo con la rama maestra de la que mucha gente sacará.

Para ser claros, tal vez nadie sacará provecho de esto. Tal vez lo hagan. De todos modos, las prácticas que se presentan aquí están destinadas a mostrar cómo ejecutar un proyecto utilizando herramientas de control de código fuente y calidad de código para que pueda crear mejores proyectos para usted, su empresa y más.

2 Reorganización de archivos

Lo primero que debemos hacer es reorganizar los archivos, para que imiten una estructura más moderna. Haré todo lo posible para justificar las decisiones que estoy tomando para el proyecto mientras hacemos esto; sin embargo, siéntase libre de tomarse libertades con la forma en que desea hacerlo.

Las decisiones que tomo en última instancia van a afectar el Boilerplate principal. Lo que decida hacer afectará cómo puede usarlo en su trabajo diario o cómo opta por seguir adelante con el proyecto en su conjunto.

Actualización de directorios

Una de las cosas que trato de hacer es desglosar mis directorios para que sean lo más claros posible. Esto significa que trato de hacer lo siguiente:

• crear un directorio de activos para JavaScript y hojas de estilo,
• crear un directorio src para todos los archivos PHP,
• crear un directorio de idioma para los archivos de internacionalización,
• mantenga todos los demás archivos en la raíz del repositorio, de modo que sea fácil para otros seguir el archivo README proporcionado.

Para hacer esto, primero voy a quitar y mover algunas cosas. He tratado de organizar esto en un orden particular:

1. Voy a eliminar el archivo README.txt. Este archivo se usa como una plantilla LÉAME estándar si va a enviar código al Repositorio de complementos de WordPress, pero no es necesario para lo que quiero para Boilerplate.
2. Cambiaré el nombre de plugin.php a Plugin .php para seguir las convenciones de PSR.
3. También cambiaré el nombre de lang a idiomas.
4. Voy a crear un directorio de activos y mover y luego mover los directorios css y js a ese directorio. Crearé un subdirectorio dev en cada uno de estos directorios donde podemos trabajar en Sass y archivos JavaScript no minimizados (ambos aparecerán más adelante en la serie).
5. Después de eso, crearé un directorio src y moveré la hoja de estilos de vistas a ese directorio.
6. También cambiaré el nombre de las vistas a Vistas y también pondré en mayúsculas los archivos que contiene.
7. Finalmente, moveré todo a la raíz del directorio. Esto significa que widget-boilerplate desaparecerá y todos los archivos residirán en el directorio raíz del repositorio.

Estos son muchos pasos, pero son pequeños. Me gusta exponerlos primero para que quede claro lo que sucederá en el resto de esta sección.

Eliminar el LÉAME

Para hacer esto, simplemente ingrese el siguiente comando en su terminal desde la raíz del directorio widget-boilerplate :

$ rm readme.txt

Esto eliminará el archivo. Si ingresas el siguiente comando en tu terminal:

$ git status

Debería ver algo como esto:

Soy fanático de asegurarme de que los diversos cambios que se implementan sean claros y concisos para que sea más fácil revertirlos uno a la vez. Así que sigamos adelante y comprometámonos e impulsemos este cambio.

Introduzca la siguiente:

$ git rm README.txt
$ git add. $ git commit -n -m "Removing the original README.txt template."
$ git push

Esto le indicará a Git que elimine el archivo, agregue el cambio único al conjunto de cambios, confirme sin ejecutar ninguna herramienta de calidad de código (porque no necesitamos hacer eso en este momento; de lo contrario, fallará) y lo impulsará a la rama de desarrollo del repositorio remoto .

Ahora que lo hemos hecho, avancemos y cambiemos el nombre de algunos archivos.

Cambio de nombre de archivos

Mientras estamos en eso, no solo vamos a cambiar el nombre del archivo .php del complemento, sino también a los otros archivos PHP. Estos son archivos que se pueden agrupar lógicamente en el mismo conjunto de cambios, por lo que tiene sentido seguir adelante y hacerlo.

Entonces, desde su terminal, ingrese los siguientes comandos:

$ mv plugin.php Plugin.php
$ mv views/admin.php views/Admin.php
$ mv views/widget.php views/Widget.php

Al hacer esto, aún no hemos realizado ningún cambio en los archivos, por lo que no hay nada que confirmar. Sigamos adelante con el cambio de nombre de los directorios.

Crear Directorios; Renombrar directorios

Tal como hicimos con los archivos, sigamos adelante y creemos un nuevo directorio de activos. En tu terminal, ingresa el siguiente comando:

$ mkdir assets

A continuación, queremos mover los directorios css y js a ese directorio, así que también ingrese lo siguiente en la terminal:

$ mv css assets
$ mv js assets

Y cambiemos el nombre del directorio lang a Idiomas ingresando el siguiente comando:

$ mv lang Languages

Finalmente, cambiemos el nombre de vista a Vistas:

$ mv views Views

En este punto, hemos hecho todo lo posible con los archivos que se encuentran actualmente en el directorio principal. Sin embargo, todavía tenemos que preparar subdirectorios para nuestros activos preprocesados.

Sin embargo, antes de hacer eso, es un buen hábito ejecutar una verificación rápida del estado de git para ver qué se puede agregar a un conjunto de cambios. Si su repositorio es como el mío, es probable que vea algo como lo siguiente:

En este caso, creo que está bien agregar todo en un solo conjunto de cambios con un comentario que indique que hemos cambiado el nombre y movido los archivos.

Puede diferir y si es así, está completamente bien. Sus comandos diferirán un poco de los míos, pero esto es lo que tengo para mi compromiso:

$ git add. $ git commit -n -m "Creating new directories; Renaming files."
$ git push

Ahora, pasemos a los subdirectorios de nuestros archivos preprocesados.

Crear subdirectorios

En el directorio CSS, cree un subdirectorio llamado dev y cree un archivo vacío llamado admin.scss y widget.scss, ya que trabajaremos con estos archivos más adelante en la serie.

A continuación, agregue un directorio dev al directorio de JavaScript y agregue el archivo admin.js vacío y los archivos widget.js a estos archivos. Si se siente tan inclinado, puede mover los archivos preexistentes a los directorios de desarrollo, ya que estos son los archivos que usaremos como base para nuestros archivos de desarrollo.

Ese es un paso opcional; sin embargo, seguí adelante y lo hice porque así es como prefiero trabajar. Aquí está el conjunto de comandos que he ejecutado.

Desde el directorio css …

$ mkdir dev
$ mv admin.css admin.scss && mv widget.css widget.scss
$ mv *.scss dev

Arriba, creé el directorio de desarrollo para mis hojas de estilo, les cambié el nombre a archivos Sass y los moví al directorio de desarrollo.

Antes de continuar, es un buen momento para hacer una verificación de estado de git y realizar cambios relacionados con las hojas de estilo:

$ git add. $ git commit -n -m "Renaming and moving stylesheets into a dev directory."
$ git push

Ahora, desde el directorio js …

$ mkdir dev
$ mv *.js dev

Como no tenemos que cambiar el tipo de archivo de los archivos asociados, simplemente podemos moverlos al nuevo directorio.

Finalmente, hagamos lo mismo y veamos si hay algún cambio que podamos impulsar a través de una verificación rápida de estado de git (que debería haber). Aquí hay una lista de los comandos que ejecuté para confirmar y enviar mis cambios:

$ git add. $ git commit -n -m "Adding a JavaScript dev directory and moving the development files."
$ git push

Ya casi hemos terminado. Todo lo que queda por hacer es mover ciertos directorios a la raíz del repositorio y cambiar el nombre del directorio principal a src. Así que hagámoslo ahora.

Mover directorios a la raíz

Esencialmente, necesitamos mover todo excepto el archivo del complemento y el directorio Views fuera del directorio widget-boilerplate, y debemos cambiar el nombre de widget-boilerplate a src.

Suena simple, ¿verdad? Es bastante sencillo. Desde dentro del directorio widget-boilerplate :

$ mv assets .. && mv languages ..
$ cd ..
$ mv widget-boilerplate src

Luego enviaré el cambio a GitHub usando lo siguiente:

$ git add. $ git commit -n -m "Reorganizing the directory structure."
$ git push

Ahora tenemos configurada una estructura de directorios mucho más moderna. Puedes verlo aquí en mi rama de desarrollo.

Una palabra sobre programación orientada a objetos

Y ahora que tenemos todo esto en su lugar, podemos comenzar a escribir código. Pero no se equivoque: una parte de la programación orientada a objetos también es análisis orientado a objetos y diseño orientado a objetos.

Lo que hemos hecho en esta publicación es esencialmente aplicar un diseño arquitectónico orientado a objetos basado en el análisis de cómo encaja el complemento.

Sin embargo, la siguiente parte es actualizar el código para eliminar todo el rojo que hemos visto al olfatear nuestro código.

En la próxima publicación

El objetivo principal de la próxima publicación es continuar con la actualización de los estándares de codificación para que hayamos resuelto todos los problemas generados por nuestro IDE o mediante las herramientas de calidad del código que estamos ejecutando en la línea de comandos.

También deberíamos tener un repositorio mucho más limpio y organizado, y estar en una posición en la que estemos listos para fusionar nuestro trabajo nuevamente en la rama principal.

Sin embargo, por ahora, asegúrese de tener un buen manejo de todo lo anterior antes de continuar, ya que es necesario comprender el resto del trabajo que tenemos por delante.