Composer Plugin WP Starter für WordPress

Vor einigen Wochen haben wir einen Artikel veröffentlicht, in dem wir erklärt haben, warum wir die Weiterentwicklung des WP-Starters unterstützen. Tatsächlich arbeitet hauptsächlich Inpsyder Giuseppe daran und erstellt das Composer Plugin WP Starter. Im 13. Adventskalender-Beitrag von 2019 veröffentlichen.

Inhaltsverzeichnis

Von der Bibliothek zum Composer Plugin
Neue Features
Einfacheres Setup
Benutzerdefinierter Befehl
Environment Management
Performance
Verbesserte Anpassung der Schritte
WP Starter Erweiterungen
Verbesserte Konfiguration
Erweiterte WP-config.php
WP-CLI Integration
Verbesserte Schritte
Ausführliche Dokumentation
Fazit

Composer ist das de-facto Standard Dependency Management Tool für PHP. So ziemlich alle PHP-Projekte, also von Frameworks, Applikationen oder Libraries, unterstützen Composer. Alle außer WordPress. WordPress hat keinen offiziellen Support für Composer. Die Erstellung eines Website-Projekts mit zentralisierten Abhängigkeiten, die von Composer verwaltet werden, erfordert etwas Aufwand und “Bootstrap”-Arbeit.

Der Hauptzweck von WP Starter ist es, diesen Prozess zu vereinfachen. Die Idee hinter WP Starter ist, dass ein Ordner mit einer einzigen composer.json zu einer voll funktionsfähigen WordPress-Website wird, nachdem die composer-Installation ausgeführt wurde.

Von der Library zum Composer Plugin

In dem Moment, in dem ich diesen Blogbeitrag schreibe, ist die aktuelle Version von WP Starter 2.4.4.

Wir arbeiteten und veränderten viel für das nächste große Release. Ein großer Dank geht an Inpsyde, die sich entschieden haben, uns Mitarbeitern Zeit zu sponsern, um am Release zu arbeiten.

In seinen ersten beiden großen Releases war WP Starter eine Library, die du neben anderen Abhängigkeiten benötigst hast. Diese Dinge werden sich in der nächsten großen Version ändern. Um genau zu sein wird WP Starter mit der Version 3 ein Composer Plugin werden. Es wird die Integration mit Composer verbessern und viele interessante Features ermöglichen.

Neue Features

Einfacheres Setup

In WP Starter v2 musst du Skriptabschnitte in composer.json einrichten, um WP Starter automatisch auf der Composer-Installation auszuführen (oder upzudaten). In v3, einem Plugin, kann der WP Starter das ohne jegliche Einstellung tun. Eigentlich kann die einzige Tatsache, WP-Starter anzufordern, ausreichen, um alles zum Laufen zu bringen: Du brauchst überhaupt nichts einzurichten.

Benutzerdefinierter Befehl

Composer-Plugins haben die Möglichkeit, benutzerdefinierte Befehle zu Composer hinzuzufügen, und WP Starter 3 wird dies tun. Es gibt einen Befehl `wpstarter`, mit dem du den gesamten WP Starter-Workflow oder nur bestimmte “Schritte” davon ausführen kannst.

Die Tatsache, dass WP Starter ein Composer Plugin ist, macht es leistungsfähiger. Aber das ist nur die Spitze des Eisbergs: WP Starter 3 wird eine Menge interessanter neuer Features bekommen.

Environment Management

Neben der Vereinfachung des Prozesses der Zentralisierung und Verwaltung von WordPress-Websiteabhängigkeiten durch Composer gibt es ein zweites Hauptziel von WP Starter. Ziel ist es, die Website über Umgebungsvariablen konfigurierbar zu machen.

Der Grund für diesen zusätzlichen Spielraum ist, dass es im professionellen Entwicklungskontext mehr als üblich ist, unterschiedliche Umgebungen für ein und dasselbe Projekt zu haben. Man denke beispielsweise an “Entwicklung”, “Bühne” und “Produktion”.

Der Standard “WordPress Weg” – die Konfiguration über PHP-Konstanten – macht umgebungsbewusste Konfigurationen komplexer als nötig. Andere Projekte (nicht nur PHP) haben festgestellt, dass Umgebungsvariablen die aktuelle Lösung für das Problem sind. Tatsächlich ist die Verwendung von Umgebungsvariablen eine der Zwölf-Faktor-App (Sammlung moderner Praktiken für Webanwendungen).

Die Konfiguration über Umgebungsvariablen ist seit dem ersten Release ein WP-Starter-Feature. Mit der Version 3 wird es jedoch viele Verbesserungen in diesem Bereich geben:

