Grundstein für moderne WordPress-Entwicklung

WordPress ist das bewährte Content-Management-System. Seit seiner Veröffentlichung im Jahr 2003 erfreut es sich großer Beliebtheit, da es den Nutzern die Möglichkeit bietet, schnell eine Website mit Tools zu erstellen, die ihnen eine echte, intuitive Kontrolle über ihre Inhalte bieten. Diese Popularität hat die WordPress-Fans zu ständigen Modernisierungsbemühungen inspiriert, von denen sie auch abhängig sind. Das jüngste Projekt, mit dem der CMS-Klassiker auch zwei Jahrzehnte nach seiner Geburt am Laufen gehalten werden soll, ist Bedrock, ein Versuch, WordPress in eine Zwölf-Faktoren-App zu verwandeln , der von den Leuten von Roots durchgeführt wird.

Roots ist ein Team von Entwicklern, das Tools zur Verbesserung des Entwicklungsprozesses für WordPress entwickelt und pflegt. Einige ihrer Projekte konzentrieren sich auf die Standardisierung der Plugin- und Theme-Entwicklung. Bedrock hingegen konzentriert sich auf die WordPress-Installation selbst und vereinfacht die Konfiguration und Anpassung, indem es vollständig in den PHP-Paketmanager Composer integriert wird .

Mit Bedrock versucht Roots, WordPress näher an die Twelve-Factor-App-Methodikheranzuführen . Twelve-Factor ist eine Art "Best Practices"-Leitfaden, der nur dann erfüllt ist, wenn eine Anwendung explizit externe Codebasen definiert, von denen sie abhängt, und wenn die Konfiguration für diese Anwendung aus der Umgebung gezogen werden kann, egal wo sie bereitgestellt wird. Diese beiden Merkmale machen Builds wiederholbar und damit zuverlässiger. Beide Merkmale werden von WordPress standardmäßig nicht befolgt, was die Wartung erheblich erschwert.

Pflege von WordPress-Sites

Sobald Sie WordPress installiert haben, ist der Installationsprozess bekanntlich einfach (einer der vielen Gründe für die anhaltende Attraktivität der Anwendung). Aber die Wartung von WordPress ist leider nicht so einfach. Zum Beispiel kanndie Aktualisierung von WordPress, abgesehen von kleineren Versions-Upgrades, sehr mühsam sein. Das Bedrock-Projekt ist ein Versuch, die Wartung von WordPress weniger mühsam zu gestalten, indem Themes und Plugins wie jede andere PHP-Abhängigkeitskomponente definiert werden, die mit einem einzigen Befehl über einen Paketmanager installiert und aktualisiert werden können.

Wenn ein Update verfügbar ist, stellt WordPress eine Schaltfläche zur Verfügung, über die Administratoren die Updates mit einem einzigen Klick herunterladen und austauschen können. Viele Hosting-Lösungen, einschließlich Platform.sh, erzwingen jedoch zur Laufzeit schreibgeschützte Dateisysteme. Diese Lösungen stellen ein hochgradig reproduzierbares Build-Image bereit, das sich aus Ihrer Codebasis und dem explizit definierten Build-Prozess ergibt, der der Versionskontrolle unterliegt. Das heißt, dass Ihre Anwendung ein Artefakt dieser Definitionenist und nicht nur die Dateien im Repository allein. Externer Code (Abhängigkeiten), von dem Ihre Anwendung abhängt, und idealerweise auch die Definitionen Ihrer Infrastruktur selbst werden in exakten Versionen festgehalten, so dass Ihr gesamter DevOps-Prozess von Anfang bis Ende wiederholbar und für jeden, der dies benötigt, reproduzierbar ist. Das ist eine gute Sache.

WordPress hingegen erfordert Schreibzugriff auf den Server, damit Plugins und Themes während der Laufzeit aktualisiert werden können. Außerdem verfolgt WordPress den Code für diese Themes und Pakete nicht in der Versionskontrolle Ihrer Website, sondern tauscht sie lediglich aus, wenn Aktualisierungen erforderlich sind. Beides zusammen kann zu unbeabsichtigten Schwachstellenführen , die völlig unauffindbar sind. Wenn Themes und Plugins versionskontrolliert sind, können sie Ihre Codebasis schnell aufblähen. Da Bedrock diese Komponenten als Abhängigkeiten behandelt, wird zur Laufzeit nichts geschrieben und einzelne Pakete müssen nicht übertragen werden, wodurch sowohl die Schwachstellen als auch die Aufblähung beseitigt werden können.

Die Lösung von Bedrock: Composerify WordPress!

