Widgets de WordPress: Refactorización, Parte 6

Debe estar bien versado en la refactorización que estamos haciendo con respecto al modelo estándar de widgets de WordPress. Si no, recomiendo ponerse al día con la serie hasta ahora:

• leyendo el post anterior ,
• o leyendo toda la serie hasta este punto,
• y mirando la rama de desarrollo del proyecto en GitHub.

En lo que respecta al código base, estamos en un buen lugar ahora mismo. Hemos comenzado a refactorizar gran parte del código en clases más pequeñas y más enfocadas. Y acabamos de configurar un Registro para que podamos comenzar a trabajar con instancias de objetos en todo el complemento sin la necesidad de demasiado acoplamiento.

Pero todavía hay un problema al que nos enfrentamos y tiene que ver con los espacios de nombres y la carga automática. Hablé un poco sobre esto hace un par de años, pero no en lo que se refiere a Composer.

Y eso es lo que vamos a ver en este post.

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

En la segunda publicación de esta serie, comenzamos a hablar sobre Composer. Si le pregunta a la mayoría de los desarrolladores de PHP (incluidos los que trabajan con WordPress), es probable que escuche que Composer es un administrador de paquetes o un administrador de dependencias.

En resumen, es una forma de traer bibliotecas de terceros a nuestro proyecto y luego utilizar sus características (para que no tengamos que escribir nuestro propio código para hacerlo).

Pero hay otra característica que ofrece Composer que es de gran utilidad, especialmente cuando está usando muchas clases y no quiere usar declaraciones require_once en su base de código.

Y ese es el cargador automático.

El cargador automático definido

Directamente del manual:

Para las bibliotecas que especifican información de carga automática, Composer genera un vendor/autoload.phparchivo. Simplemente puede incluir este archivo y comenzar a usar las clases que brindan esas bibliotecas sin ningún trabajo adicional:

Si ha estado siguiendo el código hasta ahora, verá que en realidad ya estamos usando el cargador automático generado por Composer.

Primero, definimos la configuración necesaria :

{
    "name": "wordpress-widget-boilerplate/wordpress-widget-boilerplate",
    "description": "An organized, maintainable boilerplate for building widgets using WordPress best practices.",
    "type": "wordpress-plugin",
    "license": "GPL-3.0-or-later",
    "homepage": "https://github.com/tommcfarlin/WordPress-Widget-Boilerplate",
    "authors": [
      {
        "name": "Tom McFarlin",
        "email": "tom@pressware.co",
        "homepage": "https://pressware.co"
      }
    ],
    "support": {
      "issues": "https://github.com/tommcfarlin/WordPress-Widget-Boilerplate/issues"
    },
    "config": {
      "preferred-install": "dist",
      "platform": {
          "php": "7.1"
      }
    },
    "repositories": [
      {
        "type": "composer",
        "url": "https://wpackagist.org"
      }
    ],
    "require": {
      "php": "7.1",
      "composer/installers": "^1.4"
    },
    "require-dev": {
        "friendsofphp/php-cs-fixer": "^2.13.1",
        "jakub-onderka/php-parallel-lint": "^1.0.0",
        "phpmd/phpmd": "^v2.6.0",
        "nikic/php-parser": "^4.0",
        "ocramius/proxy-manager": "^2.0.0",
        "phpro/grumphp": "^0.13.1"
    },
    "scripts": {
      "test": [
        "./vendor/bin/grumphp run"
      ]
    },
    "minimum-stability": "stable"
  }

Luego comenzamos a incluirlo en el arranque del complemento (que finalizaremos hoy):

Pero aquí hay un problema: ¿Cómo cargamos solo las clases que necesitamos para la distribución?

Para decirlo de otra manera: hay muchas bibliotecas que usamos en el desarrollo para asegurarnos de escribir código de alta calidad que cumpla con los estándares. Pero no queremos distribuir 10 MB de datos a quienes usan nuestro proyecto.

En cambio, debemos incluir solo los archivos que se requieren, ¿verdad? Y para hacer eso, debemos asegurarnos de generar un cargador automático que podamos incluir que haga exactamente eso.

Primero, le mostraré el comando y luego explicaré todo lo que hace:

$ composer install --no-dev --no-ansi --no-interaction --optimize-autoloader --no-progress --prefer-dist

Esto generará justo lo que necesitamos para que nuestro proyecto funcione en un entorno de producción. Esto es lo que hace cada bandera:

• instalación del compositor. Esto simplemente instala todas las dependencias. Si ya tiene varios de ellos en su directorio de proveedores, esto eliminará todos excepto los que sean necesarios.
• sin desarrollo Esto evitará que Composer instale los paquetes en la sección require-dev de sus archivos de configuración (es decir, las dependencias que estamos usando con GrumPHP).
• no-ansi. Esto evita que se produzca cualquier salida ANSI. Puede que no le importe ejecutar esto o no. Si opta por hacer algún tipo de implementación automática, utilícelo; de lo contrario, se puede omitir del comando.
• sin interacción. Esta es otra bandera que se usa específicamente para entornos en los que desea compilar automáticamente el proyecto y no tener que involucrarse con preguntas, resultados y cosas por el estilo.
• optimizar-cargador automático. En resumen, esto genera un cargador automático más rápido. Puede tardar un poco en ejecutarse según el tamaño de su proyecto, pero vale la pena al iniciar su trabajo.
• sin progreso. Esto oculta la barra de progreso para que no se muestre en la terminal. Es posible que realmente quieras ver esto y, si es así, eso es genial; sin embargo, es posible que algunos entornos no manejen bien ciertos caracteres (como el retroceso).
• prefer-dist. Esto asegurará que los paquetes que se instalan se hagan usando la versión de distribución (en lugar de algo que es menos estable).

