WP Packages von Roots: open source Composer-Repository für WordPress 2026

#Was Roots tatsächlich ausgeliefert hat

Im März 2026 hat das Roots-Team (Scott Walkinshaw, Ben Word und Mitwirkende) WP Packages auf wp-packages.org gestartet. Es spiegelt jedes kostenlose Plugin und Theme aus dem WordPress.org-Verzeichnis und liefert sie als Composer-JSON-Repository aus.

Der Launch lief nicht reibungslos. Das Projekt startete am Dienstag als “WP Composer”. Bis Freitag hatte Nils Adermann (Composer-Mitschöpfer, auch Mitwirkender an der SemVer-Spec) sich gemeldet und darauf hingewiesen, dass Composer eine vom Composer-Projekt gehaltene eingetragene Marke ist. Roots benannte über das Wochenende um, hielt die bestehenden wp-composer.org URLs mit 410 plus Deprecation-Hinweis arbeitsfähig und schob ein Bedrock-Template-Update raus, sodass neue Projekte auf den umbenannten Host zeigten. Diese Art Vorfall hätte bei einem Konzern-Anbieter sechs Wochen Rechtsprüfung benötigt. Open-Source-Projekte fixen das, bevor der Postmortem-Blog-Post landet.

#Die composer.json, die Ihr Dashboard ersetzt

{
  "repositories": [
    {
      "type": "composer",
      "url": "https://wp-packages.org"
    }
  ],
  "require": {
    "php": ">=8.2",
    "wp-packages/advanced-custom-fields": "^6.3",
    "wp-packages/woocommerce": "^9.4",
    "wp-packages/wordpress-seo": "^23.0"
  }
}

composer install löst dann einen Baum auf, schreibt composer.lock und lädt ZIPs nach web/app/plugins/ (Bedrock-Layout) oder wp-content/plugins/ (vanilla WordPress mit composer/installers). Auf einem 25-Plugin-Bedrock-Projekt läuft die Warm-Cache-Installation in 30 bis 90 Sekunden. Cold Cache, kein Composer-Cache-Verzeichnis, frischer CI-Runner: 2 bis 4 Minuten, hauptsächlich Download-Zeit. Diese Zahl zählt, sobald composer install in jeden PR-Build verkettet wird.

#Was Self-Hosting tatsächlich bringt

Self-Hosting von WP Packages ist das eine Feature, das WPackagist nicht bietet. Drei reale Szenarien aus dem deutschen Markt, in denen sich das auszahlt:

• DSGVO und Lieferkettenaudit. Behörden, Sparkassen, Versicherer und DAX-Konzerne fordern, dass jede Abhängigkeit aus selbst kontrollierter Infrastruktur ausgeliefert wird. Mit WP Packages forken Sie das Projekt, spiegeln es auf einen internen Endpoint bei Hetzner Cloud, IONOS Compute Engine oder einem internen Mittwald-Mirror, und Ihre composer.json spricht beim Deploy nicht mehr mit einem Drittanbieter-Host.
• Air-Gapped CI-Runner. Jenkins oder GitLab Runner in einer Behörden-VPN ohne Internetzugang erreichen weder wpackagist.org noch wp-packages.org. Mit selbst gehostetem WP Packages plus lokalem Composer-Cache ist die Deploy-Pipeline offline-clean.
• Custom Filtering. Ein realer Fall einer Berliner Agentur: Plugins, die seit über 18 Monaten kein Update bekommen haben, wurden auf der internen Infrastruktur als nicht installierbar markiert. Sie haben WP Packages geforkt, den Filter zur Indexierungszeit hinzugefügt, und composer require auf einem veralteten Plugin scheitert jetzt mit einer klaren Fehlermeldung statt verlassen Code stillschweigend zu installieren.

Für die meisten Teams reicht WPackagist. Die obigen sind die Fälle, in denen es nicht mehr reicht.