• Das Package, das die .env Datei lädt und zerlegt wird Symfony Dotenv sein (früher war es das “Dotenv”-Package von Vance Lucas, in v2). Der Grund für die Änderung ist die Vereinbarung über die Gründe, die in der PR von Fabien Potencier erläutert wurden, der Dotenv in Symfony eingeführt hat.
• Wir haben WP Starter 3 unter Berücksichtigung der Tatsache entwickelt, dass der beste (und performantere) Weg, mit Umgebungsvariablen umzugehen (insbesondere in der Produktion), die Verwendung der realen Umgebung ist. Das heißt, dass die Konfiguration im System, z.B. in den Webserver-Konfigurationsdateien, gemacht wird. Zum ersten Mal werden .env-Dateien für den WP-Starter überhaupt nicht benötigt.
• Umgebungs-Cache. Wenn .env-Dateien verwendet werden, kann das Laden und Analysieren dieser Dateien für die Leistung sehr teuer sein. Darüber hinaus muss WP Starter Konstanten basierend auf env vars einrichten … dies bei jeder Anfrage zu tun, könnte eine ziemliche Ressourcenverschwendung sein. WP Starter 3 verwendet einen Caching-Mechanismus, sodass es möglich ist, dass die Umgebung nur bei der ersten Anforderung durch .env Dateien berechnet wird. Mit dem neuen benutzerdefinierten Befehl wird es möglich sein, diesen Cache bei Bedarf zu “leeren”.

Performance

Das Caching der Umgebung und die Unterstützung von Einstellungen in der eigentlichen Umgebung anstelle von.env-Dateien ist ein Zeichen für die Sorgfalt, mit der wir WP Starter 3 weiterentwickeln. Wir wollen, dass es so wenig Wirkung wie möglich auf die WordPress-Performance hat.

Eine andere Sache, die wir in diesem Zusammenhang getan haben, ist die Optimierung des Autoloads. WP-Starter registrierte früher den automatischen Ladevorgang in Composer. Das bedeutet, dass seine Autoload-Konfiguration Teil der Autoload-Applikation war, die bei jeder Anforderung an WordPress registriert wurde.

WP Starter 3 ändert dies. Mehr Funktionen in WP Starter 3 zu haben bedeutet auch, mehr Code, mehr Klassen und mehr Dateien zu haben. Wenn du sie als Teil des Composer-Autoloads registrierst, würde der Produktionsautoload durch die WP-Starterkonfiguration “verschmutzt” werden, die bei WordPress-Anfragen überhaupt nicht benötigt wird.

Aus diesem Grund registriert WP Starter 3 nur ein paar seiner Klassen als Teil des Composer Autoload. Für den Rest verwendet es einen benutzerdefinierten Autoload, der nur geladen wird, wenn der WP-Starter ausgeführt wird.

An dieser Stelle sei erwähnt, dass WP Starter 3 PHP 7.0 als Mindestversion benötigt. Die Verwendung von PHP 7-Funktionen erhöht die Leistung allein nicht. Aber PHP 7 hat einen enormen Performancegewinn gegenüber PHP 5. So haben wir das Gefühl, im Namen der “Götter der Leistung” einen guten Dienst geleistet zu haben, indem wir darauf gedrängt haben, PHP 5 abzuschreiben.

Verbesserte Anpassung der Schritte

Der WP-Starter-Workflow basiert seit jeher auf einer Reihe von “Schritten”. Sie konnten nacheinander bei der Installation oder Aktualisierung des Composer laufen.

Mit Version 3 ist dieses grundlegende Prinzip immer noch da, aber es gibt außerdem die Möglichkeit:

• Benutzerdefinierte Schritte hinzuzufügen, die Teil des Projektes sein können, aber auch als separate Packages abgeschickt werden können, um sie damit in anderen Projekten wiederverwendbar zu machen.
• Standardschritte ersetzen durch benutzerdefinierte Schritte.
• Explizit manche Schritte ausschließen.
• Schritt-Skripte verwenden: etwas Ähnliches wie Composer-Skripte, die es ermöglichen, beliebige Rückrufe vor oder nach jedem der WP-Starter-Schritte (einschließlich benutzerdefinierter) auszuführen. Benutzerdefinierte Skripte können, genau wie benutzerdefinierte Schritte, als Teil des “Project”-Packages bereitgestellt oder aus separaten Packages gezogen werden.
• Anpassen von Schrittvorlagen. Viele der “Schritte” des WP-Starters erstellen Dateien. Am relevantesten ist der Schritt, der eine wp-config.php für das Projekt erstellt. Alle diese Dateien werden ausgehend von “Vorlagen” erstellt: Dateien, in denen eine Reihe von Platzhaltern durch Werte ersetzt werden, die durch den zugehörigen Schritt erzeugt werden. Mit Version 3 ist es möglich, die Standardvorlagen zu ersetzen und das Verhalten des WP-Starters vollständig anzupassen, ohne den Code der Schritte zu berühren.

