Die Grundlage für moderne WordPress-Entwicklung

WordPress ist das altbewährte Content-Management-System. Seit seiner Veröffentlichung im Jahr 2003 erfreut es sich nach wie vor enormer Beliebtheit, da es Nutzern die Möglichkeit bietet, mit Tools, die ihnen echte, intuitive Kontrolle über ihre Inhalte ermöglichen, schnell eine Website auf die Beine zu stellen. Diese Beliebtheit hat die ständigen Modernisierungsbemühungen der WordPress-Fans sowohl inspiriert als auch davon abhängig gemacht. Das neueste Projekt, das das klassische CMS auch zwei Jahrzehnte nach seiner Entstehung auf dem neuesten Stand hält, ist Bedrock – eine Initiative des Teams von Roots, WordPress in eine Twelve-Factor-App zu verwandeln.

Roots ist ein Entwicklerteam, das Tools erstellt und pflegt, um den Entwicklungsprozess für WordPress zu verbessern. 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 durch die vollständige Integration mit dem PHP-Paketmanager Composer.

Mit Bedrock versucht Roots, WordPress näher an die „Twelve-Factor“-App-Methodik heranzuführen. Twelve-Factor ist eine Art „Best-Practices“-Leitfaden, der nur dann erfüllt ist, wenn eine Anwendung die externen Codebasen, von denen sie abhängt, explizit definiert und wenn die Konfiguration für diese App aus der Umgebung abgerufen werden kann, egal wo sie bereitgestellt wird. Beide Eigenschaften machen Builds wiederholbar und damit zuverlässiger. Es sind zudem beides Features, denen WordPress standardmäßig nicht folgt, was die Wartung erheblich erschwert.

Wartung von WordPress-Seiten

Sobald du WordPress bereitgestellt hast, ist der Installationsprozess bekanntlich einfach (einer der vielen Gründe für die anhaltende Beliebtheit der Anwendung). Die Wartung von WordPress ist leider nicht so einfach. Zum Beispiel kann das Aktualisieren von WordPress – abgesehen von Upgrades auf eine neue Hauptversion – mühsam sein. Das Bedrock-Projekt ist ein Versuch, die Wartung von WordPress weniger aufwendig zu gestalten, indem Themes und Plugins wie jede andere PHP-Abhängigkeit definiert werden – Komponenten, die mit einzelnen Befehlen über einen Paketmanager installiert und aktualisiert werden können.

Wenn ein Update verfügbar ist, zeigt WordPress eine Schaltfläche an, über die Administratoren Updates mit einem einzigen Klick herunterladen und einspielen können. Viele Hosting-Lösungen, darunter auch Platform.sh, erzwingen jedoch zur Laufzeit schreibgeschützte Dateisysteme. Diese Lösungen stellen ein hochgradig reproduzierbares Build-Image bereit, das sich aus deiner Codebasis und dem explizit definierten Build-Prozess ergibt – beides wird in der Versionskontrolle festgehalten. Das heißt, deine Anwendung ist ein Artefakt dieser Definitionen und nicht nur die Dateien im Repository allein. Externer Code (Abhängigkeiten), auf den deine Anwendung angewiesen ist, und im Idealfall auch die Definitionen deiner Infrastruktur selbst, werden in exakten Versionen festgehalten, sodass dein gesamter DevOps-Prozess von Anfang bis Ende für jeden, der dies benötigt, wiederholbar und reproduzierbar ist. Das ist eine gute Sache.

WordPress hingegen benötigt Schreibzugriff auf den Server, damit Plugins und Themes zur Laufzeit aktualisiert werden können. Außerdem erfasst WordPress den Code dieser Themes und Pakete nicht in der Versionskontrolle deiner Website, sondern tauscht sie lediglich aus, wenn Updates erforderlich sind. Diese beiden Aspekte zusammen können unbeabsichtigte Sicherheitslücken verursachen, die völlig unauffindbar sind. Wenn Themes und Plugins versionsverwaltet werden, können sie deine Codebasis schnell aufblähen. Da Bedrock diese Komponenten als Abhängigkeiten behandelt, wird zur Laufzeit nichts geschrieben und einzelne Pakete müssen nicht festgeschrieben werden, wodurch es möglich ist, sowohl die Sicherheitslücken als auch die Aufblähung zu beseitigen.

Die Bedrock-Lösung: WordPress mit Composer arbeiten lassen!

Composer ist das Herzstück von Bedrock. Wenn wir den WordPress-Kern und alle unsere Anpassungen als Abhängigkeiten behandeln können, müssen wir weniger Code programmieren, können bei der Versionierung präziser vorgehen, die Bereitstellung in mehr Umgebungen unterstützen, als WordPress es zulassen würde, und die Wartung drastisch vereinfachen.