#WPackagist: immer noch der Default und das aus gutem Grund

WPackagist wird von Outlandish betrieben, einer britischen Genossenschaft. Es spiegelt das WordPress.org-Verzeichnis seit 2013 mit sehr wenigen Ausfällen. Die Paketnamenkonvention (wpackagist-plugin/woocommerce, wpackagist-theme/twentytwentyfour) wurde zur De-facto-Konvention; nahezu jedes deutsche Bedrock-Tutorial vor März 2026 (etwa von Inpsyde Engineering, Stayonline-Blog) setzt WPackagist voraus.

#Vergleich

#Wann wechseln, wann nicht

Wechseln Sie zu WP Packages wenn Sie Self-Hosting benötigen, bereits den gesamten Roots-Stack standardisiert haben und Single-Vendor-Support bevorzugen, oder wenn Sie eine WPackagist-Sync-Verzögerung erlebt haben, die einen Build kaputt gemacht hat, und einen zweiten Mirror als Backup wollen. Bleiben Sie bei WPackagist wenn Ihr CI grün ist, Ihre composer.lock reproduzierbar ist und “lasst uns das Vendor-Präfix auf 200 Kundenseiten migrieren” auf niemandes Roadmap steht.

Die zwei schließen sich nicht aus. Nichts hindert Sie daran, beide Repositories zu deklarieren und einzelne Plugins an einzelne Mirrors zu pinnen. Das wird in der Praxis bei den meisten Agenturen herauskommen.

#Bedrock, Sage, Trellis: wo Composer sich tatsächlich auszahlt

Der Roots-Stack ist der Grund, warum sich Composer-auf-WordPress nativ statt drangeschraubt anfühlt.

#Bedrock: das Projektlayout

Bedrock ist ein Projekt-Skeleton, kein Framework. Was es tatsächlich tut:

• Trennt WordPress-Core in web/wp/ (Composer-verwaltet), sodass wp-config.php ein dünner Loader statt der kanonischen Konfigurationsdatei ist.
• Verschiebt die gesamte Umgebungskonfiguration in .env (gelesen von vlucas/phpdotenv) und config/environments/{development,staging,production}.php. Die WP_ENV Konstante steuert welche Umgebungsdatei geladen wird.
• Behandelt web/app/plugins/, web/app/themes/ und web/app/mu-plugins/ als Composer-Installationsziele über composer/installers.
• Liefert einen mu-plugins/register-theme-directory.php Autoloader, sodass composer require auf einem Theme dieses tatsächlich bei WordPress registriert.

.env ist gitignored. Produktionsgeheimnisse leben im Secret-Manager (HashiCorp Vault, AWS Secrets Manager), nicht in wp-config.php. Das ist der Vertrag, der WP_DEBUG, ACF-Pro-Lizenzschlüssel und Datenbank-Credentials pro Umgebung sicher macht. Für DSGVO-Compliance ist diese Trennung praktisch unverzichtbar: API-Keys und Datenbank-Credentials gehören in geheime Speicher mit Auditierbarkeit, nicht in versionierte Dateien.

composer create-project roots/bedrock mein-projekt
cd mein-projekt
cp .env.example .env
# .env mit lokalen DB-Credentials und WP_ENV=development bearbeiten
composer install

Deutsche Hoster-Lage für Bedrock: Mittwald hat SSH und Composer nativ in mStudio, mit dokumentierter Bedrock-Anleitung. Raidboxes hat ein offizielles Bedrock-Template seit 2024 und Composer-Support auf den Pro-Tarifen. Hetzner Cloud Server geben Ihnen Root-Zugriff für beliebige Toolchain-Konfigurationen. IONOS Webhosting Premium ab dem Business-Tarif hat SSH; darunter wird es eng. Strato Hosting Plus L hat SSH; Strato Hosting Plus S nicht. Vermeiden Sie Shared-Hosting ohne SSH; im Jahr 2026 ist Composer-Build-am-Server ein Antipattern.