WP Starter Erweiterungen

Mit benutzerdefinierten Schritten, Skripten und Vorlagen bietet WP Starter viele verschiedene Möglichkeiten, seine Funktionen zu erweitern. Die Erstellung von Packages zur projektübergreifenden Wiederverwendung wird für Teams zu einer selbstverständlichen Möglichkeit, Standardverfahren für ihre Projekte festzulegen. Um dies weiter zu unterstützen, ist in WP Starter 3 die Unterstützung für einen neuen Composer-Package-Typ: “wpstarter-extension” implementiert.

Durch die Erstellung von Packages mit diesem Typ ist es möglich, WP-Starter als Abhängigkeit zu erklären, ohne dass der WP-Starter jederzeit in Composer-Installationen oder Updates “eingreifen” muss.

Darüber hinaus wird es durch die Erstellung von Packages des Typs “wpstarter-extension” möglich sein, eine Einstellung in composer.json zu verwenden, um den WP Starter-spezifischen Autoload zu erweitern, der alle Erweiterungsklassen nur dann autoloadbar macht, wenn WP Starter läuft, ohne die Autoload-Funktion der Anwendung zu beeinflussen.

Verbesserte Konfiguration

WP Starter v2 verfügt bereits über einen recht umfangreichen Satz von Konfigurationen, mit denen du das Standardverhalten ändern kannst. In Version 3 sind die Möglichkeiten noch größer (aber es wird keine benötigt). Außerdem haben wir eine neue Methode eingeführt, um sie einzustellen.

Neben den Einstellungen im Abschnitt “extra” von composer.json wird es möglich sein, die WP Starter-spezifischen Einstellungen in eine separate wpstarter.json-Datei zu speichern. Dies hilft, die Dinge besser lesbar zu halten, ohne die Komplexität in composer.json zu erhöhen.

Aber es gibt noch mehr. Standardmäßig sucht WP-Starter nach einer wpstarter.json im Projekt-Root Es ist jedoch möglich, ihm zu sagen, dass er in einem beliebigen Ordner suchen soll. Das bedeutet, dass die gemeinsame Nutzung der Konfiguration über Projekte hinweg jetzt möglich und sehr einfach ist.

Extended wp-config.php

Seit seiner ersten Version ist der der wp-config.php WP Starter auf der standardmäßigen wp-config.php aufgebaut, indem er das Laden von Composer Autoload und den Code hinzufügt, der zum Laden von Umgebungsvariablen erforderlich ist, die sie in Konstanten für die WordPress-Konfiguration verwandeln.

In Version 3 werden wir noch einige Features mehr hinzufügen:

• Frühes Laden der plugin.php. Die Datei, die die Plugin-API in den neuesten Versionen von WordPress enthält, wurde vom Rest der Applikation “unabhängig” gemacht. Dies ermöglicht es, es sehr früh zu laden. WP Starter lädt es nun, bevor die Anwendung gestartet wird. Auf diese Weise kannst du ganz einfach Hooks hinzufügen, bevor WordPress geladen wird. WP Starter bietet dafür zwei Einstiegspunkte, einen generischen und einen umgebungsspezifischen.
• Es gibt nun die Möglichkeit, eine {$environment}.php Datei zu laden. Das ist eine PHP-Datei, die nach der aktuellen Umgebung benannt ist (z.B. “production.php”, “staging.php”, etc.). Diese Datei ermöglicht umgebungsspezifische Operationen in WordPress. Durch das frühzeitige Laden der Plugin-API gibt es viele neue Möglichkeiten. Um nur eine zu nennen: Stell dir vor, du hättest die Möglichkeit, Plugins nur in bestimmten Umgebungen zu deaktivieren (oder zu aktivieren).
• Eine “frühe Hook-Datei”, deren Name in den Einstellungen konfiguriert werden kann, kann nach dem Laden der Plugin-API-Datei geladen werden, bevor der Rest von WordPress geladen wird. Dies ermöglicht die Verwendung von Hooks. Sie waren noch nie über Plugins (nicht einmal MU-Plugins) verwendbar, da sie im WordPress-Bootstrap-Prozess zu früh gefeuert wurden.
• Durchsetzung der Admin-Farbgebung. Die von WP Starter 3 generierte wp-config.php unterstützt eine Umgebungsvariable, mit der das in den Benutzereinstellungen definierte Admin-Farbschema überschrieben werden kann. Auf diese Weise hilft es, visuell zu erkennen, welches die aktuelle Umgebung ist, und zu vermeiden, dass z.B. in Produktionsabläufen, die für die Bereitstellung vorgesehen sind, gearbeitet wird.

