Usando el compositor con WordPress

1. Introducción al compositor y empaquetador
2. Introducción a WPackagist
3. Posibilidades y limitaciones del uso conjunto de WordPress y Composer
4. Administrar todo el sitio de WordPress a través del Mirror Of WordPress Core de John P. Bloch
5. Administrar todo el sitio de WordPress a través de Bedrock
6. Conclusión

WordPress se está modernizando, lo que nos permite repensar cómo aprovechar al máximo las herramientas y tecnologías más nuevas. En este artículo, Leonardo Losoviz explica cómo se puede integrar WordPress con Composer, Packagist y WPackagist para producir un mejor código.

WordPress se está modernizando. La reciente inclusión de Gutenberg basado en JavaScript como parte del núcleo ha agregado capacidades modernas para crear sitios en la interfaz y el próximo aumento de la versión mínima de PHP , de la actual 5.2.4 a 5.6 en abril de 2019 y 7.0 en diciembre de 2019. pondrá a disposición una gran cantidad de funciones nuevas para crear sitios potentes.

En mi artículo anterior sobre Smashing en el que identifiqué las características de PHP recientemente disponibles para WordPress , sostuve que ha llegado el momento de hacer de los componentes la unidad básica para crear funcionalidades en WordPress. Por un lado, Gutenberg ya hace del bloque (que es un componente de alto nivel) la unidad básica para construir la página web en el frontend; por otro lado, al aumentar la versión mínima requerida de PHP, el backend de WordPress tiene acceso a toda la colección de funciones de programación orientada a objetos de PHP (como clases y objetos, interfaces, rasgos y espacios de nombres), que son parte de el conjunto de herramientas para pensar/codificar en componentes.

Entonces, ¿ por qué componentes? ¿Qué tienen de bueno? Un "componente" no es una implementación (como un componente de React), sino un concepto: representa el acto de encapsular propiedades dentro de objetos y agrupar objetos en un paquete que resuelve un problema específico. Los componentes se pueden implementar tanto para el frontend (como los codificados a través de bibliotecas de JavaScript como React o Vue, o bibliotecas de componentes CSS como Bootstrap) como para el backend.

Podemos utilizar componentes ya creados y personalizarlos para nuestros proyectos, por lo que aumentaremos nuestra productividad al no tener que reinventar la rueda cada vez , y debido a su enfoque en resolver un problema específico y estar naturalmente desacoplados de la aplicación, se puede probar y corregir errores muy fácilmente, lo que hace que la aplicación sea más fácil de mantener a largo plazo.

El concepto de componentes se puede emplear para diferentes usos, por lo que debemos asegurarnos de que estamos hablando del mismo caso de uso. En un artículo anterior, describí cómo crear componentes en un sitio web ; El objetivo era transformar la página web en una serie de componentes, envolviéndolos entre sí desde un único componente superior hasta los componentes más básicos (para representar el diseño). En ese caso, el caso de uso del componente es para renderizado, similar a un componente de React pero codificado en el backend. Sin embargo, en este artículo, el caso de uso de los componentes es importar y administrar funciones en la aplicación.

Introducción al compositor y empaquetador

Para importar y administrar componentes propios y de terceros en nuestros proyectos PHP, podemos confiar en el administrador de dependencias PHP Composer que, de forma predeterminada, recupera paquetes del repositorio de paquetes PHP Packagist (donde un paquete es esencialmente un directorio que contiene código PHP). Con su facilidad de uso y características excepcionales, Composer + Packagist se han convertido en herramientas clave para establecer las bases de las aplicaciones basadas en PHP.

Composer permite declarar las bibliotecas de las que depende el proyecto y las administrará (instalará/actualizará). Funciona de forma recursiva : las bibliotecas de las que dependen las dependencias se importarán al proyecto y también se gestionarán. Composer tiene un mecanismo para resolver conflictos: si dos bibliotecas diferentes dependen de una versión diferente de una misma biblioteca, Composer intentará encontrar una versión que sea compatible con ambos requisitos o generará un error si no es posible.