#Sage 10 zu Sage 11: die Migrationssteuer

Sage ist das Roots-Theme. Sage 11 (2024 veröffentlicht) brachte Acorn, einen Laravel-artigen Container, der innerhalb von WordPress läuft, plus Blade-Templates statt einfaches PHP. Sage-10-zu-Sage-11-Migrationen haben spezifische Failure-Modes, die man kennen sollte, bevor man unterschreibt:

• Acorn Breaking Changes. Über Acorns Service-Provider-Mechanismus registrierte Hooks feuern später als dieselben Hooks in functions.php. Code, der init mit Priorität 10 voraussetzt, muss möglicherweise auf Priorität 20 oder einen anderen Hook umziehen.
• Blade vs PHP-Templates. single.blade.php statt single.php. Alte get_template_part-Aufrufe funktionieren noch, umgehen aber die Blade-Pipeline und verlieren die Section/Yield-Mechanik.
• Asset-Pipeline. Sage 10 nutzte Bud (Webpack-5-Wrapper); Sage 11 zog auf Vite um. Bud-Konfigurationsdateien sind nicht portabel. Ihre tailwind.config.js schon, aber achten Sie auf Unterschiede in der PostCSS-Plugin-Reihenfolge.

Die Migration ist nicht Knopfdruck. Planen Sie zwei Tage für ein kleines Theme, eine Woche für alles mit benutzerdefinierten Gutenberg-Blöcken.

#Trellis: die Option, die Sie wahrscheinlich nicht brauchen

Trellis ist Ansible plus Vagrant für lokale Entwicklung und Remote-Provisionierung. Es baut Ubuntu-LTS-Server mit Nginx, MariaDB, PHP-FPM, Redis und einer Deploy-Pipeline. Klartext: Trellis ist ausgezeichnet für Agenturen, die ihre eigene Infrastruktur betreiben (50 bis 200 Sites auf Hetzner-Dedis oder IONOS Cloud Servern) und übertrieben für alle anderen. Wenn Sie auf Managed WordPress Hosting deployen (Raidboxes, Mittwald, Kinsta), ist Trellis nicht das richtige Werkzeug. Wenn Sie Ihre eigene DigitalOcean- oder Hetzner-Flotte betreiben, schon.

#Failure-Modes, die in der Einleitung niemand erwähnt

Das sind die vier Wege, auf denen composer install jemandem den Nachmittag ruiniert.

#PHP-Versions-Drift zwischen lokal und CI

composer require löst gegen die PHP-Version auf, die es heute sieht. Ein Plugin mit "php": ">=8.2" installiert auf Ihrem Laptop mit PHP 8.3 problemlos. Eine auf PHP 8.1 eingefrorene Staging-Umgebung scheitert bei composer install mit einem unhilfreichen Platform-Requirement-Fehler. Pinnen Sie config.platform.php in composer.json auf die niedrigste Version, die irgendeine Umgebung ausführt:

{
  "config": {
    "platform": {
      "php": "8.2.20"
    }
  }
}

Diese eine Zeile rettet mehr Deploys als jede CI-Optimierung. Besonders relevant für deutsche Shared-Hoster, wo PHP 8.1 und 8.2 im Jahr 2026 noch Default auf älteren Strato- und IONOS-Tarifen sind.

#mu-plugins/register.php gegen die falsche WordPress-Version geladen

Bedrocks mu-plugins/-Autoloader läuft zur PHP-Boot-Zeit, vor der WordPress-Core-Initialisierung. Wenn Sie composer update auf eine WordPress-Core-Version machen, die die Semantik von WP_PLUGIN_DIR geändert hat (passierte in WP 6.5), kann der Autoloader Theme-Verzeichnisse registrieren, die nicht mehr existieren. Symptom: weißer Bildschirm auf Produktion, OK auf Staging. Fix: roots/wordpress auf eine bekannt gute Minor-Version pinnen und bewusst bumpen.

