WP Composer : un dépôt Composer ouvert et communautaire pour remplacer WPackagist

Pendant plus de dix ans, WPackagist a été la pièce quasi incontournable pour gérer des plugins et des thèmes WordPress avec Composer (le gestionnaire de dépendances PHP). Si tu as déjà maintenu un projet WordPress “moderne” (Bedrock, CI/CD, déploiements reproductibles), tu as forcément croisé les préfixes wpackagist-plugin/<em> et wpackagist-theme/</em> dans un composer.json.

Sauf qu’en mars 2026, WPackagist a été racheté par WP Engine. Au-delà du simple rachat, c’est la question de la centralisation qui se pose : une brique aussi structurante du workflow WordPress + Composer ne devrait pas dépendre d’une seule entreprise. C’est précisément dans ce contexte qu’un nouveau dépôt apparaît : WP Composer.

WP Composer, c’est quoi exactement ?

WP Composer est un dépôt Composer dédié à WordPress, indépendant, financé par la communauté et entièrement open source, construit et maintenu par l’équipe Roots. L’objectif est clair : proposer une alternative durable et transparente à WPackagist pour l’installation des extensions et thèmes issus du répertoire WordPress.org.

Pourquoi le remplacement de WPackagist est devenu un sujet ?

À l’origine, WPackagist a été créé par Outlandish et maintenu pendant des années. Mais sur sa période plus récente, le service a souffert d’un manque d’attention : mises à jour plus lentes, maintenance limitée, et très peu de place pour des retours ou une gouvernance communautaire.

Le rachat par WP Engine accentue ces inquiétudes : quand l’outillage de base est contrôlé par une seule organisation, la communauté perd mécaniquement sa voix. Les décisions structurantes (disponibilité, tarification potentielle, orientation) se prennent alors en interne plutôt qu’au grand jour. Autre signal problématique : le dépôt GitHub historique de WPackagist n’est plus représentatif de ce qui tourne réellement en production : https://github.com/outlandishideas/wpackagist.

L’idée derrière WP Composer est donc de remettre au centre une approche ouverte, auditable et financée par les utilisateurs plutôt que dépendante d’un acteur unique.

Ce que WP Composer apporte concrètement

WP Composer fournit chaque plugin et thème gratuit du répertoire WordPress.org, installable via Composer, avec un nommage plus propre et plus direct :

{
  "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 convention est simple :

• Les plugins utilisent wp-plugin/*.
• Les thèmes utilisent wp-theme/*.
• Fin des préfixes wpackagist-plugin et wpackagist-theme.

Autre point important si tu es dans l’écosystème Roots : WP Composer est le dépôt recommandé pour fonctionner avec les packages WordPress core de Roots, notamment roots/wordpress, roots/wordpress-full, et roots/wordpress-no-content. Dans un projet Bedrock, le schéma typique consiste à utiliser roots/wordpress pour le cœur WordPress et WP Composer pour les plugins et thèmes.

Migration depuis WPackagist : la procédure propre (et reproductible)

Le passage de WPackagist à WP Composer se fait en quelques commandes. L’idée est de (1) retirer les anciens packages, (2) remplacer la configuration du dépôt, puis (3) réinstaller avec le nouveau nommage.

1) Supprimer les packages WPackagist

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

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

2) Remplacer le dépôt configuré dans 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) Réinstaller avec le nouveau nommage wp-plugin/<em> et wp-theme/</em>

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

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

Alternative : script de migration automatique

Si tu veux mettre à jour ton composer.json sans le faire à la main, un script est disponible ici : https://github.com/roots/wp-composer/blob/main/scripts/migrate-from-wpackagist.sh. Exécution en une ligne :

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

Enfin, si tu utilisais la GitHub Action de suivi des mises à jour côté WPackagist, elle a été renommée en WP Composer Changelog Action et supporte pleinement le nouveau format wp-plugin/<em> et wp-theme/</em> : https://github.com/roots/wp-composer-changelog-action.

Performances : pourquoi WP Composer peut être beaucoup plus rapide

Le point technique le plus intéressant, c’est l’utilisation du protocole metadata-url de Composer v2, qui permet à Composer de récupérer uniquement les métadonnées des packages nécessaires à la résolution. À l’inverse, WPackagist s’appuie encore sur l’approche provider-includes, qui pousse Composer à télécharger de gros fichiers d’index contenant les métadonnées de milliers de packages avant de pouvoir résoudre les dépendances.

Temps de résolution (cold resolve) – plus bas = mieux

Mesure sur une résolution à froid (sans cache) :

• 10 plugins : WP Composer 0,7 s vs WPackagist 12,3 s (≈ 17× plus rapide)
• 20 plugins : WP Composer 1,1 s vs WPackagist 19,0 s (≈ 17× plus rapide)

Métadonnées & cache : les différences qui comptent en CI/CD

• Support du metadata-url (Composer v2) : WP Composer Oui ; WPackagist Non.
• Cache CDN : WP Composer renvoie public, max-age=300 ; WPackagist renvoie no-cache, private.
• Fichiers par package : WP Composer utilise des fichiers immuables, adressés par contenu (content-addressed) et mis en cache indéfiniment ; WPackagist n’est pas content-addressed.

Un projet entièrement open source (et forkable)

WP Composer ne se limite pas à publier un endpoint : l’application, la documentation et la configuration de déploiement sont disponibles publiquement sur GitHub : https://github.com/roots/wp-composer. Les contributions sont ouvertes, et il est possible de forker le projet et d’exécuter sa propre instance – un point clé quand on parle d’infrastructure critique.

Financement communautaire : comment le service reste indépendant

Le financement de WP Composer repose entièrement sur la communauté via GitHub Sponsors : https://github.com/sponsors/roots. Le sponsoring sert à couvrir l’infrastructure, le développement et la maintenance de WP Composer, ainsi que l’écosystème Roots plus largement.

Pour le suivi et les échanges techniques autour de l’annonce, une discussion est ouverte sur Discourse : https://discourse.roots.io/t/-/30235.

Récap : ce que ça change pour nos projets WordPress gérés avec Composer

• Tu peux installer plugins et thèmes WordPress.org via un dépôt Composer indépendant : https://repo.wp-composer.com.
• Le nommage devient plus clair : wp-plugin/<em> et wp-theme/</em>.
• La migration depuis WPackagist est simple (commandes) ou automatisable (script).
• Les performances de résolution peuvent être nettement meilleures grâce à metadata-url (Composer v2) et une stratégie de cache plus adaptée.
• Le code est auditable et déployable ailleurs : le projet est entièrement open source sur GitHub.
• Le modèle économique annoncé repose sur la communauté (GitHub Sponsors), pour éviter une dépendance à un acteur unique.