Der Composer ist für Bedrock das Herzstück von allem. Wenn wir den WordPress-Kern und alle unsere Anpassungen als Abhängigkeiten behandeln, können wir weniger Code committen, unsere Versionierung spezifischer gestalten, den Einsatz in mehr Umgebungen unterstützen, als es WordPress erlauben würde, und die Wartung drastisch vereinfachen.

Wir haben kürzlich eine Methode zur Aktualisierung von "Vanilla" WordPress auf Upsun mit Source Operationsvorgestellt . Mit dieser Methode können Sie weiterhin ein schreibgeschütztes Dateisystem verwalten, alles an Git übergeben und einen Endpunkt bereitstellen, der Aktualisierungen in einem separaten Container auslöst, der die traditionelle WordPress-Wartung mit unserer Plattform kompatibel macht .

Sie können dies aber auch erreichen, indem Sie WordPress mit Composer, dem Paketverwaltungssystem von PHP, integrieren. Dies ist, wenig überraschend, seit einiger Zeit die empfohlene Methode für die Bereitstellung von WordPress auf Platform.sh. Unsere WordPress-Vorlage basiert auf dem beliebten John Bloch Composer Fork, der die Standard-WordPress-Codebasis spiegelt und dann die composer.json-Datei hinzufügt, die benötigt wird, um WordPress Core als Abhängigkeit zu behandeln. Dasselbe Muster wird auf das riesige Ökosystem von WordPress-Themes und -Plugins angewandt, die mit Composer über das WPackagist-Repository zugänglich sind .

Bedrock: der WordPress-Entwicklungsstarter

Vieles von dem, was Bedrock anders macht, beginnt mit seiner Projektstruktur, also klonenwir eine lokale Kopie des Repos, um es mit der typischen Struktur von WordPress zu vergleichen :

. ├── config/ │ ├── application.php │ └── environments/ │ ├── development.php │ └── staging.php ├── web/ │ ├── app/ │ │ ├── mu-plugins/ │ │ ├── plugins/ │ │ ├── themes/ │ │ └── uploads/ │ ├── index.php │ └── wp-config.php ├── composer.json ├── composer.lock ├── phpcs.xml └── wp-cli.yml

Die Struktur unterscheidet sich hier deutlich von derjenigen, die wir in vanilla WordPress sehen: Sie ist viel kleiner. Die meisten der Dateien, die WordPress zum Laufen bringen - einschließlich der WordPress-Kerndateien sowie der Standard- und benutzerdefinierten Themes und Plugins - werden nicht in das Repository übertragen. Stattdessen werden diese Dateien als Abhängigkeiten für die endgültige Anwendung heruntergeladen, die alle in der composer.json-Datei definiert sind.

 "repositories": [ { "type": "composer", "url": "https://wpackagist.org", "only": ["wpackagist-plugin/*", "wpackagist-theme/*"] } ], "require": { "php": ">=8.0", "composer/installers": "^2.2", "vlucas/phpdotenv": "^5.5", "oscarotero/env": "^2.1", "roots/bedrock-autoloader": "^1.0", "roots/bedrock-disallow-indexing": "^2.0", "roots/wordpress": "6.6.1", "roots/wp-config": "1.0.0", "roots/wp-password-bcrypt": "1.1.0", "wpackagist-theme/twentytwentyfour": "^1.0" }, "extra": { "installer-paths": { "web/app/mu-plugins/{$name}/": ["type:wordpress-muplugin"], "web/app/plugins/{$name}/": ["type:wordpress-plugin"], "web/app/themes/{$name}/": ["type:wordpress-theme"] }, "wordpress-install-dir": "web/wp" },

Im obigen Ausschnitt wird roots/wordpress eine genaue Version von WordPress gegeben: 6.6.1. Dieselbe Version wird bei jedem Build (wenn composer install ausgeführt wird) in ein Unterverzeichnis heruntergeladen, was auch außerhalb der "Composerified"-Versionen von WordPresseine beliebte Praxisgeworden ist.

Schon jetzt entfernen wir uns von einigen der oben beschriebenen Probleme. WordPress ist eine Abhängigkeit, die explizit definiert und auf eine bestimmte Version festgelegt werden kann, um wiederholbare Builds zu gewährleisten. Nichts davon wird übertragen, und nur diese spezifische Version wird während eines Composer-Installations-Build-Befehls heruntergeladen.

Erweitern von WordPress mit Composer