#ACF-Pro-Lizenzaktivierung in Deploy-Umgebungen

ACF Pro authentifiziert seine Lizenz gegen advancedcustomfields.com. Deploy-Artefakt-Builds (Bitbucket Pipelines, GitHub Actions) laufen als frischer Container ohne DOM, ohne Admin-Sitzung und mit einer IP, die der ACF-Lizenzserver nie gesehen hat. Der Aktivierungs-Flow, der in wp-admin funktioniert, funktioniert in einem CI-Runner nicht. Fixes, die in 2026 tatsächlich funktionieren:

• Verwenden Sie den Roots-Premium-Proxy, wenn Sie auf einem Roots-Organisationsplan sind (er vermittelt ACF Pro und andere Premium-Lizenzen über Composer).
• Setzen Sie ACF_PRO_LICENSE als Umgebungsvariable, die von der ACF-PHP-API gelesen wird, und überspringen Sie den Dashboard-Aktivierungs-Flow komplett.
• Verwenden Sie Composer HTTP Basic Auth (auth.json), um sich gegen den offiziellen ACF-Composer-Endpoint auf connect.advancedcustomfields.com zu authentifizieren.

Die ersten beiden sind die einzigen, die eine Servermigration ohne manuelle Eingriffe überstehen.

#Composer 2.7 vs Composer 2.6 Lockfile-Inkompatibilität

Composer 2.7 änderte, wie composer.lock Plattform-Overrides aufzeichnet. Eine von 2.7 geschriebene composer.lock scheitert bei der Installation auf 2.6 mit einem irreführenden “the lock file is not up to date” Fehler. Standardisieren Sie die Composer-Version in CI (composer self-update 2.7.7) und dokumentieren Sie sie in der README. Ja, das ist nervig. Ja, es hat genug Teams gebissen, dass Composer 2.8 explizit warnen wird.

#Premium-Plugins: der Teil, den die Docs überspringen

Die Hälfte der Plugins auf einer realen Kundensite ist nicht im WordPress.org-Verzeichnis. ACF Pro, Gravity Forms, WP Migrate, GP Premium, FacetWP, WP All Import Pro, Borlabs Cookie (im DACH-Markt fast unvermeidlich für DSGVO-konforme Cookie-Banner). Composer-Support variiert stark:

• ACF Pro: offizieller Composer-Endpoint auf connect.advancedcustomfields.com. Funktioniert gut, benötigt auth.json mit Lizenzschlüssel als Passwort.
• Gravity Forms: offizieller Composer-Support seit 2023. Lizenzschlüssel in auth.json, Paketname gravityforms/gravityforms.
• Borlabs Cookie: kein offizieller Composer-Endpoint. SatisPress oder ZIP in privatem Repository.
• WP Migrate Pro (Delicious Brains, jetzt WP Engine): ZIP-Download mit lizenzgeschütztem URL. Custom Composer-Repository, das das Paket als package-Typ mit URL inline deklariert, oder Proxy über SatisPress.
• WP All Import Pro: kein Composer-Endpoint. ZIPs gehostet auf einem lizenzgeschützten URL. SatisPress oder ZIP in privatem Repository commiten.

Drei Patterns decken alle ab:

1. Roots Premium (roots.io/premium). Ein verwalteter Composer-Proxy, der Lizenzen für ACF Pro, Gravity Forms und andere handhabt. Preis individuell; bei Agenturen mit 50+ Sites geht die Rechnung normalerweise auf.
2. SatisPress. Ein WordPress-Plugin, das Ihre eigene WordPress-Installation in ein Composer-Repository verwandelt. Premium-Plugins normal installieren, über https://ihr-privater-host/satispress/ exponieren, mit HTTP Basic Auth absichern.
3. Private Packagist von packagist.com. Gehostetes Composer-Repository mit privater Paketunterstützung. Kostet mehr als SatisPress, benötigt null Infrastruktur.

