Usando Composer con WordPress

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

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 la interfaz; 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 estos?

Un «componente» no es una implementación (como un componente 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) y el backend.

Podemos usar 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 al estar naturalmente desacoplados de la aplicación, se pueden 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 este artículo, el caso de uso de los componentes es importar y administrar la funcionalidad en la aplicación.

Introducción a Composer y Packagist #

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 dependientes de 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 composer.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 composer.json hace que un proyecto requiera nesbot/carbon, una biblioteca que proporcione 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 puede crearse / actualizarse 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 composer.json existente. (Si este archivo aún no existe, primero lo creará). Luego, podemos importar las dependencias al proyecto, que se agregan por defecto en la carpeta vendor/, simplemente ejecutando:

composer install 

Siempre que se actualice una dependencia, por ejemplo, la nesbot/carbonversión 2.12.1 publicada 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 carpeta vendor/ en el archivo .gitignore para no comprometer las dependencias del proyecto bajo el control de versiones, por lo que es muy fácil mantener el código de nuestro proyecto completamente desacoplado de las bibliotecas externas.

Composer ofrece muchas funciones adicionales, que se describen correctamente en la documentación. Sin embargo, ya en su uso más básico, Composer brinda a los desarrolladores un poder ilimitado para administrar 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 plugins alojados en los directorios de plugins y temas de WordPress, lo que los hace disponibles para ser administrados a través de Composer.

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

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