Wir haben kürzlich eine Methode vorgestellt, wie man „Vanilla“-WordPress auf der Upsun Cloud mithilfe von Source Operations aktualisieren kann. Mit dieser Methode kannst du weiterhin ein schreibgeschütztes Dateisystem beibehalten, alles in Git committen und einen Endpunkt bereitstellen, der Updates in einem separaten Container auslöst – wodurch die traditionelle WordPress-Wartung mit unserer Plattform kompatibel wird.

Du kannst dies aber auch erreichen, indem du WordPress mit Composer, dem Paketverwaltungssystem von PHP, integrierst. Dies ist – wenig überraschend – schon seit einiger Zeit die empfohlene Vorgehensweise für die Bereitstellung von WordPress auf Platform.sh. Unsere WordPress-Vorlage basiert auf dem beliebten Composer-Fork von John Bloch, der die Standard-WordPress-Codebasis widerspiegelt und zusätzlich die Datei „composer.json“ hinzufügt, die erforderlich ist, um den WordPress-Kern als Abhängigkeit zu behandeln. Dasselbe Muster gilt für das riesige Ökosystem an WordPress-Themes und -Plugins, auf das man mit Composer über das WPackagist-Repository zugreifen kann.

Bedrock: der Einstieg in die WordPress-Entwicklung

Vieles, was Bedrock anders macht, beginnt schon bei der Projektstruktur. Klonen wir also eine lokale Kopie des Repos, um sie 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 erheblich von dem, was wir bei einem reinen WordPress sehen würden: Zum einen ist sie viel kleiner. Die meisten Dateien, die WordPress zum Laufen bringen – darunter WordPress-Kern-Dateien sowie Standard- und benutzerdefinierte Themes und Plugins – werden gar nicht erst ins Repository eingecheckt. Stattdessen werden diese Dateien bei Bedarf als Abhängigkeiten für die fertige Anwendung heruntergeladen, die alle in der Datei „composer.json“ 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 in `roots/wordpress` eine genaue WordPress-Version angegeben: 6.6.1. Genau diese Version wird bei jedem Build (wenn `composer install` ausgeführt wird) in ein Unterverzeichnis heruntergeladen – eine Vorgehensweise, die sich auch außerhalb der „Composer-optimierten“ WordPress-Versionen durchgesetzt hat.

Schon jetzt entgehen wir 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 festgeschrieben, und beim Befehl „composer install“ wird ausschließlich diese bestimmte Version heruntergeladen.

WordPress mit Composer erweitern

Das Gleiche gilt für Themes und Plugins. Du wirst jedoch feststellen, dass der „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 einem nicht festgeschriebenen Unterverzeichnis unter vendor installiert. Auf Platform.sh erfolgt die Installation über unseren Build-Flavor oder während deines Build-Hooks.

Die Sache ist nur: Das ist nicht der Ort, an dem wir den WordPress-Kern gerne haben möchten. Im obigen Snippet siehst du die Attribute extra.wordpress-install-dir und extra.installer-paths. Das erste weist Composer (über composer/installers) an, die von uns definierte WordPress-Version in web/wp herunterzuladen, und das zweite, Themes und Plugins in web/app zu installieren. Alles, was aus dem WordPress-Upstream stammt, befindet sich in einem Verzeichnis, und alles andere, was wir zu WordPress hinzufügen, kommt in ein anderes. Du wirst etwas Ähnliches bei deiner Konfiguration feststellen, die auf config isoliert wurde, komplett mit umgebungsabhängiger Steuerung. Hier ist alles klar getrennt, wird versionsverwaltet und ist dank Composer reproduzierbar.

Mit diesem Setup können wir viele Dinge ganz einfach erledigen. Wenn wir den WordPress-Kern sowie alle unsere Themes und Plugins aktualisieren wollen, müssen wir lediglich „composer update“ ausführen. Wir können das Erscheinungsbild der Seite mit einem Community-Theme über „composer require wpackagist-theme/magsoul“ anpassen (als Beispiel) und es dann nach der Bereitstellung im Admin-Dashboard aktivieren. Wenn wir die Seite zu einem Online-Shop ausbauen wollen, können wir das WooCommerce-Plugin auf dieselbe Weise hinzufügen:

$ composer require wpackagist-plugin/woocommerce

Wenn wir die Anwendung über die WordPress-CLI verwalten wollen:

$ composer require wp-cli/wp-cli

Jeder, der versucht, unsere Anwendung nachzubauen, muss lediglich composer install ausführen, um einen Beitrag dazu zu leisten. Alles ist eine Abhängigkeit und lässt sich vollständig über Composer installieren und aktualisieren.

Bereitstellung von Bedrock auf Upsun.com

