WP Composer: Ein unabhängiger Ersatz für WPackagist im WordPress-Composer-Workflow
Wer WordPress professionell mit Composer (PHP-Dependency-Manager) betreibt – etwa in modernen Deployments oder in Roots/Bedrock-Setups – kennt WPackagist als die lange Zeit naheliegende Lösung, um Plugins und Themes aus dem WordPress.org-Verzeichnis als Composer-Pakete zu beziehen. Genau diese Rolle bekommt seit März 2026 eine neue Dynamik: WPackagist wurde von WP Engine übernommen. Bei Infrastruktur, die so zentral im WordPress-Composer-Workflow sitzt, ist die Frage nach Unabhängigkeit, Transparenz und Mitgestaltung plötzlich nicht mehr akademisch, sondern ganz praktisch.
Mit WP Composer gibt es nun ein unabhängiges, community-finanziertes und vollständig Open-Source Composer-Repository für WordPress-Plugins und -Themes. Es wird von Roots aufgebaut und betrieben – mit dem Anspruch, zentrale Entwickler-Infrastruktur nicht in die Hand einer einzelnen Firma zu legen.
Warum das Thema gerade jetzt wichtig ist
WPackagist wurde ursprünglich von Outlandish aufgebaut und über viele Jahre gepflegt. In der späteren Phase gab es jedoch zunehmend Friktion: langsame Updates, begrenzte Wartung und kaum echte Community-Einbindung. Die Übernahme durch WP Engine hat diese Sorgen eher verstärkt als ausgeräumt.
Sobald grundlegende Developer-Tools von einer einzelnen Corporation kontrolliert werden, verschiebt sich das Machtzentrum: Entscheidungen zu Verfügbarkeit, Kosten und Ausrichtung fallen dann eher in Boardrooms als öffentlich und nachvollziehbar. Zusätzlich ist nicht klar, ob WPackagist in der Praxis weiterhin wirklich Open Source ist – das öffentliche Repository auf GitHub bildet die Live-Realität offenbar nicht mehr ab (siehe: GitHub-Repo von WPackagist).
Roots’ Position dazu ist klar: Es braucht eine Alternative, die transparent ist, von der Community getragen wird und von Leuten gebaut wird, die diese Art Infrastruktur seit Langem im WordPress-Umfeld betreiben.
Eine detaillierte Gegenüberstellung – inklusive Performance und Metadaten-Modell – findet sich hier: WP Composer vs WPackagist.
Was WP Composer konkret liefert
WP Composer stellt jedes kostenlose Plugin und jedes kostenlose Theme aus dem WordPress.org-Verzeichnis als Composer-Pakete bereit – mit einem deutlich aufgeräumteren Paket-Namensschema.
Statt der bekannten Präfixe wpackagist-plugin/<em> und wpackagist-theme/</em> setzt WP Composer auf:
- Plugins:
wp-plugin/* - Themes:
wp-theme/*
Damit sehen composer.json-Einträge spürbar „cleaner“ aus. Beispiel-Konfiguration:
{
"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"
}
}
Wichtig dabei: WP Composer ist auch das empfohlene Repository in Kombination mit den WordPress-Core-Paketen aus dem Roots-Ökosystem, konkret:
roots/wordpressroots/wordpress-fullroots/wordpress-no-content
In einem typischen Bedrock-Projekt kommt für den Core häufig roots/wordpress zum Einsatz, während Plugins und Themes über WP Composer eingebunden werden.
Migration: Von WPackagist auf WP Composer umstellen
Der Wechsel ist bewusst simpel gehalten und lässt sich in wenigen Schritten durchführen.
1) WPackagist-Pakete entfernen
composer remove wpackagist-plugin/woocommerce wpackagist-theme/twentytwentyfive
2) Repository-Konfiguration tauschen
composer config --unset repositories.wpackagist && composer config repositories.wp-composer composer https://repo.wp-composer.com
3) Pakete mit neuem Naming wieder hinzufügen
composer require wp-plugin/woocommerce wp-theme/twentytwentyfive
Alternative: Migrationsscript für composer.json
Wenn du viele Abhängigkeiten hast, ist das automatische Update der composer.json oft der angenehmere Weg. Dafür gibt es ein Script, das die Umstellung erledigt:
curl -sO https://raw.githubusercontent.com/roots/wp-composer/main/scripts/migrate-from-wpackagist.sh && bash migrate-from-wpackagist.sh
Auch im Umfeld von automatisiertem Plugin-Update-Tracking gibt es eine Anpassung: Die bisherige WPackagist Changelog Action wurde in WP Composer Changelog Action umbenannt und unterstützt das neue Naming-Format wp-plugin/<em> und wp-theme/</em> vollständig.
Performance: Warum WP Composer beim Resolve deutlich schneller ist
Der wichtigste technische Unterschied liegt im Metadaten-Transport: WP Composer unterstützt das Composer-v2-Protokoll metadata-url. Damit lädt Composer Metadaten gezielt nur für die Pakete, die tatsächlich gebraucht werden.
WPackagist setzt weiterhin auf den älteren Ansatz provider-includes. In der Praxis bedeutet das: Composer muss zuerst große Index-Dateien herunterladen, die Metadaten für tausende Pakete enthalten, bevor überhaupt sauber aufgelöst werden kann.
Composer-Resolve-Zeiten (Cold Resolve, ohne Cache)
Bei einem Cold Resolve (kein Cache) sind niedrigere Werte besser. Die folgenden Messwerte zeigen den Unterschied sehr deutlich:
- 10 Plugins: WP Composer 0,7s, WPackagist 12,3s → 17× schneller
- 20 Plugins: WP Composer 1,1s, WPackagist 19,0s → 17× schneller
Metadaten & Caching im Vergleich
- Composer v2
metadata-url: WP Composer Yes, WPackagist No - CDN-Caching: WP Composer
public, max-age=300, WPackagistno-cache, private - Per-Package-Files: WP Composer immutable, content-addressed, unbegrenzt cachebar; WPackagist nicht content-addressed
Die Benchmarks wurden von einem einzelnen Standort mit Composer 2.7+ ausgeführt; je nach Region und Netzwerkbedingungen können die Werte variieren. Die Benchmark-Skripte sind offen einsehbar: https://github.com/roots/wp-composer/tree/main/benchmarks
Vollständig Open Source – inklusive Deployment
Nicht nur das Ergebnis ist offen, sondern das gesamte Projekt: Anwendungscode, Doku und Deployment-Konfiguration sind auf GitHub verfügbar: https://github.com/roots/wp-composer. Beiträge sind ausdrücklich erwünscht – und wer möchte, kann das Projekt forken und eine eigene Instanz betreiben.
Community-finanziert statt Corporate-Control
WP Composer wird vollständig durch die Community über GitHub Sponsors finanziert: https://github.com/sponsors/roots. Damit fließt Unterstützung direkt in Infrastruktur, Weiterentwicklung und Wartung von WP Composer – und generell in das Roots-Ökosystem.
Gerade wenn Composer ein fester Bestandteil deines WordPress-Stacks ist, ist ein unabhängiges Repository keine Nebensache: Es entscheidet darüber, wie verlässlich, transparent und planbar dein Build- und Update-Prozess in den nächsten Jahren bleibt.
Referenzen / Quellen
Julia Schneider
Leiterin der deutschen Redaktion, Softwarearchitektin und technische Mentorin. Java- und Spring-Framework-Expertin. Präzision und Qualität über alles.
Alle Beiträge