Luego, cualquier tema y plugin se puede importar al proyecto usando "wpackagist-theme" y "wpackagist-plugin" respectivamente como el nombre del proveedor, y el slug del tema o plugin en el directorio de WordPress (como "akismet" en https://wordpress.org/plugins/akismet/) como el 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 plugins 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 de usar WordPress y Composer juntos #

Hasta ahora, todo va bien: Composer facilita la gestión de las dependencias de un proyecto PHP. Sin embargo, el núcleo de WordPress no lo ha adoptado como su herramienta de administración de dependencias preferida, 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 hacks.

En este dilema, WordPress está superado por marcos más nuevos que podrían incorporar Composer como parte de su arquitectura. Por ejemplo, Laravel se sometió a una importante reescritura 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 composer.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 los obstáculos que encontramos en cada caso. Hay tres formas básicas en las que WordPress y Composer pueden trabajar juntos:

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

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

1. El desarrollador puede tener el control absoluto de cómo se actualizará el software, por ejemplo, administrando el sitio para el cliente o brindando capacidades al mismo sobre cómo hacerlo.
2. El desarrollador no tiene un control absoluto de la experiencia del usuario administrador, por ejemplo, liberando temas o plugins 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 la profundidad con la que podemos integrar WordPress y Composer juntos.

Desde un aspecto filosófico sobre el objetivo y el grupo objetivo de cada herramienta, mientras Composer da poder a los desarrolladores, WordPress se enfoca principalmente en las necesidades de los usuarios finales primero, y solo luego 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 que (a partir de ese momento) utilizará los procedimientos estándar para instalar temas y plugins. sin pasar por Composer. Sin embargo, el sitio y su archivo composer.json se desincronizan y el proyecto ya no se puede administrar de manera confiable a través de Composer: eliminar manualmente todos los plugins de la carpeta wp-content/plugins/ y ejecutar composer update no volverá a descargar los plugins agregados por el usuario final.

La alternativa a mantener el proyecto sincronizado sería pedirle al usuario que instale temas y plugins 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 install para instalar las dependencias de un tema o plugin agrega fricción, y WordPress no puede esperar que todos los usuarios puedan ejecutar esta tarea, por simple como puede ser. Por tanto, este enfoque no puede ser el predeterminado; en cambio, solo se puede usar si tenemos un control absoluto de la experiencia del usuario wp-admin/, como cuando construimos un sitio para nuestro propio cliente y brindamos capacidades sobre cómo actualizar el sitio.

El enfoque predeterminado, que maneja el caso cuando la parte que usa el software es desconocida, es lanzar temas y plugins con todas sus dependencias incluidas. Esto implica que las dependencias también deben cargarse en los repositorios de subversión de plugins y temas de WordPress, derrotando al propósito de Composer. Siguiendo este enfoque, los desarrolladores aún pueden usar Composer para el desarrollo, sin embargo, no para lanzar el software.

Este enfoque tampoco es a prueba de errores: si dos plugins diferentes agrupan diferentes versiones de una misma biblioteca que son incompatibles entre sí, y estos dos plugins están instalados en el mismo sitio, podría provocar un mal funcionamiento del sitio. Una solución a este problema es modificar el espacio de nombres de las dependencias a un 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 plugin 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 a otras bibliotecas, por lo tanto, la configuración debe considerar WordPress como una dependencia del sitio y no el sitio en sí. (Composer no toma una postura: esta decisión tiene el propósito práctico de poder usar 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 está instalado por defecto 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 composer.json obstinado con una configuración que funciona bien: el colaborador principal John P. Bloch proporciona un espejo del core de WordPress, y Roots proporciona una plantilla de WordPress llamada Bedrock. Voy a describir cómo utilizar cada uno de estos dos proyectos en las secciones siguientes.

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

He seguido la receta de Andrey “Rarst” Savchenko para crear el paquete Composer de todo el sitio, que hace uso del espejo de John P. Bloch del núcleo de WordPress. A continuación, reproduciré su método, agregando información adicional y mencionando las trampas que he encontrado en el camino.

Primero, cree un archivo composer.json con el siguiente contenido en la carpeta raíz del 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íjete a la carpeta raíz del proyecto en el terminal y ejecute 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 plugins 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 espera WordPress, 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 plugins en carpetas "wp/wp-content/themes" y "wp/wp-content/plugins", sin embargo, no se accederá a ellos.

Agrega el siguiente contenido 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! ¡Se han instalado el tema y los plugins! Puesto que todas las dependencias se distribuyen a través de carpetas wp, content/vendors, content/plugins y content/themes, podemos fácilmente ignorar estos cuando la comisión de nuestro proyecto bajo control de versiones a través de Git. Para ello, cree un archivo .gitignore con este contenido:

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 plugins, que probablemente no deben estar bajo el control de versiones.

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

// Load Composer’s autoloader
require_once (__DIR__.'/content/vendor/autoload.php');

// Move the location of the content dir
define('WP_CONTENT_DIR', dirname(__FILE__).'/content');

De forma predeterminada, WordPress establece una constante WP_CONSTANT_URL con valor get_option('siteurl').'/wp-content'. Debido a que hemos cambiado el directorio de contenido del 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_option ya que aún no se ha definido, por lo que debemos codificar el dominio o, posiblemente mejor, podemos recuperarlo de $_SERVER de esta 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 bajo domain.com/wp/ y proceder a instalar WordPress. Una vez que se completa la instalación, iniciamos sesión en el Panel de control y activamos el tema y los plugins.

Finalmente, debido a que WordPress se instaló en el subdirectorio wp, la URL contendrá la ruta «/wp» al acceder al sitio. Eliminemos eso (aunque no para el lado del administrador, que al acceder desde /wp/wp-admin/ agrega un nivel adicional de seguridad al sitio).

La documentación propone dos métodos para hacer esto: con o sin cambio de URL. Seguí a ambos y encontré el cambio sin URL 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íjete a «Configuración general» que encontrarás en domain.com/wp/wp-admin/options-general.php y elimina el /wp del valor «Dirección del sitio (URL)» y guarda. Después de hacerlo, el sitio se romperá momentáneamente: navegar por la página de inicio mostrará el contenido del directorio y navegar por una publicación de blog arrojará un 404. Sin embargo, no te preocupes, 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 has 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 estar comprometidos con Git:

1. .gitignore.
2. composer.json.
3. composer.lock: Este archivo es generado automáticamente por Composer, que contiene las versiones de todas las dependencias instaladas.
4. index.php: Este archivo se crea manualmente.
5. .htaccess: Este archivo es creado automáticamente por WordPress, por lo que podríamos evitar comprometerlo, sin embargo, pronto podremos personalizarlo 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 fue bastante fluido, sin embargo, podría mejorarse si se tratan mejor los siguientes problemas:

1. Parte del código de la aplicación no está comprometido bajo el control de versiones. Dado que contiene información del entorno, el archivo wp-config.php no debe estar comprometido con Git, sino que requiere 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 autocargador 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 a través de su procedimiento estándar, iniciar sesión en el Panel de control 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 para la misma tarea.

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

Bedrock es una plantilla de WordPress con una estructura de carpetas mejorada, que luce 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 adoptara la aplicación Twelve Factor, y explican cómo se logra esto a través de una serie de publicaciones en su blog. Esta estructura de carpetas se puede considerar una mejora con respecto a la de WordPress estándar en las siguientes partes:

• Agrega soporte para Composer al mover el núcleo de WordPress de la carpeta raíz a 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 se establece como la raíz del documento del servidor web (la amenaza de seguridad es que, si el servidor web deja de funcionar, no habría protección para bloquear el acceso a los archivos de configuración);
• La carpeta wp-content ha sido renombrada como “app”, que es un nombre más estándar ya que es usado por 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 limpiamente 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_name
DB_USER=database_user
DB_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=development
WP_HOME=http://example.com
WP_SITEURL=${WP_HOME}/wp

# Generate your keys here: https://roots.io/salts.html
AUTH_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 suspropias instrucciones. Primero crea un proyecto como este:

composer create-project "roots/bedrock" 

Este comando arrancará el proyecto Bedrock en una nueva carpeta «bedrock», configurando la estructura de la carpeta, 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 las salts, 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 plugins. Bedrock viene con temas: twenty twenty que se envían por defecto en la carpeta web/wp/wp-content/themes, pero cuando se agregan más temas a través de Composer, estos se instalan debajo 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 composer.json, por lo que ya podemos instalar temas y plugins desde este repositorio. Para hacerlo, simplemente pise la carpeta raíz del proyecto y ejecute el comando composer require para cada tema y plugin a instalar (este comando ya instala la dependencia, por lo que no es necesario ejecutar composer update):

cd bedroot
composer 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 carpeta web. Una vez hecho esto, diríjete a domain.com en el navegador y la pantalla de instalación de WordPress nos dará una feliz bienvenida. Una vez que se completa la instalación, podemos acceder al administrador de WordPress domain.com/wp/wp-admin y activar el tema y los plugins 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 compromete 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 oportunidad maravillosa para repensar cómo creamos sitios de WordPress para aprovechar al máximo las nuevas herramientas y tecnologías. 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 son fáciles de probar y corregir.

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 constante 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 se resuelva este problema, ya que varios actores tomaron el asunto en sus propias manos para brindar una solución.

En este artículo, revisamos dos proyectos que brindan una integración entre WordPress y Composer: configurar manualmente nuestro archivo composer.json según el espejo de John P. Bloch del núcleo de WordPress y Bedrock by Roots. Vimos cómo estas dos alternativas, que ofrecen una cantidad diferente de libertad para dar forma a la estructura de carpetas del proyecto, y que son más o menos fluidas durante el proceso de instalación, pueden cumplir con nuestro requisito de administrar completamente un sitio de WordPress, incluida la instalación de el núcleo, los temas y los plugins.

Si tienes alguna experiencia usando WordPress y Composer juntos, ya sea a través de cualquiera de los dos proyectos descritos o cualquier otro, me encantaría ver tu opinión en los comentarios.