All das wäre nun umsonst, wenn wir nicht auf die Bereitstellung eingehen würden, und genau hier eröffnet Bedrock wirklich neue Möglichkeiten bei der Konfiguration. Mit Bedrock kannst du Umgebungsvariablen nutzen, um eine Verbindung zur Datenbank herzustellen und Routing-Variablen wie WP_HOME und WP_SITEURL flexibler als beim herkömmlichen WordPress festzulegen. Das ist ein weiterer Bestandteil des Twelve-Factor-App-Konzepts: die in der Umgebung gespeicherte Konfiguration. Die Anwendung kann in viele verschiedene Umgebungen verschoben werden und behält dennoch denselben Build bei, solange diese Variablen definiert sind. Unten siehst du eine ähnliche „.environment“-Datei, die in unserer Platform.sh WordPress-Bedrock-Vorlage enthalten ist (die auf Upsun Cloud 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
# Uncomment this line if you would like development versions of WordPress on non-production environments.
# 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 Datenbankdienst-Informationen werden als eine Reihe von Umgebungsvariablen bereitgestellt, denen der Name des Datenbankdienstes vorangestellt ist, den wir in der Eigenschaft „relationships“ unserer Konfigurationsdatei definieren (siehe unten). In diesem Fall habe ich ihn „mariadb“ genannt, sodass den Dienstinformationen das Präfix „MARIADB_*“ vorangestellt wird. Bedrock benötigt jedoch, dass den Umgebungsvariablen das Präfix „DB_“ vorangestellt wird, daher ordnet der erste Block in der .environment-Datei die Informationen einfach so zu, wie es Bedrock erfordert.

Anschließend nutzen wir `jq`, um die primäre Route zu unserer Anwendung abzurufen, da sich die URL je nach Umgebung (Produktion vs. Staging vs. Entwicklung) ändert, sowie die Projektvariable `PLATFORM_PROJECT_ENTROPY` für unsere Sicherheitsvariablen. All diese können in unserer umgebungsspezifischen Konfiguration (im Unterverzeichnis `config`) aufgerufen werden. Die restliche Konfiguration ähnelt weitgehend dem, was du bereits in unserer Composer-WordPress-Vorlage für Platform.sh gesehen hast.

.upsun/config.yaml

.upsun/config.yaml ist ebenfalls ähnlich, einschließlich eines „Build-Hook“-Schritts, der es uns ermöglicht, auf Wunsch weiterhin Plugins zu nutzen, die nicht als Abhängigkeiten heruntergeladen werden können. Nicht jedes WordPress-Theme und -Plugin wurde mit Composer kompatibel gemacht (die Upstreams enthalten keine „composer.json“-Datei), daher ist es immer sinnvoll, diesen Schritt einzubauen. Im Gegensatz zu „.platform.app.yaml“ enthält die Konfigurationsdatei von Upsun Cloud auch Routen („routes.yaml“ bei Platform.sh) und unsere Dienste („services.yaml“ bei Platform.sh)

# .upsun/config.yaml
applications:
  wp-bedrock-upsun:
    source:
      root: "/"

    type: "php:8.3"

    relationships:
      mariadb:
    
    
    # Mounts define directories that are writable 
    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"


# The services of the project.
services:
  mariadb:
    type: mariadb:11.0



# The routes of the project.
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 jede deiner Abhängigkeiten herunter (das ist wiederum WordPress selbst, zusammen mit all deinen Themes und Plugins), stellt eine Verbindung zur Datenbank her und stellt Bedrock für dich bereit.

Speicherplatz

Ein wesentlicher Unterschied zwischen Platform.sh und Upsun.com besteht darin, dass du in der Konfigurationsdatei nicht festlegst, wie viel Speicherplatz du deinen Diensten und Anwendungs-Mounts zuweist. Stattdessen weist Upsun.com beim ersten Push automatisch 512 MB Speicherplatz sowohl dem MariaDB-Dienst als auch den Mounts zu, die WordPress für Uploads verwendet. Um den jeweils zugewiesenen Speicherplatz anzupassen, kannst du entweder die Konsole oder den CLI-Befehl `upsun resources:set` verwenden. Weitere Informationen findest du im Abschnitt „Ressourcen verwalten“ in der Dokumentation. 

Niemand kann sagen, wie die Zukunft von WordPress aussehen wird, aber man kann mit Sicherheit davon ausgehen, dass es weiterhin sehr beliebt bleiben wird. Bedrock bietet eine Möglichkeit, auf interessante Weise mit WordPress zu entwickeln. Die wenigen Einschränkungen, die es der Struktur deines Projekts auferlegt, eröffnen größere Flexibilität für schnelle Anpassungen und verringern gleichzeitig langfristig den Wartungsaufwand erheblich.