Para usar Composer, el proyecto simplemente necesita un archivo compositor.json en su carpeta raíz. Este archivo define las dependencias del proyecto (cada una para una restricción de versión específica basada en el control de versiones semántico ) y también puede contener otros metadatos. Por ejemplo, el siguiente archivo compositor.json hace que un proyecto requiera nesbot/carbon, una biblioteca que proporciona una extensión para DateTime, para el último parche de su versión 2.12:

{ "require": { "nesbot/carbon": "2.12.*" }}

Podemos editar este archivo manualmente o podemos crearlo/actualizarlo mediante comandos. Para el caso anterior, simplemente abrimos una ventana de terminal, nos dirigimos al directorio raíz del proyecto y escribimos:

composer require "nesbot/carbon"

Este comando buscará la biblioteca requerida en Packagist (que se encuentra aquí ) y agregará su última versión como una dependencia del archivo compositor.json existente . (Si este archivo aún no existe, primero lo creará). Luego, podemos importar las dependencias al proyecto, que se agregan de forma predeterminada en la vendor/carpeta, simplemente ejecutando:

composer install

Siempre que se actualiza una dependencia, por ejemplo nesbot/carbonla versión publicada 2.12.1 y la instalada actualmente es 2.12.0, Composer se encargará de importar la biblioteca correspondiente ejecutando:

composer update

Si usamos Git, solo tenemos que especificar la vendor/carpeta en el archivo .gitignore para no comprometer las dependencias del proyecto bajo control de versiones, lo que facilita mantener el código de nuestro proyecto completamente desacoplado de las bibliotecas externas.

Composer ofrece muchas características adicionales, que se describen adecuadamente en la documentación . Sin embargo, ya en su uso más básico, Composer ofrece a los desarrolladores poder ilimitado para gestionar las dependencias del proyecto.

Introducción a WPackagist

Similar a Packagist, WPackagist es un repositorio de paquetes PHP. Sin embargo, tiene una particularidad: contiene todos los temas y complementos alojados en los directorios de temas y complementos de WordPress , lo que los hace disponibles para su administración a través de Composer.

Para utilizar WPackagist, nuestro archivo compositor.json debe incluir la siguiente información:

{ "repositories":[ { "type":"composer", "url":"https://wpackagist.org" } ]}

