En lo que respecta al c\u00f3digo base, estamos en un buen lugar ahora mismo. Hemos comenzado a refactorizar gran parte del c\u00f3digo en clases m\u00e1s peque\u00f1as y m\u00e1s 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.<\/p>\n
Pero todav\u00eda hay un problema al que nos enfrentamos y tiene que ver con los espacios de nombres y la carga autom\u00e1tica. Habl\u00e9 un poco sobre esto hace un par de a\u00f1os,<\/a> pero no en lo que se refiere a Composer.<\/p>\n Y eso es lo que vamos a ver en este post.<\/p>\n En la segunda publicaci\u00f3n de esta serie<\/a>, comenzamos a hablar sobre Composer. Si le pregunta a la mayor\u00eda 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.<\/p>\n En resumen, es una forma de traer bibliotecas de terceros a nuestro proyecto y luego utilizar sus caracter\u00edsticas (para que no tengamos que escribir nuestro propio c\u00f3digo para hacerlo).<\/p>\n Pero hay otra caracter\u00edstica que ofrece Composer que es de gran utilidad, especialmente cuando est\u00e1 usando muchas clases y no<\/strong> quiere usar declaraciones require_once en su base de c\u00f3digo.<\/p>\n Y ese es el cargador autom\u00e1tico.<\/p>\n Directamente del manual:<\/a><\/p>\n Para las bibliotecas que especifican informaci\u00f3n de carga autom\u00e1tica, Composer genera un Si ha estado siguiendo el c\u00f3digo hasta ahora, ver\u00e1 que en realidad ya estamos usando el cargador autom\u00e1tico generado por Composer.<\/p>\n Primero, definimos la configuraci\u00f3n necesaria<\/a> :<\/p>\n Luego comenzamos a incluirlo en el arranque del complemento<\/a> (que finalizaremos hoy):<\/p>\n Pero aqu\u00ed hay un problema: \u00bfC\u00f3mo cargamos solo las clases que necesitamos para la distribuci\u00f3n?<\/p>\n Para decirlo de otra manera: hay muchas bibliotecas que usamos en el desarrollo para asegurarnos de escribir c\u00f3digo de alta calidad que cumpla con los est\u00e1ndares. Pero no queremos distribuir 10 MB de datos a quienes usan nuestro proyecto.<\/p>\n En cambio, debemos incluir solo los archivos que se requieren, \u00bfverdad? Y para hacer eso, debemos asegurarnos de generar un cargador autom\u00e1tico que podamos incluir que haga exactamente eso.<\/p>\n Primero, le mostrar\u00e9 el comando<\/a> y luego explicar\u00e9 todo lo que hace:<\/p>\n Esto generar\u00e1 justo lo que necesitamos para que nuestro proyecto funcione en un entorno de producci\u00f3n. Esto es lo que hace cada bandera:<\/p>\n Si tiene mucha curiosidad por optimizar el cargador autom\u00e1tico para proyectos fuera de esta publicaci\u00f3n, le recomiendo leer esta p\u00e1gina<\/a> en la documentaci\u00f3n de Composer. Est\u00e1 fuera del alcance de lo que estamos haciendo aqu\u00ed, pero puede ser \u00fatil con otro trabajo que tenga ahora o que haga en el futuro.<\/p>\n Si est\u00e1 trabajando en Boilerplate en su m\u00e1quina local, es posible que vea algo como esto:<\/p>\n Pero si ejecuta el comando que se incluye arriba, ver\u00e1 algo como esto:<\/p>\n Esa es una gran diferencia y este es un proyecto peque\u00f1o. Imagine hacer algo mucho m\u00e1s grande que se ejecutar\u00e1 en producci\u00f3n.<\/p>\n Hablando por experiencia, puedo decirle que los proyectos pueden alcanzar r\u00e1pidamente 20 MB o m\u00e1s de dependencias si est\u00e1 utilizando una variedad de bibliotecas de terceros para cosas como registro, solicitudes HTTP y herramientas de calidad de c\u00f3digo.<\/p>\n La gente suele decir que no debe incluir el directorio de proveedores en el control de c\u00f3digo fuente y por una buena raz\u00f3n: puede ser enorme.<\/p>\n Incluso la documentaci\u00f3n de Composer habla de esto:<\/a><\/p>\n La mejor pr\u00e1ctica es hacer que todos los desarrolladores usen Composer para instalar las dependencias. Del mismo modo, el servidor de compilaci\u00f3n, CI, herramientas de implementaci\u00f3n, etc. deben adaptarse para ejecutar Composer como parte de su proyecto de arranque.<\/p>\n<\/blockquote>\n Entonces, \u00bfqu\u00e9 se supone que debemos hacer? Necesitamos el cargador autom\u00e1tico y necesitamos ciertas dependencias porque nuestros usuarios no sabr\u00e1n ejecutar (\u00a1ni deber\u00edan tener que ejecutar!) Composer siempre que descarguen nuestro trabajo.<\/p>\n 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.<\/p>\n Entonces, hagamos cada paso y veamos c\u00f3mo se ve cuando hayamos terminado.<\/p>\n Para crear una nueva rama desde la terminal, ingrese el siguiente comando<\/a> :<\/p>\n Esto tomar\u00e1 todo el c\u00f3digo en el que estamos trabajando y luego crear\u00e1 una nueva rama con \u00e9l. Ya que esta ser\u00e1 la rama que usaremos para actuar como lo que usar\u00e1n nuestros usuarios (hablaremos sobre el maestro<\/strong> en una publicaci\u00f3n futura).<\/p>\n Primero, revise su archivo composer.json y aseg\u00farese de que incluya lo siguiente:<\/p>\n Ahora debemos asegurarnos de ejecutar el comando Composer anterior para asegurarnos de que nada m\u00e1s que lo que necesitamos est\u00e9 en el\u00a0 directorio de proveedores<\/strong>.<\/p>\n Ahora necesitamos actualizar gitignore.<\/p>\n Y si ha seguido tanto la serie como la publicaci\u00f3n hasta aqu\u00ed, entonces sabe que se ver\u00e1 as\u00ed (puede incluir m\u00e1s o menos, pero deber\u00eda incluir al menos esto).<\/p>\n Para m\u00ed, esto se parece a lo siguiente<\/a> :<\/p>\n Dependiendo de si est\u00e1 utilizando una terminal o un cliente, ver\u00e1 que hay nuevos archivos para confirmar (del directorio del proveedor, espec\u00edficamente). As\u00ed que agr\u00e9galos a tu rama.<\/p>\n Luego confirme sus cambios<\/a>. Es posible que deba especificar lo siguiente si est\u00e1 trabajando en la terminal:<\/p>\n Y con eso, su c\u00f3digo deber\u00eda funcionar y estar disponible en GitHub (o cualquier servicio de control de fuente que est\u00e9 usando). Puedes ver lo que tengo disponible aqu\u00ed<\/a>.<\/p>\n 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\u00e1sicas a WordPress Widget Boilerplate para que tengamos algo que mostrar para nuestro trabajo. .<\/p>\n Para aquellos que tengan curiosidad, ahora mismo planeo mantener las sucursales organizadas as\u00ed:<\/p>\n Sin embargo, por ahora, revise lo que se cubre en esta publicaci\u00f3n y lo retomaremos en la pr\u00f3xima publicaci\u00f3n.<\/p>\nEl modelo de widget de WordPress: refactorizaci\u00f3n, parte 6<\/h2>\n
El cargador autom\u00e1tico definido<\/h3>\n
\n
vendor\/autoload.php<\/code>archivo. Simplemente puede incluir este archivo y comenzar a usar las clases que brindan esas bibliotecas sin ning\u00fan trabajo adicional:<\/p>\n<\/blockquote>\n{\n \"name\": \"wordpress-widget-boilerplate\/wordpress-widget-boilerplate\",\n \"description\": \"An organized, maintainable boilerplate for building widgets using WordPress best practices.\",\n \"type\": \"wordpress-plugin\",\n \"license\": \"GPL-3.0-or-later\",\n \"homepage\": \"https:\/\/github.com\/tommcfarlin\/WordPress-Widget-Boilerplate\",\n \"authors\": [\n {\n \"name\": \"Tom McFarlin\",\n \"email\": \"tom@pressware.co\",\n \"homepage\": \"https:\/\/pressware.co\"\n }\n ],\n \"support\": {\n \"issues\": \"https:\/\/github.com\/tommcfarlin\/WordPress-Widget-Boilerplate\/issues\"\n },\n \"config\": {\n \"preferred-install\": \"dist\",\n \"platform\": {\n \"php\": \"7.1\"\n }\n },\n \"repositories\": [\n {\n \"type\": \"composer\",\n \"url\": \"https:\/\/wpackagist.org\"\n }\n ],\n \"require\": {\n \"php\": \"7.1\",\n \"composer\/installers\": \"^1.4\"\n },\n \"require-dev\": {\n \"friendsofphp\/php-cs-fixer\": \"^2.13.1\",\n \"jakub-onderka\/php-parallel-lint\": \"^1.0.0\",\n \"phpmd\/phpmd\": \"^v2.6.0\",\n \"nikic\/php-parser\": \"^4.0\",\n \"ocramius\/proxy-manager\": \"^2.0.0\",\n \"phpro\/grumphp\": \"^0.13.1\"\n },\n \"scripts\": {\n \"test\": [\n \".\/vendor\/bin\/grumphp run\"\n ]\n },\n \"minimum-stability\": \"stable\"\n }<\/code><\/pre>\n<?php\n\n\/\/ Include the autoloader.\n\/\/ TODO: Note this has not yet been defined.\nrequire_once __DIR__. '\/inc\/autoload.php';\n<\/code><\/pre>\n$ composer install --no-dev --no-ansi --no-interaction --optimize-autoloader --no-progress --prefer-dist<\/code><\/pre>\n\n
\u00bfA\u00fan interesado?<\/h4>\n
\u00bfC\u00f3mo es este aspecto en el Boilerplate?<\/h2>\n
![\"Widgets](\"https:\/\/wordpress.mediadoma.com\/wp-content\/uploads\/2022\/01\/post-161015-61e719e23bf2d.png\")
<\/a><\/p>\n![\"Widgets](\"https:\/\/wordpress.mediadoma.com\/wp-content\/uploads\/2022\/01\/post-161015-61e719e5afd5a.png\")
<\/a><\/p>\n\u00bfIncluiremos en nuestro directorio de proveedores?<\/h2>\n
\n
\n
Creaci\u00f3n de la rama de lanzamiento<\/h3>\n
$ git checkout -b release<\/code><\/pre>\n\"autoload\": {\n \"psr-4\": {\n \"WordPressWidgetBoilerplate\": \"src\/\",\n \"WordPressWidgetBoilerplateSubscriber\": \"src\/Subscriber\/\",\n \"WordPressWidgetBoilerplateUtilities\": \"src\/Utilities\/\",\n \"WordPressWidgetBoilerplateViews\": \"src\/Views\/\"\n }\n},<\/code><\/pre>\n$ composer install --no-dev --no-ansi --no-interaction --optimize-autoloader --no-progress --prefer-dist<\/code><\/pre>\nActualizar lo que ignoramos<\/h3>\n
*.DS_Store\n*.log\nwp-config.php\nwp-content\/advanced-cache.php\nwp-content\/backup-db\/\nwp-content\/backups\/\nwp-content\/blogs.dir\/\nwp-content\/cache\/\nwp-content\/upgrade\/\nwp-content\/uploads\/\nwp-content\/mu-plugins\/\nwp-content\/wp-cache-config.php\nwp-content\/plugins\/hello.php\n\n\/.htaccess\n\/license.txt\n\/readme.html\n\/sitemap.xml\n\/sitemap.xml.gz\n\n\/vendor\/**\/.git\n\/vendor\/bin\ncomposer.lock\n<\/code><\/pre>\n$ git push --set-upstream origin release<\/code><\/pre>\nAdici\u00f3n de funcionalidad<\/h2>\n
\n