Was auch immer Sie wählen, die Regel: Lizenzschlüssel kommen niemals in eine in Git eingecheckte composer.json oder auth.json. Sie leben in Umgebungsvariablen, die zur Installationszeit gelesen werden, oder in CI-Secrets, die während des Build-Schritts in auth.json injiziert werden. DSGVO-Konformität verlangt explizit eine Trennung zwischen Quellcode-Repositories und Geheimnisspeichern.

#CI-Integration, die die Realität überlebt

Eine funktionierende Deploy-Pipeline:

# .github/workflows/deploy.yml (Auszug)
- name: Set up PHP 8.2
  uses: shivammathur/setup-php@v2
  with:
    php-version: '8.2'
    tools: composer:2.7

- name: Cache Composer
  uses: actions/cache@v4
  with:
    path: ~/.composer/cache
    key: composer-${{ hashFiles('composer.lock') }}

- name: Install
  run: composer install --no-dev --optimize-autoloader --prefer-dist --no-interaction
  env:
    COMPOSER_AUTH: ${{ secrets.COMPOSER_AUTH_JSON }}

- name: Deploy artifact
  run: rsync -avz --delete --exclude='.git' --exclude='node_modules' ./ deploy@host:/var/www/html/

Drei Regeln, die Debugging-Zeit sparen:

• Niemals composer update in CI. Lokal updaten, neue composer.lock committen, pushen. CI führt composer install gegen exakt diese Lockfile aus.
• Cachen Sie ~/.composer/cache mit dem composer.lock-Hash als Key. Cold Installs gehen von 4 Minuten auf 30 Sekunden runter.
• Injizieren Sie auth.json aus einem Secret. Die Umgebungsvariable COMPOSER_AUTH wird von Composer nativ gelesen. Niemals lizenzierte Credentials commiten.

#Was sich 2026 in der WordPress-Kultur geändert hat

Composer-auf-WordPress war früher eine Roots-Shop-Sache. Im Jahr 2026 ist es der Default für jede deutsche Agentur oder jedes Inhouse-Team, das auf mehr als eine Umgebung deployt. Drei Signale aus dem breiteren Ökosystem:

• WordPress.org-Plugin-Einreichungen überschritten Anfang 2026 die 500 pro Woche, gestiegen von 100 bis 150 wöchentlich in 2022 bis 2024 (Quelle: wöchentliche Plugin-Review-Team-Berichte). Der Großteil des neuen Volumens ist KI-assistierter Code. Das Plugins-Team rekrutiert ehrenamtliche Reviewer; die Qualitätshürde des Verzeichnisses ist unter Druck.
• Sowohl Kinsta als auch WP Engine fügten Ende 2025 native Composer-Build-Unterstützung zu ihrem Git-Push-Deployment hinzu. Mittwald und Raidboxes folgten im ersten Quartal 2026. Die Kategorie “Managed WordPress Hosting, das composer.json ignoriert” schrumpft.
• WP-CLI 2.10 fügte wp composer Subkommandos hinzu, die composer install, composer update und Lockfile-Validierung kapseln. Composer wird Teil der offiziellen WP-CLI-Oberfläche.

Die Lehre für Plugin-als-Abhängigkeitsverwaltung: das Tooling reift schneller als die Review-Kapazität des WordPress.org-Verzeichnisses. Ein selbst hostbarer Mirror wie WP Packages ist in diesem Kontext nützlicher als er vor fünf Jahren gewesen wäre, als das Verzeichnis ein geschlossener Garten war, dem alle standardmäßig vertrauten.

#Letzte Aktualisierung: 2026-04-01

Brauchen Sie Hilfe bei der Migration einer Site zu Bedrock oder beim Einrichten einer Composer-getriebenen Deploy-Pipeline? Sehen Sie sich unsere WordPress-Entwicklungsdienste an.