WP-CLI Integration

WP Starter kümmert sich um die Dateistruktur der Website und deren Konfiguration auf Dateisystemebene. Es tut jedoch beispielsweise nichts für die Datenbank, und sicherlich ist WP-CLI der beste Verbündete für diejenigen, die das Bootstrapping von Websites vollständig automatisieren wollen.

WP CLI benötigt keinen WP-Starter und kann in einer WP-Starter-Umgebung ohne besondere Einstellungen oder Ähnliches arbeiten. WP Starter 3 bietet jedoch eine integrierte Möglichkeit, WP-CLI-Befehle auszuführen, was den Vorteil hat, dass WP-CLI für die Ausführung der Befehle verfügbar ist. Beispielsweise prüft WP Starter, ob WP-CLI über den Composer installiert ist. Im Falle, dass es das ist, wird es nichts machen. Falls nicht, kümmert es sich um den Download der WP-CLI-Phar.

Mit WP Starter können Sie WP-CLI-Befehle so schreiben, dass sie nicht mit der Art der WP CLI-Installation (Composer oder phar) übereinstimmen. WP Starter kümmert sich um die “Übersetzung” in der für die Installationsart geeigneten Weise.

Die Generierung der Datei wp-cli.yml, der auf den WordPress-Installationsordner hinweist und seit der Version 2 vorhanden ist, wurde beibehalten und kann dank benutzerdefinierter Vorlagen jetzt sogar erweitert werden.

Verbesserte Schritte

Wir verbesserten viele der Standardschritte, die WP Starter macht. Wir haben das Handling von Dropins und MU Plugins deutlich einfacher und effektiver gemacht.

Darüber hinaus ist mit der Einführung von benutzerdefinierten Befehlen und benutzerdefinierten Schritten nun ein Mechanismus vorhanden, um Schritte zu ermöglichen, die nur über den Befehl wpstarter ausgeführt werden sollen. Dies macht WP Starter zu einer großen Hilfe bei der Automatisierung von Aufgaben und bietet de-facto ein Framework für die Interaktion mit der WordPress-Installation, Composer und der “Brücke” zwischen beiden.

Ausführliche Dokumentation

WP Starter hatte nie eine gute Dokumentation. Viele seiner Features und Verhaltensweisen waren einfach nicht dokumentiert. So hatten besonders Menschen, die nicht wussten, wie sie WordPress mit Composer nutzen sollen, am Anfang Probleme.

WP Starter 3 wird das ändern. Selbst wenn sich die Version 3 noch im Alpha-Status befindet, steht bereits eine umfangreiche Dokumentation zur Verfügung (mehr als 20.000 Wörter in dem Moment, in dem ich schreibe). Und während der laufenden Entwicklung wird jede Änderung oder Ergänzung, die im Code vorgenommen wird, sofort dokumentiert und in den gleichen Commit verschoben, der die Code-Änderung einführt.

Fazit

WP Starter 3 wird nach dreieinhalb Jahren nach dem Release der Version 2.0 erscheinen. Dreieinhalb Jahre, in denen Entwickler es in vielen Projekten (und auch sehr großen Projekten) verwendet haben. Und es wird auf vielfältige Weise von diesen gewonnenen Erfahrungen profitieren.

Das Sponsoring von Inpsyde gewährleistet eine nachhaltigere Entwicklung. Kombiniert mit all den Verbesserungen wird es hoffentlich bekannter werden. Und wir hoffen, dass es die Möglichkeit für Contributions, Feedback und vor allen die Qualität des Projektes verbessern wird.

Wo wir gerade von Hilfe aus der Community sprechen: Version 3 ist im Alpha-Status. Das heißt, wir empfehlen auf keinen Fall, es in echten WordPress-Projekten zu verwenden. Aber jedwede Art der Contribution hilft uns sehr. Sogar, wenn man einfach nur die Dokumentation liest und Feedback gibt – auch das ist wertvoll und wir schätzen es sehr.

Ich kann es wirklich kaum erwarten, dass ich die Veröffentlichung der Version 3 verkünden kann. Ich hoffe, ich hab es geschafft euch alle mit diesem Artikel anzustecken. Also … bleibt dran!