Eine WordPress-Website aufsetzen: Das ist heute kein Hexenwerk mehr. Diverse Anleitungen im Netz und automatisierte Dienste von Hosting-Anbietern helfen dabei. Doch mit der Projekt- und Teamgröße steigt auch der Schwierigkeitsgrad für die Aufrechterhaltung und (Weiter-)Entwicklung eines WordPress-Projekts. Alle Beteiligten müssen den neuesten Stand möglichst gut kennen und einen grundlegenden Überblick haben. Außerdem muss sich die Seite im Notfall in ihren Ursprungszustand zurücksetzen lassen – ohne dass die Entwickler des Teams dadurch ihre Stunden in die Wiederherstellung ihrer Arbeit anstatt in die Weiterentwicklung stecken müssen.

Um das zu bewerkstelligen, gibt es verschiedene mögliche Herangehensweise und dazugehörige Werkzeuge. Jedes Team und Projekt muss zwar für sich den genau passenden Workflow selbst entwickeln, doch die hier beschriebenen Arbeitsabläufe eignen sich für neue und die meisten bereits bestehenden Projekte.

Größere WordPress-Projekte verlangen Entwicklern etwas mehr als üblich ab. Selbst diejenigen, die sich im Umgang mit PHP und der Entwicklung von WordPress-Plugins und -Themes sicher fühlen, können dabei noch das ein oder andere dazulernen. Neben einer guten IDE – wie beispielsweise PHPStorm – sollten die folgenden Werkzeuge in großen Projekten auf keinem Entwicklergerät fehlen.

GIT ist die wohl bekannteste Lösung, um Code zu speichern und zu versionieren. Mit Diensten wie GitHub oder BitBucket erhalten Entwicklerteams mächtige Werkzeuge, um den Fortschritt ihrer Arbeit festzuhalten, gemeinsam zu entwickeln und Code zu teilen.

Composer ist ein PHP-Dependency-Manager, mit dem Entwickler PHP-Pakete in Abhängigkeit voneinander herunterladen und stets auf dem neuesten Stand halten können. Dazu gehören auch WordPress-Plugins und -Themes – und das nicht nur Client- sondern auch Serverseitig.

Der Deployer ist nur eines von zahlreichen Werkzeugen, mit denen sich Code auf Servern deployen lässt. Deployer erweist sich aber als eines des unkompliziertesten Tools. Es führt eine Reihe von definierten SSH-Kommandos auf dem Ziel-Server aus. Damit können Entwickler ihre Codebase über Composer und GIT aktualisieren oder andere Aufgaben voll automatisiert durchführen.

Das WP-Starter-Paket liefert den einfachsten Weg, um eine WordPress-Installation mit Hilfe des Tools Composers zusammenzustellen und aufzusetzen.

WP-CLI bringt WordPress auf die Kommandozeile. Mit ihr können Entwickler unter anderem Plugins aktualisieren, Seiten konfigurieren und Änderungen an einer Datenbank vornehmen – und das alles, ohne auch nur einmal das WordPress-Interface bemühen zu müssen. WP-CLI lässt sich außerdem relativ einfach um eigene Routinen erweitern, sodass sich spezielle, auf das Projekt zugeschnittene Abläufe automatisiert über die Kommandozeile realisieren lassen.

Auch bei der Entwicklung großer WordPress-Projekte kann sich zwar jeder Entwickler eine eigene Test-Umgebung einrichten. Entwicklerteams sollten daneben aber mit mindestens drei Servern arbeiten:

Auf dem Development- oder auch DEV-Server findet die eigentliche Entwicklung statt. Die Programmierer können hier sämtlichen Code (mehr oder weniger) ungetestet deployen. Der Direkt-Upload ohne GIT und Composer ist explizit erlaubt, um eine schnelle Entwicklung auch ohne Entwickler-eigenes Testsystem zu ermöglichen.

Gerade für Designer, die lediglich CSS-Dateien über FTP hochladen wollen, ist dieser Server die perfekte Spielwiese. Allerdings sollten die Teams sicherstellen, dass die Projektbeteiligten nicht gegeneinander arbeiten – also sich gegenseitig nicht die Dateien zerschießen.