¿Aún interesado?

Si tiene mucha curiosidad por optimizar el cargador automático para proyectos fuera de esta publicación, le recomiendo leer esta página en la documentación de Composer. Está fuera del alcance de lo que estamos haciendo aquí, pero puede ser útil con otro trabajo que tenga ahora o que haga en el futuro.

¿Cómo es este aspecto en el Boilerplate?

Si está trabajando en Boilerplate en su máquina local, es posible que vea algo como esto:

Pero si ejecuta el comando que se incluye arriba, verá algo como esto:

Esa es una gran diferencia y este es un proyecto pequeño. Imagine hacer algo mucho más grande que se ejecutará en producción.

Hablando por experiencia, puedo decirle que los proyectos pueden alcanzar rápidamente 20 MB o más de dependencias si está utilizando una variedad de bibliotecas de terceros para cosas como registro, solicitudes HTTP y herramientas de calidad de código.

¿Incluiremos en nuestro directorio de proveedores?

La gente suele decir que no debe incluir el directorio de proveedores en el control de código fuente y por una buena razón: puede ser enorme.

Incluso la documentación de Composer habla de esto:

La mejor práctica es hacer que todos los desarrolladores usen Composer para instalar las dependencias. Del mismo modo, el servidor de compilación, CI, herramientas de implementación, etc. deben adaptarse para ejecutar Composer como parte de su proyecto de arranque.

Entonces, ¿qué se supone que debemos hacer? Necesitamos el cargador automático y necesitamos ciertas dependencias porque nuestros usuarios no sabrán ejecutar (¡ni deberían tener que ejecutar!) Composer siempre que descarguen nuestro trabajo.

Debido a la naturaleza de WordPress y el trabajo que estamos haciendo, vamos a necesitar confirmar el directorio de proveedores, pero solo con ciertos requisitos.

1. Crearemos una rama que se usará para el lanzamiento (la llamaremos creativamente lanzamiento y podemos fusionarla para desarrollarla cuando sea necesario).
2. Nos aseguraremos de que el directorio de proveedores no sea parte del archivo gitignore; sin embargo, nos aseguraremos de que se ignoren los directorios .git dentro del directorio del proveedor (eso aún puede ocupar mucho espacio).

Entonces, hagamos cada paso y veamos cómo se ve cuando hayamos terminado.

Creación de la rama de lanzamiento

Para crear una nueva rama desde la terminal, ingrese el siguiente comando :

$ git checkout -b release

Esto tomará todo el código en el que estamos trabajando y luego creará una nueva rama con él. Ya que esta será la rama que usaremos para actuar como lo que usarán nuestros usuarios (hablaremos sobre el maestro en una publicación futura).

Primero, revise su archivo composer.json y asegúrese de que incluya lo siguiente:

"autoload": {
    "psr-4": {
        "WordPressWidgetBoilerplate": "src/",
        "WordPressWidgetBoilerplateSubscriber": "src/Subscriber/",
        "WordPressWidgetBoilerplateUtilities": "src/Utilities/",
        "WordPressWidgetBoilerplateViews": "src/Views/"
    }
},

Ahora debemos asegurarnos de ejecutar el comando Composer anterior para asegurarnos de que nada más que lo que necesitamos esté en el  directorio de proveedores.

$ composer install --no-dev --no-ansi --no-interaction --optimize-autoloader --no-progress --prefer-dist

Ahora necesitamos actualizar gitignore.

Actualizar lo que ignoramos

Y si ha seguido tanto la serie como la publicación hasta aquí, entonces sabe que se verá así (puede incluir más o menos, pero debería incluir al menos esto).

Para mí, esto se parece a lo siguiente :

*.DS_Store
*.log
wp-config.php
wp-content/advanced-cache.php
wp-content/backup-db/
wp-content/backups/
wp-content/blogs.dir/
wp-content/cache/
wp-content/upgrade/
wp-content/uploads/
wp-content/mu-plugins/
wp-content/wp-cache-config.php
wp-content/plugins/hello.php

/.htaccess
/license.txt
/readme.html
/sitemap.xml
/sitemap.xml.gz

/vendor/**/.git
/vendor/bin
composer.lock

Dependiendo de si está utilizando una terminal o un cliente, verá que hay nuevos archivos para confirmar (del directorio del proveedor, específicamente). Así que agrégalos a tu rama.

Luego confirme sus cambios. Es posible que deba especificar lo siguiente si está trabajando en la terminal:

$ git push --set-upstream origin release

Y con eso, su código debería funcionar y estar disponible en GitHub (o cualquier servicio de control de fuente que esté usando). Puedes ver lo que tengo disponible aquí.

Adición de funcionalidad

Ahora que tenemos todas las piezas necesarias en su lugar, es hora de comenzar a usar Composer, el autocargador, nuestras clases abstractas y nuestro Registro para comenzar a agregar algunas funciones básicas a WordPress Widget Boilerplate para que tengamos algo que mostrar para nuestro trabajo. .

Para aquellos que tengan curiosidad, ahora mismo planeo mantener las sucursales organizadas así:

• master será lo que esté disponible para todos los que quieran crear un widget de WordPress,
• desarrollar es estrictamente para desarrolladores, incluidos aquellos que saben cómo usar Composer y los temas discutidos en esta publicación,
• release es lo que se utilizará para proporcionar una demostración funcional.

Sin embargo, por ahora, revise lo que se cubre en esta publicación y lo retomaremos en la próxima publicación.