WP Packages funktioniert so, wie Open Source es sollte

Als WP Engine am 12. März WPackagist übernahm, stand die WordPress-Entwicklergemeinschaft vor einer vertrauten Frage: Was passiert, wenn kritische Open-Source-Infrastruktur unter die Kontrolle des Unternehmens gerät? Die Community hatte bereits eine Antwort in Arbeit. Vier Tage später wurde WP Packages (ehemals WP Composer) als völlig unabhängige, von der Community finanzierte Alternative mit einigen netten zusätzlichen Funktionen auf den Markt gebracht.

Erstellt von Ben Words von Roots, dem Team hinter Bedrock, Sage und Trellis, ist WP Packages ein neues Open-Source-Composer-Repository für WordPress Plugins und Themes. Composer ist der Abhängigkeitsmanager von PHP und dient dazu, wie viele professionelle WordPress-Entwickler Plugins und Themes in ihren Projekten installieren und aktualisieren. Jedes kostenlose Plugin und Theme im WordPress.org-Verzeichnis ist über WP Packages verfügbar. Die Migration von WPackagist kann über ein einzelnes Skript oder ein paar Terminalbefehle erfolgen.

Was geschah und warum es wichtig ist

WPackagist wurde 2013 von Outlandish, einer in Großbritannien ansässigen digitalen Genossenschaft, gegründet und diente über ein Jahrzehnt lang dem WordPress Composer-Ökosystem. In den späteren Jahren litt das Projekt unter verzögerter Wartung, langsamen Aktualisierungszyklen und wenig bis gar keinem Community-Beitrag. Als WP Engine die Übernahme ankündigte, äußerten die Entwickler sofort Bedenken hinsichtlich eines von Private Equity finanzierten Unternehmens, das eine so grundlegende Infrastruktur für den WordPress-Entwickler-Workflow kontrolliert. WP Engine hat das Composer-Feld info sofort aktualisiert, um in jedem Entwicklerterminal den Hinweis „WPackagist wird jetzt von WP Engine verwaltet“ anzuzeigen. Eine kleine Sache, aber aufschlussreich. Auf diese Weise verändert Unternehmenseigentum die Beziehung zwischen einem Tool und seinen Benutzern.

Ich hatte bereits letzten August mit der Entwicklung eines WPackagist-Ersatzes begonnen, lange bevor die Übernahme Schlagzeilen machte. Als der Deal mit WP Engine zustande kam, beschleunigte er den Start und ging am 16. März mit einem vollständig Open-Source-Repository auf GitHub live

Open-Source-Repo ≠ transparentes System. WP Packages macht alles öffentlich, einschließlich Infrastruktur und Build-Prozess. – Ben Word auf X

Es ist auch einfach ein besseres Werkzeug. WP Packages unterstützt das Metadaten-URL-Protokoll von Composer v2, das es Composer ermöglicht, Metadaten nur für die Pakete abzurufen, die ein Projekt tatsächlich benötigt. WPackagist verlässt sich immer noch auf den älteren Provider-includes-Ansatz und zwingt Composer dazu, große Indexdateien herunterzuladen, bevor Abhängigkeiten aufgelöst werden. Kalte Abhängigkeitsauflösungen sind bei WP-Paketen etwa 17-mal schneller: 0,7 Sekunden für 10 Plugins im Vergleich zu 12,3 Sekunden bei WPackagist.

WP Packages verwendet außerdem CDN-Caching mit öffentlichen Cache-Headern und stellt unveränderliche, inhaltsadressierte Dateien pro Paket bereit. Die Paketbenennung ist sauberer (wp-plugin/ und wp-theme/ anstelle von wpackagist-plugin/ und wpackagist-theme/), die Metadaten umfassen Plugin- und Theme-Autoren, Beschreibungen und Homepage-URLs, die WPackagist seit Jahren fehlt, und die Aktualisierungen werden alle fünf Minuten statt wie bei WPackagist etwa 90 Minuten synchronisiert Zyklus.

So wechseln Sie

Der Wechsel von WPackagist zu WP Packages erfordert nur ein paar Terminalbefehle.

1. Entfernen Sie Ihre vorhandenen WPackagist-Pakete:

composer Remove wpackagist-theme/twentytwentyfive

2. Entfernen Sie das WPackagist-Repository und fügen Sie WP-Pakete hinzu:

composer config --unset repositories.wpackagist && Composer config repositories.wp-composer Composer https://repo.wp-packages.org

3. Pakete mit dem neuen Namen erforderlich:

Komponisten benötigen wp-theme/twentytwentyfive

Alternativ können Sie das Migrationsskript verwenden, um Ihre composer.json automatisch zu aktualisieren:

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

Roots bietet außerdem eine WP Packages Changelog Action für GitHub-Workflows, die Abhängigkeitsaktualisierungen mithilfe des neuen Benennungsformats verfolgt. Projekte, die Bedrock verwenden, werden bereits mit standardmäßig konfigurierten WP-Paketen ausgeliefert.

Open Source gewinnt

Das gesamte WP Packages-Projekt ist öffentlich. Der Anwendungscode, die Dokumentation und sogar die vollständige Ansible-Bereitstellungskonfiguration sind auf GitHub verfügbar. Jeder kann das Repository teilen und seine eigene WordPress Composer-Registrierung ausführen. Ich habe außerdem öffentlich zugesagt, dass WP Packages niemals das Composer-info-Feld verwenden wird, um Nachrichten, Anzeigen oder Upsells in Entwicklerterminals zu pushen. Diese Art von Zurückhaltung lässt sich leichter versprechen, wenn ein Projekt seiner Gemeinschaft gegenüber verantwortlich ist und nicht einem übergeordneten Unternehmen.

WP Packages wird durch GitHub-Sponsoren finanziert. Zu den aktuellen Sponsoren gehören Carrot, Kinsta, WordPress.com und Itineris. Das WordPress-Ökosystem war schon immer dann am stärksten, wenn die Community die benötigten Tools offen erstellt. Monate bevor irgendjemand anders darauf aufmerksam wurde, sah ich, wie sich eine Lücke bildete, baute etwas Besseres als das, was existierte, und veröffentlichte es für alle. Keine Anschaffung erforderlich. Keine Vorstandsentscheidungen über Verfügbarkeit oder Preise. Nur Entwickler, die ein Problem für andere Entwickler lösen und das Ergebnis teilen. Open Source gewinnt.

Zur Originalquelle gehen