Auf dem Staging-Server testen die Entwickler oder Entwicklerteams sämtlichen Code, bevor er live geht. Das Deployment findet hier nur über die oben genannten Werkzeuge statt, sodass der Prozess möglichst nah an dem späteren Szenario beim Deployment auf den Production-Server herankommt. Die Konfiguration des Staging-Servers sollte möglichst eng an die des Production-Servers angelehnt sein, sodass das Team unter Quasi-Realbedingungen testen kann.

Der Production-Server ist für den öffentlichen Einsatz bestimmt und beherbergt den getesteten und freigegebenen Code. Alles, was auf diesem Server landet, sollte vorher auf dem Staging-Server überprüft und von Fehlern bereinigt sein.

Auf allen drei Servern gilt es, GIT, Composer und WP-CLI zur Verfügung zu stellen. Außerdem sollten die drei Server sämtliche Repositories (auch die nicht-öffentlichen) über SSH klonen. Wie das bei GitHub und BitBucket geht, beschreiben die Dokumentationen der Anbieter. Auf allen Servern sollte sich außerdem PHP über die Kommandozeile ausführen lassen.

Mit WPStarter ist das Anlegen einer WordPress-Installation fast so einfach wie mit dem eigentlichen WordPress-Installer. Zunächst mag der Vorgang zwar unnötig kompliziert erscheinen, doch der kleine Umweg lohnt sich. Zur Installation gehören nur die folgenden drei Schritte:

1. composer.json anlegen
2. composer install ausführen
3. Umgebungsvariablen einrichten

Der Autor von WPStarter zeigt in einem Quick-Start ein Beispiel für eine grundlegende composer.json. Entwickler können diese aber auch ihren Bedürfnissen anpassen. Ist die composer.json angelegt, muss man nur noch den Befehl „composer install“ über die Kommandozeile im Projektordner ausführen – und schon lädt die Anwendung sämtliche Abhängigkeiten, die in der composer.json definiert sind, herunter.

Eine der heruntergeladenen Dateien ist die .env.example, die ein Entwickler nur noch kopieren, als .env abspeichern und mit den entsprechenden Einstellungen für die Installation bestücken muss. Dabei sollte er zumindest die Datenbank-Einstellungen und die URL der Website setzen. Diesen Schritt muss er auf jedem Server und jeder (lokalen) Test-Umgebung durchführen. WordPress lässt sich nun über WP-CLI oder über den WordPress-Installer installieren.

Der folgende Befehl liefert das Administrator-Passwort zurück. Die WordPress-Webseite ist nun bereit.

$ wp core install --url=http://meine-testseite.de --title=Test --admin_user=admin --admin_email=admin@test.de

Mit WP-Starter und Composer lassen sich Plugins und Themes aus dem WordPress-Repository ganz einfach zu einem Projekt hinzufügen. Der Dienst WordPress Packagist stellt diese Plugins und Themes für Composer zur Verfügung.

Das Composer Repository von WPackagist liegt bereits als Quelle im WP-Starter-Paket. Über „composer require wpackagist-plugin/plugin-name:version“ oder „composer require wpackagist-theme/theme-name:version“ lassen sich die Plugins und Themes ins Projekt laden.

Eigene Plugins und Themes können Entwicklerteams hingegen über das Werkzeug GIT für Composer bereitstellen. Hierfür sollten das Theme oder die Plugins eine composer.json im jeweiligen Hauptverzeichnis enthalten. Diese kann aber auch ganz minimal gehalten sein:

{
  "name": "imbaa/test-plugin",
  "description": "Ein Test Plugin",
  "type": "wordpress-theme"
}

In der composer.json des Projekts muss der Entwickler nun nur noch das GIT-Repository hinterlegen, sodass Composer die Plugins und Themes über „composer require“ als Abhängigkeit beziehen kann. Composer kann neben GIT- auch auf Subversion-, Mercurial- und Fossil-Repositories zugreifen.

"repositories": [
        {
            "type": "vcs",
            "url": "git@bitbucket.org:imbaa/test-plugin.git"
        }
    ]