Das Gleiche gilt für Themes und Plugins. Sie werden jedoch feststellen, dass die composer.json einige zusätzliche Konfigurationen benötigt, um diese neue Art der Definition von WordPress-Abhängigkeiten zu unterstützen. Standardmäßig wird jede Composer-Abhängigkeit in ein unbestimmtes Unterverzeichnis vendor installiert. Auf Platform.sh wird dies mit unserem Build-Flavor oder während Ihres Build-Hooksinstalliert .

Das Problem ist, dass wir nicht möchten, dass WordPress Core dort landet. In dem obigen Schnipsel sehen Sie die Attribute extra.wordpress-install-dir und extra.installer-paths. Das erste weist Composer (unter Verwendung von composer/installers) an, die von uns definierte Version von WordPress in web/wp herunterzuladen, und das zweite, Themes und Plugins in web/app zu installieren. Alles, was WordPress vorgelagert ist, befindet sich in einem Verzeichnis, und alles, was wir zu WordPress hinzufügen, in einem anderen. Ähnlich verhält es sich mit Ihrer Konfiguration, die in config isoliert wurde, komplett mit umgebungsabhängiger Kontrolle. Alles hier ist klar getrennt, wird versionskontrolliert und ist mit Composer reproduzierbar.

Mit diesem Setup können wir eine Menge Dinge sehr einfach tun. Wenn wir den WordPress-Kern und alle unsere Themes und Plugins aktualisieren wollen, brauchen wir nur composer update auszuführen. Wir können das Aussehen der Website mit einem Community-Theme mit composer require wpackagist-theme/magsoul anpassen (als Beispiel) und es dann im Admin-Dashboard aktivieren, sobald es bereitgestellt wurde. Wenn wir die Seite zu einem Online-Shop erweitern wollen, können wir das WooCommerce-Plugin auf die gleiche Weisehinzufügen :

$ composer require wpackagist-plugin/woocommerce

Wenn wir in der Lage sein wollen, die Anwendung mit der WordPress CLI zu verwalten:

$ composer require wp-cli/wp-cli

Jeder, der unsere Anwendung nachbauen möchte, braucht nur composer install auszuführen, um einen Beitrag zu leisten. Alles ist eine Abhängigkeit und kann vollständig über Composer installiert und aktualisiert werden.

Bereitstellung von Bedrock auf Upsun.com

Nun wäre das ganze Gerede umsonst, wenn wir uns nicht mit dem Deployment befassen würden, und hier eröffnet Bedrock wirklich die Möglichkeit, die Konfiguration zu ändern. Bedrock ermöglicht die Verwendung von Umgebungsvariablen für die Verbindung zur Datenbank und das Setzen von Routing-Variablen wie WP_HOME und WP_SITEURL auf flexiblere Weise als das traditionelle WordPress. Dies ist eine weitere Komponente der Idee der Zwölf-Faktoren-App: die in der Umgebung gespeicherte Konfiguration. Die Anwendung kann in viele verschiedene Umgebungen verschoben werden und trotzdem denselben Build beibehalten, solange diese Variablen definiert sind. Nachfolgend sehen Sie eine ähnliche .environment-Datei, die in unserer Platform.sh WordPress Bedrock-Vorlage enthalten ist (die auf Upsun identisch funktioniert):

# .environment export DB_NAME=$MARIADB_PATH export DB_HOST=$MARIADB_HOST export DB_PORT=$MARIADB_PORT export DB_USER=$MARIADB_USERNAME export DB_PASSWORD=$MARIADB_PASSWORD export WP_HOME=$(echo $PLATFORM_ROUTES | base64 --decode | jq -r 'to_entries[] | select(.value.primary == true) | .key') export WP_SITEURL="${WP_HOME}wp" export WP_DEBUG_LOG=/var/log/app.log export WP_ENV=production # Dekommentieren Sie diese Zeile, wenn Sie Entwicklungsversionen von WordPress in Nicht-Produktionsumgebungen verwenden möchten.
# export WP_ENV="${PLATFORM_ENVIRONMENT_TYPE}" export AUTH_KEY=$PLATFORM_PROJECT_ENTROPY export SECURE_AUTH_KEY=$PLATFORM_PROJECT_ENTROPY export LOGGED_IN_KEY=$PLATFORM_PROJECT_ENTROPY export NONCE_KEY=$PLATFORM_PROJECT_ENTROPY export AUTH_SALT=$PLATFORM_PROJECT_ENTROPY export SECURE_AUTH_SALT=$PLATFORM_PROJECT_ENTROPY export LOGGED_IN_SALT=$PLATFORM_PROJECT_ENTROPY export NONCE_SALT=$PLATFORM_PROJECT_ENTROPY

