WP Composer: el reemplazo abierto e independiente de WPackagist para gestionar plugins y temas con Composer

Durante más de una década, WPackagist fue el camino “por defecto” para instalar plugins y temas de WordPress mediante Composer (el gestor de dependencias de PHP). Era práctico: tratabas plugins y themes como paquetes versionados y repetibles, y los integrabas en tu composer.json como cualquier otra dependencia.

El problema es que, cuando una pieza tan central del flujo de trabajo pasa a estar controlada por una única corporación, la comunidad pierde margen de maniobra: disponibilidad, condiciones, prioridades de mantenimiento y dirección del proyecto pueden dejar de decidirse de forma abierta.

En marzo de 2026, WPackagist fue adquirido por WP Engine. A partir de ahí, el debate dejó de ser puramente técnico: ¿debería una infraestructura tan crítica para el ecosistema WordPress + Composer depender de una sola compañía? En respuesta a esa preocupación, Roots ha creado WP Composer.

Qué es WP Composer y por qué es relevante

WP Composer es un repositorio de Composer para WordPress, independiente, financiado por la comunidad y completamente open source, construido y mantenido por Roots. Su objetivo es cubrir el mismo caso de uso principal: permitirte instalar plugins y temas gratuitos del directorio de WordPress.org usando Composer, pero con un enfoque más transparente, más moderno y con mejor rendimiento.

La relevancia práctica para desarrolladores es clara: el repositorio que uses impacta directamente en tu DX (Developer Experience), en la reproducibilidad de despliegues, y en tiempos de resolución de dependencias cuando tu proyecto crece.

Qué problemas había alrededor de WPackagist

WPackagist fue creado originalmente por Outlandish y se mantuvo durante años. Con el tiempo, el proyecto arrastró señales típicas de abandono: actualizaciones lentas, mantenimiento limitado y poca o nula participación significativa de la comunidad en su evolución.

