WP Composer : pourquoi Roots.io a remplacé WPackagist (et ce que ça change vraiment)

Mis à jour en 2026

Le rachat de WPackagist par WP Engine en mars 2026 a provoqué une onde de choc discrète mais réelle dans l’écosystème WordPress professionnel.

Pour beaucoup, WPackagist était transparente : un registry Composer qui convertit les plugins et thèmes du répertoire officiel en packages installables via composer.json. On l’utilisait sans y penser. Jusqu’au jour où Roots.io a tiré la sonnette d’alarme, et proposé une alternative solide : WP Composer.

Si vous gérez des projets WordPress avec Bedrock, Trellis ou simplement Composer dans un workflow CI/CD, cette migration vous concerne directement.

WPackagist : les problèmes qui couvaient

Avant même le rachat, WPackagist accumulait des signaux préoccupants :

• Des délais de mise à jour parfois importants entre la sortie d’un plugin et sa disponibilité via le registry
• Un manque de maintenance visible sur le dépôt GitHub, dont le code source ne reflétait plus ce qui tournait en production
• Un statut open source ambigu : le projet se revendiquait open source, mais sans transparence réelle sur l’infrastructure déployée

Le rachat par WP Engine a cristallisé ces inquiétudes. WP Engine est un acteur commercial majeur. Céder le contrôle d’une dépendance critique de votre toolchain à une entité privée, sans garantie de continuité ni de neutralité, c’est un risque opérationnel concret pour des équipes qui automatisent leurs déploiements.

WP Composer : ce que Roots a construit (et pourquoi c’est mieux)

Un protocole Composer v2 natif

C’est là que la différence est la plus tangible. WPackagist utilisait encore le protocole provider-includes, hérité de Composer v1. Ce protocole oblige Composer à télécharger des fichiers d’index massifs (couvrant des milliers de packages) avant même de commencer à résoudre les dépendances de votre projet.

WP Composer implémente le protocole moderne metadata-url de Composer v2. Il ne récupère que les métadonnées strictement nécessaires à la résolution. Le gain de performance est spectaculaire.

Selon les benchmarks publiés par Roots avec Composer 2.7+ :

Scénario	WP Composer	WPackagist	Gain
10 plugins	0,7 s	12,3 s	17x plus rapide
20 plugins	1,1 s	19,0 s	17x plus rapide

Un CDN avec une vraie stratégie de cache

WPackagist renvoyait des headers no-cache, private. Concrètement : impossible de mettre en cache les réponses en amont, ni localement, ni sur un CDN.

WP Composer adopte une approche inverse : public, max-age=300, avec des fichiers par package immuables et adressés par leur contenu (content-addressed). Le cache est efficace, les ressources peuvent être distribuées via CDN.

L’impact concret sur un workflow CI/CD avec Trellis

Prenons un cas réel. Sur un déploiement Trellis standard avec Bedrock — disons une quinzaine de plugins dans le composer.json — la phase de résolution et d’installation des dépendances représente généralement 1 à 2 minutes d’un pipeline qui en dure 4 au total.

Avec WP Composer, cette phase passe sous les 10 secondes en résolution à froid. Sur des runs avec cache Composer activé (ce que la plupart des setups GitHub Actions ou Bitbucket Pipelines font déjà), le gain est moindre mais reste perceptible.

À l’échelle d’une équipe qui déploie plusieurs fois par jour, sur plusieurs environnements (staging, production, review apps), ces secondes s’accumulent rapidement en minutes économisées — et en frustration évitée lors d’un hotfix en urgence.

Migrer de WPackagist à WP Composer

Nouveau nommage des packages

Le changement le plus visible : le préfixe des packages change.

// Avant (WPackagist)
"wpackagist-plugin/woocommerce": "^9.0",
"wpackagist-theme/twentytwentyfive": "*"

// Après (WP Composer)
"wp-plugin/woocommerce": "^9.0",
"wp-theme/twentytwentyfive": "*"

Mise à jour du repository dans composer.json

{
  "repositories": [
    {
      "type": "composer",
      "url": "https://wp-composer.roots.io"
    }
  ]
}

Script de migration automatisé

Roots fournit un script shell pour automatiser la réécriture de votre composer.json :

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

Ce script renomme les packages en masse. Vérifiez le diff avant de commiter, mais en pratique il fonctionne de manière fiable sur des projets Bedrock standards.

GitHub Action

Si vous utilisez la WPackagist Changelog Action dans vos workflows CI pour suivre les mises à jour de plugins, elle a été renommée en « WP Composer Changelog Action » et supporte nativement le nouveau format wp-plugin/* / wp-theme/*.

Checklist de migration

•  Remplacer le repository WPackagist par https://wp-composer.roots.io dans composer.json
•  Lancer le script de migration pour renommer les packages
•  Vérifier que toutes les références wpackagist-plugin/ et wpackagist-theme/ ont bien disparu
•  Mettre à jour la GitHub Action si utilisée
•  Tester la résolution en local avec composer install --no-cache
•  Vérifier le pipeline CI sur une branche de test avant de merger en production

Open source et pérennité

Un point qui tranche avec la situation WPackagist : WP Composer est entièrement open source, code, documentation et configuration de déploiement compris. Le projet est financé via GitHub Sponsors.

C’est une différence de philosophie importante pour des équipes qui veulent auditer leurs dépendances critiques ou contribuer à les améliorer. La dépendance à un acteur commercial disparaît.

WP Composer est également compatible avec roots/wordpress, roots/wordpress-full et roots/wordpress-no-content — les packages Composer officiels de Roots pour intégrer le core WordPress dans une architecture Bedrock.

En pratique : faut-il migrer maintenant ou attendre ?

WPackagist continue de fonctionner pour le moment. Mais en pratique, pour un projet en production avec un workflow CI/CD actif, migrer dès maintenant présente peu de risques et des bénéfices immédiats en performance.

Le risque réel est de reporter la migration jusqu’à ce qu’une dégradation de service ou un changement de politique WP Engine vous y force dans l’urgence — ce qui n’est jamais le meilleur moment.

Pour les nouveaux projets Bedrock/Trellis, il n’y a aucune raison de démarrer avec WPackagist.

Si vous gérez plusieurs projets WordPress et que vous cherchez à rationnaliser votre stack, je détaille mon approche sur ma page dédiée au développement WordPress freelance.

WP Composer est-il compatible avec les versions antérieures de Composer ?

WP Composer utilise le protocole metadata-url introduit dans Composer v2. En pratique, Composer v2 est disponible depuis fin 2020 et est aujourd’hui la version par défaut sur tous les environnements modernes. Si votre environnement de build tourne encore sur Composer v1, une mise à jour s’impose de toute façon indépendamment de cette migration.

La migration casse-t-elle les lock files existants ?

Le composer.lock référence les packages par leur nom. Après renommage via le script de migration, il faut relancer composer install pour régénérer le lock file avec les nouveaux identifiants. Ce n’est pas une opération risquée, mais elle doit être faite consciemment et testée avant déploiement.

WP Composer couvre-t-il tous les plugins du répertoire WordPress ?

Oui. WP Composer indexe l’ensemble du répertoire officiel WordPress.org, comme le faisait WPackagist. Les plugins Premium (ACF Pro, Gravity Forms, etc.) qui n’y sont pas listés continuent de s’intégrer via des repositories Composer privés ou des packages vcs, indépendamment de WP Composer.

Sources : 

• Roots.io — Introducing WP Composer as a WPackagist Replacement 
• Composer v2 metadata protocol documentation