Der Deployer lässt sich zwar einfach über Composer zum Projekt hinzufügen. Es lohnt sich aber, den Deployer global auf jedem Entwicklersystem, das später auch das Deployment durchführen soll, zur Verfügung zu stellen.

curl -LO https://deployer.org/deployer.phar
mv deployer.phar /usr/local/bin/dep
chmod +x /usr/local/bin/dep

Über den Befehl „dep init“ können Entwickler ein grundlegendes Rezept generieren. Der Deployer erstellt dabei eine zusätzliche PHP-Datei (deploy.php), die den Zielserver definiert, sowie vom System beschreibbare Ordner und für jedes Deployment gemeinsame Dateien und Ordner, die nicht bei jedem Deployment überschrieben werden sollen. Ein grundlegendes Rezept für WordPress kann folgendermaßen aussehen:

 <?php
require 'recipe/composer.php';
// Haupt-Repository des Projekts
set('repository', 'git@bitbucket.org:imbaa/imbaa-website.git');
// Shared Files, die als Symlink auf dem Zielserver eingebunden werden
set(
    'shared_files',
    [
        '.env',
        'public/robots.txt',
        'public/.htaccess',
        'public/wp-content/debug.log'
    ]
);
// Shared Directories, die als Symlink auf dem Server eingebunden werden
set(
    'shared_dirs',
    [
        'public/wp-content/uploads',
        'public/wp-content/cache',
        'public/wp-content/tmp',
        'public/wp-content/languages'
    ]
);
set('writable_dirs', []);
// Configure servers
server('dev', 'home.imbaa.de')
    ->user('username')
    ->env('deploy_path', '/var/www/dev.imbaa.de')
    ->identityFile(); // Über SSH-Key authentifizieren
server('stage', 'imbaa.de')
    ->user('imbaa')
    ->env('deploy_path', '/var/www/stage.imbaa.de')
    ->identityFile();
server('live', 'imbaa.de')
    ->user('imbaa')
    ->env('deploy_path', '/var/www/ imbaa.de')
    ->identityFile();

Mit dem Befehl „dep deploy dev“ können Entwickler nun ein Deployment auf dem Development-Server auslösen. Der Server klont dabei das oben definierte Repository und führt Composer aus. Beim ersten Deployment-Vorgang legt das Werkzeug dann zusätzliche Ordner an.

Im Ordrner „releases“ befinden sich die Kopien der Daten aus dem Repository. Jeder Deployment-Vorgang erzeugt einen neuen Unterordner, sodass das Team jederzeit zum ursprünglichen Zustand des WordPress-Projekts zurückkehren kann. Im Ordner „shared“ liegen die als gemeinsam definierten Dateien und Ordner. Zusätzlich dazu entsteht ein Symlink „current“, der bei einem erfolgreichen Deployment auf das jeweilige Release im „releases“-Ordner zeigt. Diesen Symlink sollte man auch als Document Root des Webservers definieren.

Beim Deployment führt ein WP-Starter-Projekt einige automatische Prozeduren aus. Scheitern diese, bricht der Deployment-Prozess ab und aktualisiert den Symlink nicht. So merken User bei einem fatalen Fehler meistens nichts von einem auftretenden Problem. Sollte aber doch mal etwas richtig schiefgehen, kann das Team mit „dep rollback“ auf das vorhergehende Release zurückspringen.

Besonders für kleine Teams ist es oft nicht leicht, gewohnte Routinen zu verändern – etwa das „einfache Hochladen“ oder Installieren von Plugins und Themes über die Bordmittel von WordPress. Doch die Umstellung lohnt sich, die zusätzlichen Werkzeuge in den Arbeitsablauf aufzunehmen. Denn nur so kann das Team tatsächlich sicherstellen, dass alle auf einem möglichst aktuellen Stand sind und sich jeder Arbeitsschritt zurückverfolgen lässt. Probleme sind frühzeitig auf dem DEV- und Staging-System sichtbar und lassen sich somit beheben, bevor sie zu Schwierigkeiten im Live-Betrieb führen. Dass sich dadurch einige Prozesse – die sonst viel schneller von der Hand gehen – gegebenenfalls in die Länge ziehen, sollte Entwickler deshalb keineswegs abschrecken.