Luego, cualquier tema y complemento se puede importar al proyecto usando "wpackagist-theme"y "wpackagist-plugin"respectivamente como nombre del proveedor y el slug del tema o complemento en el directorio de WordPress (como "akismet"en https://wordpress.org/plugins/akismet/ ) . como nombre del paquete. Debido a que los temas no tienen una versión troncal, se recomienda que la restricción de versión del tema sea “*”:

{ "require": { "wpackagist-plugin/akismet":"^4.1", "wpackagist-plugin/bbpress":"=2.5.12", "wpackagist-theme/twentynineteen":"*" }}

A los paquetes disponibles en WPackagist se les ha asignado el tipo "wordpress-plugin" o "wordpress-theme". Como consecuencia, después de ejecutar composer update, en lugar de instalar los temas y complementos correspondientes en la carpeta predeterminada vendor/, estos se instalarán donde WordPress los espera: en las carpetas wp-content/themes/y wp-content/plugins/respectivamente.

Posibilidades y limitaciones del uso conjunto de WordPress y Composer

Hasta ahora, todo bien: Composer hace que sea muy sencillo administrar las dependencias de un proyecto PHP. Sin embargo, el núcleo de WordPress no lo ha adoptado como su herramienta preferida de gestión de dependencias, principalmente porque WordPress es una aplicación heredada que nunca fue diseñada para usarse con Composer , y la comunidad no puede ponerse de acuerdo si WordPress debe considerarse el sitio o la dependencia de un sitio , y la integración de estos enfoques requiere trucos.

En este sentido, WordPress se ve superado por frameworks más nuevos que podrían incorporar Composer como parte de su arquitectura. Por ejemplo, Laravel se sometió a una reescritura importante en 2013 para establecer Composer como un administrador de paquetes a nivel de aplicación . Como consecuencia, el núcleo de WordPress todavía no incluye el archivo compositor.json necesario para administrar WordPress como una dependencia de Composer.

Sabiendo que WordPress no se puede administrar de forma nativa a través de Composer, exploremos las formas en que se puede agregar dicho soporte y qué obstáculos encontramos en cada caso.

Hay tres formas básicas en las que WordPress y Composer pueden trabajar juntos :

1. Gestionar dependencias al desarrollar un tema o complemento;
2. Administrar temas y complementos en un sitio;
3. Administre el sitio por completo (incluidos sus temas, complementos y el núcleo de WordPress).

Y hay dos situaciones básicas sobre quién tendrá acceso al software (un tema o complemento, o el sitio):

1. El desarrollador puede tener control absoluto sobre cómo se actualizará el software, por ejemplo, administrando el sitio para el cliente o brindando capacitación sobre cómo hacerlo;
2. El desarrollador no tiene control absoluto de la experiencia del usuario administrador, por ejemplo, al publicar temas o complementos a través del directorio de WordPress, que serán utilizados por una parte desconocida.

A partir de la combinación de estas variables, tendremos más o menos libertad en cuanto a qué tan profundamente podemos integrar WordPress y Composer juntos.

Desde un aspecto filosófico relacionado con el objetivo y el grupo objetivo de cada herramienta, mientras Composer empodera a los desarrolladores, WordPress se centra principalmente en las necesidades de los usuarios finales primero, y sólo después en las necesidades de los desarrolladores. Esta situación no es contradictoria: por ejemplo, un desarrollador puede crear y lanzar el sitio web usando Composer, y luego entregar el sitio al usuario final, quien (a partir de ese momento) utilizará los procedimientos estándar para instalar temas y complementos . sin pasar por Composer. Sin embargo, entonces el sitio y su archivo compositor.json no están sincronizados y el proyecto ya no se puede administrar de manera confiable a través de Composer: eliminar manualmente todos los complementos de la wp-content/plugins/carpeta y ejecutarlos composer updateno volverá a descargar los complementos agregados al final. usuario.

La alternativa para mantener el proyecto sincronizado sería pedirle al usuario que instale temas y complementos a través de Composer. Sin embargo, este enfoque va en contra de la filosofía de WordPress : pedirle al usuario final que ejecute un comando, como composer installinstalar las dependencias de un tema o complemento, agrega fricción, y WordPress no puede esperar que todos los usuarios puedan ejecutar esta tarea , tan simple. como puede ser. Por tanto, este enfoque no puede ser el predeterminado; en cambio, solo se puede utilizar si tenemos control absoluto de la experiencia del usuario en wp-admin/, como cuando creamos un sitio para nuestro propio cliente y brindamos capacitación sobre cómo actualizar el sitio.

El enfoque predeterminado, que maneja el caso en el que se desconoce quién utiliza el software, es lanzar temas y complementos con todas sus dependencias incluidas. Esto implica que las dependencias también deben cargarse en los repositorios de subversión de temas y complementos de WordPress , lo que evita el propósito del Compositor. Siguiendo este enfoque, los desarrolladores aún pueden usar Composer para el desarrollo, pero no para lanzar el software.

Este enfoque tampoco es a prueba de fallos: si dos complementos diferentes incluyen versiones diferentes de una misma biblioteca que son incompatibles entre sí, y estos dos complementos están instalados en el mismo sitio, podría provocar que el sitio no funcione correctamente . Una solución a este problema es modificar el espacio de nombres de las dependencias a algún espacio de nombres personalizado, lo que garantiza que las diferentes versiones de la misma biblioteca, al tener diferentes espacios de nombres, se traten como bibliotecas diferentes. Esto se puede lograr mediante un script personalizado o mediante Mozart , una biblioteca que compone todas las dependencias como un paquete dentro de un complemento de WordPress.

Para administrar el sitio por completo, Composer debe instalar WordPress en un subdirectorio para poder instalar y actualizar el núcleo de WordPress sin afectar otras bibliotecas, por lo tanto, la configuración debe considerar WordPress como una dependencia del sitio y no el sitio en sí. (Composer no adopta una postura: esta decisión tiene el propósito práctico de poder utilizar la herramienta; desde una perspectiva teórica, aún podemos considerar que WordPress es el sitio). Debido a que WordPress se puede instalar en un subdirectorio , esto No representa un problema técnico. Sin embargo, WordPress se instala de forma predeterminada en la carpeta raíz, e instalarlo en un subdirectorio implica una decisión consciente tomada por el usuario.

Para facilitar la administración completa de WordPress con Composer, varios proyectos han adoptado la postura de instalar WordPress en una subcarpeta y proporcionar un archivo compositor.json obstinado con una configuración que funciona bien: el colaborador principal John P. Bloch proporciona un espejo de WordPress. core y Roots proporciona un modelo estándar de WordPress llamado Bedrock . Describiré cómo utilizar cada uno de estos dos proyectos en las secciones siguientes. Aprender a programar con ejemplos

Administrar todo el sitio de WordPress a través del Mirror Of WordPress Core de John P. Bloch

He seguido la receta de Andrey “Rarst” Savchenko para crear el paquete Composer de todo el sitio , que utiliza la réplica de John P. Bloch del núcleo de WordPress. A continuación, reproduciré su método, agregando información adicional y mencionando los errores que encontré en el camino.

Primero, cree un archivo compositor.json con el siguiente contenido en la carpeta raíz de su proyecto:

{ "type": "project", "config": { "vendor-dir": "content/vendor" }, "extra": { "wordpress-install-dir": "wp" }, "require": { "johnpbloch/wordpress": "=5.1" }}

A través de esta configuración, Composer instalará WordPress 5.1 en la carpeta "wp"y las dependencias se instalarán en la carpeta "content/vendor". Luego dirígete a la carpeta raíz del proyecto en la terminal y ejecuta el siguiente comando para que Composer haga su magia e instale todas las dependencias, incluido WordPress:

composer install --prefer-dist

A continuación agreguemos un par de complementos y el tema, para lo cual también debemos agregar WPackagist como repositorio, y configuremos estos para que se instalen en "content/plugins"y "content/themes"respectivamente. Debido a que estas no son las ubicaciones predeterminadas que WordPress espera, más adelante necesitaremos decirle a WordPress dónde encontrarlas a través de constante WP_CONTENT_DIR.

Nota : El núcleo de WordPress incluye de forma predeterminada algunos temas y complementos en carpetas "wp/wp-content/themes" y "wp/wp-content/plugins", sin embargo, no se podrá acceder a ellos.

Añade el siguiente contenido a composer.json, además del anterior:

{ "repositories": [ { "type": "composer", "url" : "https://wpackagist.org" } ], "require": { "wpackagist-plugin/wp-super-cache": "1.6.*", "wpackagist-plugin/bbpress": "2.5.*", "wpackagist-theme/twentynineteen": "*" }, "extra": { "installer-paths": { "content/plugins/{$name}/": ["type:wordpress-plugin"], "content/themes/{$name}/": ["type:wordpress-theme"] } }}

Y luego ejecutar en la terminal:

composer update --prefer-dist

¡Aleluya! ¡El tema y los complementos han sido instalados! Dado que todas las dependencias se distribuyen en las carpetas wp, y content/vendors, podemos ignorarlas fácilmente al enviar nuestro proyecto bajo control de versiones a través de Git. Para ello, cree un archivo .gitignore con este contenido:content/pluginscontent/themes

wp/content/vendor/content/themes/content/plugins/

Nota : También podríamos ignorar directamente la carpeta content/, que ya ignorará todos los archivos multimedia content/uploads/ y los archivos generados por los complementos, que probablemente no deban estar bajo control de versiones.

Quedan algunas cosas por hacer antes de que podamos acceder al sitio. Primero, duplique el archivo wp/wp-config-sample.php en wp-config.php (y agregue una línea con wp-config.php al archivo .gitignore para evitar comprometerlo, ya que este archivo contiene información del entorno), y edítelo con la información habitual que requiere WordPress (información de la base de datos y claves secretas y sales). Luego, agregue las siguientes líneas en la parte superior de wp-config.php , que cargará el cargador automático de Composer y establecerá la constante WP_CONTENT_DIRen la carpeta content/:

// Load Composer’s autoloaderrequire_once (__DIR__.'/content/vendor/autoload.php');// Move the location of the content dirdefine('WP_CONTENT_DIR', dirname(__FILE__).'/content');

De forma predeterminada, WordPress establece una constante WP_CONSTANT_URLcon valor get_option('siteurl').'/wp-content'. Debido a que hemos cambiado el directorio de contenido predeterminado "wp-content"a "content", también debemos establecer el nuevo valor para WP_CONSTANT_URL. Para hacer esto, no podemos hacer referencia a la función get_optionya que aún no se ha definido, por lo que debemos codificar el dominio o, posiblemente mejor, podemos recuperarlo de $_SERVEResta manera:

$s = empty($_SERVER["HTTPS"]) ? '' : ($_SERVER["HTTPS"] == "on") ? "s" : "";$sp = strtolower($_SERVER["SERVER_PROTOCOL"]);$protocol = substr($sp, 0, strpos($sp, "/")) . $s;$port = ($_SERVER["SERVER_PORT"] == "80") ? "" : (":".$_SERVER["SERVER_PORT"]);define('WP_CONTENT_URL', $protocol."://".$_SERVER[’SERVER_NAME'].$port.'/content');

Ahora podemos acceder al sitio en el navegador domain.com/wp/y proceder a instalar WordPress. Una vez completada la instalación, iniciamos sesión en el Dashboard y activamos el tema y los complementos.

Finalmente, debido a que WordPress se instaló en el subdirectorio wp, la URL contendrá la ruta " /wp" al acceder al sitio. Eliminémoslo (aunque no para el lado administrativo, al que al acceder /wp/wp-admin/se agrega un nivel adicional de seguridad al sitio).

La documentación propone dos métodos para hacer esto: con o sin cambio de URL. Los seguí a ambos y encontré que el cambio sin URL era un poco insatisfactorio porque requiere especificar el dominio en el archivo .htaccess , mezclando así el código de la aplicación y la información de configuración. Por lo tanto, describiré el método con cambio de URL.

Primero, dirígete a "Configuración general" que encontrarás debajo domain.com/wp/wp-admin/options-general.phpy elimina el /wpbit " " del valor "Dirección del sitio (URL)" y guarda. Después de hacerlo, el sitio dejará de funcionar momentáneamente: al navegar por la página de inicio se enumerará el contenido del directorio y al navegar por una publicación de blog se obtendrá un 404. Sin embargo, no entre en pánico, esto se solucionará en el siguiente paso.

A continuación, copiamos el archivo index.php a la carpeta raíz y editamos este nuevo archivo, agregando " wp/" a la ruta del archivo requerido, así:

/** Loads the WordPress Environment and Template */require( dirname( __FILE__ ) . '/wp/wp-blog-header.php' );

¡Hemos terminado! Ahora podemos acceder a nuestro sitio en el navegador en domain.com:

A pesar de que ha descargado todo el código base de WordPress y varias bibliotecas, nuestro proyecto en sí involucra solo seis archivos de los cuales solo cinco deben enviarse a Git:

1. .gitignore
2. compositor.json
3. compositor.lock
   Este archivo lo genera automáticamente Composer y contiene las versiones de todas las dependencias instaladas.
4. index.php
   Este archivo se crea manualmente.
5. .htaccess
   WordPress crea automáticamente este archivo, por lo que podríamos evitar su confirmación; sin embargo, es posible que pronto lo personalicemos para la aplicación, en cuyo caso es necesario confirmarlo.

El sexto archivo restante es wp-config.php , que no debe confirmarse ya que contiene información del entorno.

¡Nada mal!

El proceso transcurrió bastante bien, sin embargo, podría mejorarse si se solucionan mejor los siguientes problemas:

1. Parte del código de la aplicación no se confirma bajo el control de versiones.
   Dado que contiene información del entorno, el archivo wp-config.php no debe enviarse a Git, sino que debe mantener una versión diferente de este archivo para cada entorno. Sin embargo, también agregamos una línea de código para cargar el cargador automático de Composer en este archivo, que deberá replicarse para todas las versiones de este archivo en todos los entornos.
2. El proceso de instalación no está completamente automatizado.
   Después de instalar las dependencias a través de Composer, aún debemos instalar WordPress mediante su procedimiento estándar, iniciar sesión en el Panel y cambiar la URL del sitio para que no contenga " wp/". Por lo tanto, el proceso de instalación está ligeramente fragmentado e involucra tanto un script como un operador humano.

Veamos a continuación cómo le va a Bedrock en la misma tarea.

Administrar todo el sitio de WordPress a través de Bedrock

Bedrock es un modelo estándar de WordPress con una estructura de carpetas mejorada, que se ve así:

├── composer.json├── config│ ├── application.php│ └── environments│ ├── development.php│ ├── staging.php│ └── production.php├── vendor└── web ├── app │ ├── mu-plugins │ ├── plugins │ ├── themes │ └── uploads ├── wp-config.php ├── index.php └── wp

Las personas detrás de Roots eligieron esta estructura de carpetas para que WordPress adopte la aplicación Twelve Factor , y explican cómo se logra esto a través de una serie de publicaciones en el blog . Esta estructura de carpetas puede considerarse una mejora con respecto a la estándar de WordPress en las siguientes cuentas:

• Agrega soporte para Composer al mover el núcleo de WordPress fuera de la carpeta raíz y dentro de la carpeta web/wp;
• Mejora la seguridad, porque los archivos de configuración que contienen la información de la base de datos no se almacenan dentro de la carpeta web, que está configurada como la raíz de documentos del servidor web (la amenaza a la seguridad es que, si el servidor web falla, no habrá protección para bloquear el acceso a los archivos de configuración );
• La carpeta wp-contentha sido renombrada como “ app”, que es un nombre más estándar ya que lo utilizan otros frameworks como Symfony y Rails, y para reflejar mejor el contenido de esta carpeta.

Bedrock también presenta diferentes archivos de configuración para diferentes entornos (desarrollo, preparación, producción) y desacopla claramente la información de configuración del código a través de la biblioteca PHP dotenv , que carga variables de entorno desde un archivo .env que se ve así:

DB_NAME=database_nameDB_USER=database_userDB_PASSWORD=database_password# Optionally, you can use a data source name (DSN)# When using a DSN, you can remove the DB_NAME, DB_USER, DB_PASSWORD, and DB_HOST variables# DATABASE_URL=mysql://database_user:database_password@database_host:database_port/database_name# Optional variables# DB_HOST=localhost# DB_PREFIX=wp_WP_ENV=developmentWP_HOME=https://example.comWP_SITEURL=${WP_HOME}/wp# Generate your keys here: https://roots.io/salts.htmlAUTH_KEY='generateme'SECURE_AUTH_KEY='generateme'LOGGED_IN_KEY='generateme'NONCE_KEY='generateme'AUTH_SALT='generateme'SECURE_AUTH_SALT='generateme'LOGGED_IN_SALT='generateme'NONCE_SALT='generateme'

Procedamos a instalar Bedrock, siguiendo sus instrucciones . Primero cree un proyecto como este:

composer create-project "roots/bedrock"

Este comando iniciará el proyecto Bedrock en una nueva carpeta "bedrock", configurando la estructura de carpetas, instalando todas las dependencias iniciales y creando un archivo .env en la carpeta raíz que debe contener la configuración del sitio. Luego debemos editar el archivo .env para agregar la configuración de la base de datos y las claves secretas y sales, como normalmente se requeriría en el archivo wp-config.php , y también para indicar cuál es el entorno (desarrollo, preparación, producción) y el sitio. dominio.

A continuación, ya podemos agregar temas y complementos. Bedrock viene con los temas veinte diez a veintinueve enviados de forma predeterminada en la carpeta web/wp/wp-content/themes, pero cuando se agregan más temas a través de Composer, estos se instalan en web/app/themes. Esto no es un problema, porque WordPress puede registrar más de un directorio para almacenar temas a través de la función register_theme_directory.

Bedrock incluye la información de WPackagist en el archivo compositor.json , por lo que ya podemos instalar temas y complementos desde este repositorio. Para hacerlo, simplemente acceda a la carpeta raíz del proyecto y ejecute el composer requirecomando para cada tema y complemento a instalar (este comando ya instala la dependencia, por lo que no es necesario ejecutarlo composer update):

cd bedrootcomposer require "wpackagist-theme/zakra"composer require "wpackagist-plugin/akismet":"^4.1"composer require "wpackagist-plugin/bbpress":"=2.5.12"

El último paso es configurar el servidor web, estableciendo la raíz del documento en la ruta completa de la webcarpeta. Una vez hecho esto, al dirigirnos domain.comal navegador, nos saludará felizmente la pantalla de instalación de WordPress. Una vez que se completa la instalación, podemos acceder al administrador de WordPress domain.com/wp/wp-adminy activar el tema y los complementos instalados, y se puede acceder al sitio en domain.com. ¡Éxito!

La instalación de Bedrock fue bastante sencilla. Además, Bedrock hace un mejor trabajo al no mezclar el código de la aplicación con la información del entorno en el mismo archivo, por lo que el problema relacionado con el código de la aplicación que no se confirma bajo el control de versiones que obtuvimos con el método anterior no ocurre aquí.

Conclusión

Con el lanzamiento de Gutenberg y el próximo aumento de la versión mínima requerida de PHP, WordPress ha entrado en una era de modernización que brinda una maravillosa oportunidad para repensar cómo construimos sitios de WordPress para aprovechar al máximo las herramientas y tecnologías más nuevas. Composer, Packagist y WPackagist son herramientas que pueden ayudarnos a producir un mejor código de WordPress, con énfasis en componentes reutilizables para producir aplicaciones modulares que sean fáciles de probar y corregir errores.

Lanzado por primera vez en 2012, Composer no es precisamente lo que llamaríamos software "nuevo", sin embargo, no se ha incorporado al núcleo de WordPress debido a algunas incompatibilidades entre la arquitectura de WordPress y los requisitos de Composer. Este problema ha sido una fuente continua de frustración para muchos miembros de la comunidad de desarrollo de WordPress, quienes afirman que la integración de Composer en WordPress mejorará la creación y lanzamiento de software para WordPress. Afortunadamente, no necesitamos esperar hasta que este problema se resuelva, ya que varios actores tomaron el asunto en sus propias manos para brindar una solución.

En este artículo, revisamo

Tal vez te puede interesar:

1. ¿Deberían abrirse los enlaces en ventanas nuevas?
2. 24 excelentes tutoriales de AJAX
3. 70 técnicas nuevas y útiles de AJAX y JavaScript
4. Más de 45 excelentes recursos y repositorios de fragmentos de código

Usando el compositor con WordPress

Introducción al compositor y empaquetadorIntroducción a WPackagistPosibilidades y limitaciones del uso conjunto de WordPress y ComposerAdministrar todo el si

programar

es

https://aprendeprogramando.es/static/images/programar-usando-el-compositor-con-wordpress-973-0.jpg

2024-12-03

Si crees que alguno de los contenidos (texto, imagenes o multimedia) en esta página infringe tus derechos relativos a propiedad intelectual, marcas registradas o cualquier otro de tus derechos, por favor ponte en contacto con nosotros en el mail [email protected] y retiraremos este contenido inmediatamente