La adquisición por WP Engine intensificó esas inquietudes, especialmente por el componente de gobernanza: cuando una herramienta base queda en manos de una sola empresa, las decisiones clave pueden moverse de un contexto abierto a uno corporativo. Además, existe incertidumbre sobre si WPackagist sigue siendo realmente open source en la práctica: su repositorio público en GitHub (https://github.com/outlandishideas/wpackagist) ya no refleja el sitio en producción.

Qué ofrece WP Composer (y cómo se usa)

WP Composer publica cada plugin y tema gratuito del directorio de WordPress.org como paquetes instalables con Composer, con un esquema de nombres más limpio y consistente:

{
  "repositories": [
    {
      "name": "wp-composer",
      "type": "composer",
      "url": "https://repo.wp-composer.com",
      "only": ["wp-plugin/*", "wp-theme/*"]
    }
  ],
  "require": {
    "wp-plugin/woocommerce": "^10.0",
    "wp-theme/twentytwentyfive": "^1.0"
  }
}

{
  "repositories": [
    {
      "name": "wp-composer",
      "type": "composer",
      "url": "https://repo.wp-composer.com",
      "only": ["wp-plugin/*", "wp-theme/*"]
    }
  ],
  "require": {
    "wp-plugin/woocommerce": "^10.0",
    "wp-theme/twentytwentyfive": "^1.0"
  }
}

La convención es simple:

• Los plugins usan el prefijo wp-plugin/*.
• Los temas usan el prefijo wp-theme/*.
• Se eliminan los prefijos históricos wpackagist-plugin y wpackagist-theme.

Encaje con los paquetes de WordPress core en Composer

WP Composer también es el repositorio recomendado para combinar con los paquetes de WordPress core mantenidos por Roots:

• roots/wordpress
• roots/wordpress-full
• roots/wordpress-no-content

En un proyecto típico con Bedrock, el patrón habitual es: roots/wordpress para el core y WP Composer para plugins y temas.

Migrar desde WPackagist: pasos y comandos

Si ya vienes de WPackagist, el cambio es directo. La idea es: eliminar paquetes con el naming antiguo, sustituir el repositorio y volver a requerirlos con el naming nuevo.

1) Elimina los paquetes de WPackagist

composer remove wpackagist-plugin/woocommerce wpackagist-theme/twentytwentyfive

composer remove wpackagist-plugin/woocommerce wpackagist-theme/twentytwentyfive

2) Sustituye el repositorio configurado en Composer

composer config --unset repositories.wpackagist && composer config repositories.wp-composer composer https://repo.wp-composer.com

composer config --unset repositories.wpackagist && composer config repositories.wp-composer composer https://repo.wp-composer.com

3) Requiere de nuevo los paquetes con el naming de WP Composer

composer require wp-plugin/woocommerce wp-theme/twentytwentyfive

composer require wp-plugin/woocommerce wp-theme/twentytwentyfive

Opción: script de migración automática

Si prefieres automatizar el ajuste del composer.json, existe un script oficial que realiza la migración de forma automática:

curl -sO https://raw.githubusercontent.com/roots/wp-composer/main/scripts/migrate-from-wpackagist.sh && bash migrate-from-wpackagist.sh

curl -sO https://raw.githubusercontent.com/roots/wp-composer/main/scripts/migrate-from-wpackagist.sh && bash migrate-from-wpackagist.sh

Si usas GitHub Actions para changelogs de plugins

En entornos donde se automatiza el seguimiento de actualizaciones (por ejemplo, generando changelogs), Roots también renombró su acción: WPackagist Changelog Action pasa a ser WP Composer Changelog Action, con soporte completo para el formato wp-plugin/<em> y wp-theme/</em>.

Rendimiento: por qué WP Composer es mucho más rápido

Además de la independencia y la transparencia, WP Composer pone mucho foco en rendimiento. La clave técnica es que soporta el protocolo metadata-url de Composer v2, que permite descargar metadatos solo de los paquetes necesarios para resolver tus dependencias.

En cambio, WPackagist se basa en el enfoque más antiguo provider-includes, que obliga a Composer a descargar índices grandes con metadatos de miles de paquetes antes de poder resolver lo que realmente necesitas. En proyectos con muchas dependencias, esto se nota (y bastante).

Tiempos de resolución (Composer resolve)

Medición de cold resolve (sin caché): cuanto más bajo, mejor.

• 10 plugins: WP Composer 0.7s vs WPackagist 12.3s (17x faster)
• 20 plugins: WP Composer 1.1s vs WPackagist 19.0s (17x faster)

Metadatos y caché

• Compatibilidad con metadata-url de Composer v2: WP Composer sí, WPackagist no.
• CDN caching: WP Composer usa public, max-age=300; WPackagist usa no-cache, private.
• Ficheros por paquete: WP Composer utiliza ficheros inmutables, content-addressed y cacheados indefinidamente; WPackagist no es content-addressed.

Open source de verdad: código, documentación y despliegue

WP Composer publica todo el proyecto como open source: código de la aplicación, documentación y configuración de despliegue. El repositorio está en GitHub: https://github.com/roots/wp-composer.

Esto no es solo un detalle filosófico: significa que cualquiera puede auditarlo, contribuir, hacer un fork y levantar su propia instancia si lo necesita.

Financiación por la comunidad (sin dependencias corporativas)

WP Composer se financia íntegramente por la comunidad a través de GitHub Sponsors: https://github.com/sponsors/roots. Ese soporte se destina a infraestructura, desarrollo y mantenimiento de WP Composer y del ecosistema Roots en general.

Si tu stack de WordPress depende de Composer (especialmente en setups tipo Bedrock), este modelo de financiación es lo que mantiene la herramienta independiente y disponible de forma libre.

Resumen: qué cambia para tu día a día

• Un repositorio de Composer para WordPress independiente y con gobernanza más abierta.
• Naming limpio y coherente: wp-plugin/<em> y wp-theme/</em>.
• Mejores tiempos de resolución gracias a metadata-url (Composer v2).
• Migración sencilla con comandos o script automático.
• Código y despliegue completamente open source en GitHub.
• Financiación comunitaria vía GitHub Sponsors, reduciendo dependencia de una sola empresa.