Unsere Datenbankdienstinformationen werden als Umgebungsvariablen mit dem Namen des Datenbankdienstes angezeigt, den wir in der Eigenschaft relationships unserer Konfigurationsdatei definieren (siehe unten). In diesem Fall habe ich ihn mariadbgenannt , so dass die Dienstinformationen mit dem Präfix MARIADB_* versehen sind . Bedrock benötigt jedoch die Umgebungsvariablen mit dem Präfix DB_, so dass der erste Block in der Umgebungsdatei einfach die Informationen auf die Anforderungen von Bedrock abbildet.

Dann verwenden wir jq, um die primäre Route zu unserer Anwendung abzurufen, da sich die URL je nach Umgebung (Produktion vs. Staging vs. Entwicklung) ändert, und die Projektvariable PLATFORM_PROJECT_ENTROPY für unsere Sicherheitsvariablen, die alle in unserer umgebungsspezifischen Konfiguration (dem Unterverzeichnis config ) aufgerufen werden können. Die restliche Konfiguration ist ziemlich ähnlich zu der, die Sie bereits in unserer Composer-WordPress-Vorlage für Platform.shgesehen haben .

.upsun/config.yaml

.upsun/config.yaml ist ebenfalls ähnlich, einschließlich eines Build-Hook-Schrittes, der es uns erlaubt, Plugins, die nicht als Abhängigkeiten heruntergeladen werden können, weiterhin zu verwenden. Nicht jedes WordPress-Theme und -Plugin ist mit dem Composer kompatibel (ihre Upstreams enthalten keine composer.json-Datei ), daher ist dieser Schritt immer hilfreich. Anders als .platform.app.yaml enthält die Konfigurationsdatei von Upsun auch Routen (routes.yaml in Platform.sh) und unsere Dienste (services.yaml in Platform.sh)

# .upsun/config.yaml applications: wp-bedrock-upsun: source: root: "/" type: "php:8.3" relationships: mariadb: # Mounts definieren Verzeichnisse, die beschreibbar sind web: locations: "/": root: "web" passthru: "/index.php" index: - "index.php" expires: 600s scripts: true allow: true rules: ^/composer\.json: allow: false ^/license\.txt$: allow: false ^/readme\.html$: allow: false "/wp/wp-content/uploads": root: "web/wp/wp-content/uploads" scripts: false allow: false rules: '(?<!\-lock)\.(?i:jpe?g|gif|png|svg|bmp|ico|css|js(?:on)?|eot|ttf|woff|woff2|pdf|docx?|xlsx?|pp[st]x?|psd|odt|key|mp[2-5g]|m4[av]|og[gv]|wav|mov|wm[av]|avi|3g[p2])$': allow: true expires: 1w build: flavor: none dependencies: php: composer/composer: "^2" hooks: build: | set -eux composer --no-ansi --no-interaction install --no-progress --prefer-dist --optimize-autoloader --no-dev rsync -a plugins/* web/app/plugins/ mounts: "web/wp/wp-content/cache": source: storage source_path: "cache" "web/wp/wp-content/uploads": source: storage source_path: "uploads" # Die Dienste des Projekts. services: mariadb: type: mariadb:11.0 # Die Routen des Projekts. routes: "https://{default}/": type: upstream upstream: "wp-bedrock-upsun:http" "https://www.{default}": type: redirect to: "https://{default}/

Mit dieser Konfiguration lädt Upsun.com alle Ihre Abhängigkeiten herunter (was wiederum WordPress selbst ist, zusammen mit all Ihren Themes und Plugins), verbindet sich mit der Datenbank und stellt Bedrock für Sie bereit.

Speicherplatz

Ein deutlicher Unterschied zwischen Platform.sh und Upsun.com besteht darin, dass Sie den Speicherplatz, den Sie Ihren Diensten und Anwendungen zuweisen, nicht in der Konfigurationsdatei festlegen. Stattdessen weist Upsun.com beim ersten Push automatisch 512 MB Festplattenspeicher sowohl dem MariaDB-Dienst als auch den Mounts zu, die WordPress für Uploads verwendet. Um den zugewiesenen Speicherplatz anzupassen, können Sie entweder die Konsole oder den Befehl upsun resources:set CLI verwenden. Weitere Informationen finden Sie unter Manage resources in den Dokumenten.

Man kann nicht sagen, wie die Zukunft von WordPress aussehen wird, aber es ist sicher, dass es weiterhin sehr beliebt sein wird. Bedrock bietet eine Methode zur Entwicklung mit WordPress auf interessante Weise. Die wenigen Beschränkungen, die es der Projektstruktur auferlegt, ermöglichen eine größere Flexibilität bei der schnellen Anpassung, während der Wartungsaufwand langfristig erheblich reduziert wird.