Die Verwaltung von Datenbankschemaänderungen in WordPress-Umgebungen ist oft eine fehleranfällige und zeitraubende Aufgabe. Eine einzige falsch gestellte SQL-Abfrage oder eine vergessene Datenbankänderung kann während der Bereitstellung zu einer Unterbrechung der Website führen. Außerdem fehlt es bei Aktionen wie manuellen SQL-Skripten und direkten Bearbeitungen an Versionskontrolle, Prüfpfaden und Koordination zwischen den Umgebungen.
Die Verwendung von Roots‘ Radicle (insbesondere Acorn) ist eine Lösung, die Laravel-Migrationen in WordPress ermöglicht. Du erhältst versionskontrollierte Datenbankänderungen, die zusammen mit deinem Code bereitgestellt werden, eine automatische Nachverfolgung, welche Änderungen durchgeführt wurden, und die Möglichkeit, Schemaänderungen bei Bedarf zurückzunehmen.
Wenn du dies mit der Infrastruktur und den Tools von Kinsta kombinierst, erhältst du eine Möglichkeit, die Ausführung von Migrationen während der Bereitstellung zu automatisieren.
Warum WordPress-Datenbankänderungen Versionskontrolle brauchen
Bei manuellen Datenbankänderungen werden Schemaänderungen als einmalige Operationen und nicht als versionierter Code behandelt. Du führst zum Beispiel eine SQL-Abfrage aus, um eine benutzerdefinierte Tabelle hinzuzufügen, eine ALTER TABLE-Anweisung, um Spalten hinzuzufügen, oder verlässt dich auf Plugin-Aktivierungshooks, um Aktualisierungen durchzuführen. Diese Lösungen funktionieren anfangs, aber sie versagen, wenn du mehrere Umgebungen verwaltest oder mit einem Team zusammenarbeitest.
Die Staging-Umgebungen weichen oft von den lokalen Umgebungen ab, wenn du vergisst, kleinere Änderungen zu dokumentieren (z. B. das Hinzufügen einer Spalte zur lokalen Datenbank), was auch dazu führt, dass der Produktionseinsatz fehlschlägt. Das bedeutet auch, dass es keinen Prüfpfad gibt.
Laravel-Migrationen sind eine gute Möglichkeit, diese Koordinationsfehler zu beseitigen, da sie Datenbankänderungen wie versionierten Code behandeln, der in deinem Git-Repository lebt. Dieser wird zusammen mit deiner Anwendung bereitgestellt und in jeder Umgebung in der gleichen Reihenfolge ausgeführt.
Wie Laravel-Migrationen in WordPress mit Acorn funktionieren
Laravel-Migrationen sind PHP-Dateien, die Änderungen am Datenbankschema durch zwei Methoden definieren: up() wendet die Änderungen an und down() macht sie rückgängig. Jede Migrationsdatei erhält einen Zeitstempel-Präfix, der die Reihenfolge der Ausführung bestimmt. Acorn von Roots bringt dieses Migrationssystem (und mehr) zu WordPress, ohne dass eine vollständige Laravel-Installation erforderlich ist.
Das Migrationssystem verfolgt anhand einer migrations Tabelle in deiner WordPress-Datenbank, welche Änderungen durchgeführt wurden. Wenn du wp acorn migrate ausführst, führt Acorn einige Aufgaben aus:
- Überprüft die Tabelle, um anstehende Migrationen zu identifizieren.
- Führt die Tabellen in chronologischer Reihenfolge aus, basierend auf den Zeitstempeln.
- Zeichnet jede erfolgreiche Migration auf.
Diese Nachverfolgung verhindert, dass Migrationen mehrfach ausgeführt werden, und zeigt dir genau, welche Schemaänderungen in einer Umgebung durchgeführt wurden.
Acorn integriert den Schema-Builder von Laravel, der eine flüssige PHP-Syntax zum Erstellen und Ändern von Datenbanktabellen bietet. Anstatt rohes SQL zu schreiben, verwendest du Methoden wie $table->string('key')->unique() oder $table->json('value')->nullable(). Dieser Ansatz bietet eine datenbankunabhängige Syntax, Typsicherheit und einen lesbareren Code als SQL-Anweisungen mit verketteten Strings.
Erstellen und Ausführen deiner ersten Migration
Du erstellst Migrationen über WP-CLI:
wp acorn make:migration create_app_settings_tableDabei wird eine neue Migrationsdatei im Verzeichnis database/migrations/ mit dem aktuellen Zeitstempel und dem von dir angegebenen Namen erstellt:
<?php
use IlluminateDatabaseMigrationsMigration;
use IlluminateDatabaseSchemaBlueprint;
use IlluminateSupportFacadesSchema;
return new class extends Migration
{
public function up(): void
{
Schema::create('app_settings', function (Blueprint $table) {
$table->id();
$table->string('key')->unique();
$table->json('value')->nullable();
$table->string('group')->default('general');
$table->boolean('is_public')->default(false);
$table->text('description')->nullable();
$table->timestamps();
$table->index('group');
$table->index('is_public');
});
}
public function down(): void
{
Schema::dropIfExists('app_settings');
}
};Die Methode up() erstellt die Tabelle mit Spalten zum Speichern von Schlüssel-Wert-Paaren, Gruppierungseinstellungen und zur Nachverfolgung, wann Einträge erstellt oder geändert wurden. Die Indizes auf group und is_public verbessern die Abfrageleistung. Die Methode down() löscht die Tabelle vollständig, so dass du die Migration rückgängig machen kannst.
Ausstehende Migrationen führst du mit dem Befehl wp acorn migrate aus. Dadurch werden alle noch nicht ausgeführten Migrationen ausgeführt, Tabellen erstellt und dein Datenbankschema geändert. Mit dem Befehl wp acorn migrate:status kannst du überprüfen, welche Migrationen ausgeführt wurden. Die Statusausgabe zeigt jede Migrationsdatei mit Indikatoren an, ob sie ausgeführt wurde.
Wenn du den letzten Stack von Migrationen rückgängig machen musst, verwendest du den Befehl wp acorn migrate:rollback. Dieser führt die Methode down() für jede Migration im letzten Stack aus, um die Änderungen rückgängig zu machen.
Überprüfen von Migrationen mit Database Studio
Nachdem du die Migrationen ausgeführt hast, kannst du mit dem Database Studio von Kinsta (oder einem anderen Datenbankwerkzeug) überprüfen, ob die erwarteten Tabellen und Spalten in der richtigen Struktur vorhanden sind. Du erreichst das Database Studio über das MyKinsta-Dashboard, indem du zu einer beliebigen Seite navigierst und auf die Registerkarte Datenbank klickst:
Mit der mitgelieferten SQL-Konsole kannst du Überprüfungsabfragen durchführen, um zu bestätigen, dass deine Migrationen die erwartete Struktur erstellt haben.
Nachdem du die Tabelle app_settings erstellt hast, kannst du mit der Abfrage DESCRIBE app_settings; die Spalten verifizieren. Sie liefert die Tabellenstruktur mit Spaltennamen, Typen und Indizes. Eine weitere Abfrage: SELECT * FROM app_settings; mit der du überprüfen kannst, ob die Tabelle Einfügungen zulässt.
Mit der Filterfunktion kannst du bestimmte Datensätze oder Spalten untersuchen, ohne SQL-Abfragen zu schreiben. Hier klickst du auf die Spaltenüberschriften, um zu sortieren, wendest Filter an, um die Ergebnisse einzugrenzen, und exportierst deine Daten:
Diese Exportoptionen sind nützlich, um Rollback-Prozeduren zu testen.
Migrationen mit SSH und WP-CLI auf Kinsta durchführen
Kinsta bietet in allen Paketen SSH-Zugang und WP-CLI. Das bedeutet, dass du Migrationsbefehle direkt in deinen Staging- und Produktionsumgebungen ausführen kannst, ohne dass zusätzliche Einstellungen erforderlich sind.
Um Migrationen in einer Kinsta-Umgebung durchzuführen, musst du dich zunächst per SSH mit ihr verbinden. Die Zugangsdaten findest du auf dem Info-Bildschirm für jede Seite in MyKinsta:
Nachdem du dich verbunden und authentifiziert hast, navigierst du zum Stammverzeichnis deiner Website. Bei Radicle-Seiten ist dies das Verzeichnis public. Als Nächstes führst du wp acorn migrate aus.
Der Migrationsprozess zeigt in der Ausgabe an, welche Migrationen laufen und welchen Status sie haben. Dies funktioniert auch in Staging- und Produktionsumgebungen, da Acorn die Migrationen unabhängig voneinander in der Datenbank der jeweiligen Umgebung verfolgt.
Migrationen in Kinsta-Staging-Umgebungen testen
Die Staging-Umgebungen von Kinsta sind ein sicherer Ort, um Migrationen zu testen, bevor du sie in die Produktion überführst, aber du brauchst einen zuverlässigen Workflow, um sie zu testen. Sobald du die Migrationsänderungen in Database Studio überprüft hast, solltest du das Rollback testen, um sicherzustellen, dass die Methode down() korrekt funktioniert.
Wechsle dazu in MyKinsta zu deiner Staging-Umgebung, gehe auf die Registerkarte Datenbank und überprüfe die Tabellen, die deine Migrationen erstellt oder geändert haben.
Wenn du während der Staging-Tests Probleme entdeckst, kannst du mit dem Befehl wp acorn migrate:rollback den letzten Stack von Migrationen rückgängig machen und Korrekturen vornehmen, ohne die Produktion zu beeinträchtigen. Du kannst dann deine Migrationsdateien ändern, die Änderungen festschreiben, erneut im Staging einsetzen und erneut testen.
Mit dem selektiven Push von Kinsta kannst du nur die Änderungen verteilen, die du getestet hast. Du kannst also wählen, ob du nur deine Dateien oder sowohl die Dateien als auch die Datenbank in die Produktion übertragen willst:
Bei Migrations-Workflows werden in der Regel nur die Dateien gepusht, da die Migrationen auf der bestehenden Produktionsdatenbank laufen und diese nicht mit Staging-Daten überschrieben wird.
Bereitstellungsworkflow mit automatisierten Migrationen
Automatisierte Migrations-Workflows führen Datenbankschemaänderungen durch, wenn der Code bereitgestellt wird, wodurch manuelle Schritte entfallen und Bereitstellungsfehler reduziert werden. Dies erreichst du, indem du Migrationsbefehle zu deinem Bereitstellungsprozess hinzufügst, egal ob es sich dabei um manuelle SSH-Skripte, die Automatisierung von GitHub-Aktionen oder Tools wie Trellis von Roots handelt.
Für die manuelle Bereitstellung per SSH verbindest du dich mit deiner Produktionsumgebung und navigierst zum Stammverzeichnis des Dokuments. Dann führst du die folgenden Befehle nacheinander aus:
git pull origin main
composer install --no-dev
npm install && npm run build
wp acorn optimize
wp acorn migrate --forceDas Flag --force weist Acorn an, Migrationen ohne Bestätigungsaufforderung auszuführen, was für automatisierte Verteilungen wichtig ist, bei denen du nicht mit dem Terminal interagieren kannst. Die Ausführung dieses Befehls nach wp acorn optimize stellt sicher, dass der Anwendungscache frisch ist, bevor die Migrationen ausgeführt werden.
Wenn du GitHub Actions für die kontinuierliche Bereitstellung verwendest, automatisierst du Migrationen in deiner Workflow-Datei. Radicle enthält eine .github/workflows/deploy.yml Konfiguration, die du anpasst, um einen Migrationsschritt nach dem Build-Prozess einzubauen:
- name: Run migrations
run: |
ssh user@host -p port 'cd /path/to/site && wp acorn migrate --force'Der Deployment-Workflow verbindet sich über SSH, navigiert zu deinem Site-Verzeichnis und führt den Migrationsbefehl aus.
Bei der Bereitstellung mit Trellis werden die Migrationen in die Bereitstellungshooks integriert. Sie werden durch die Änderung von deploy-hooks/finalize-after.yml eingebunden:
- name: Run Acorn migrations
command: wp acorn migrate --force
args:
chdir: "{{ deploy_helper.new_release_path }}"Dadurch werden Migrationen ausgeführt, nachdem Trellis andere Bereitstellungsaufgaben abgeschlossen hat. Die Migrationen werden im neuen Release-Verzeichnis ausgeführt, und Trellis kümmert sich um das Rollback, wenn die Bereitstellung fehlschlägt.
Versionskontrolle der Migrationsdateien mit Git
Die Migrationsdateien befinden sich im Verzeichnis database/migrations/ in deiner Radicle-Projektstruktur. Dieses Verzeichnis ist Teil deines Git-Repos, was bedeutet, dass die Migrationen zusammen mit deinem Code durch die Versionskontrolle laufen. Der Arbeitsablauf entspricht dem der Standardentwicklung: Erstelle die Migrationen lokal, übertrage sie in einen Funktionszweig und führe sie nach dem Testen in den Hauptzweig ein.
Der Commit-Workflow für Migrationen folgt einem einheitlichen Muster:
git add database/migrations/2025_01_03_140000_create_app_settings_table.php
git commit -m "Add app_settings table migration"
git push origin feature-branchSobald du die Migration überprüft hast, führst du den Funktionszweig auf main zusammen. Dadurch wird die Migration für den Staging- und Produktionseinsatz verfügbar.
Der Befehl wp acorn migrate:status stellt sicher, dass in allen Umgebungen die gleichen Migrationen angewendet werden. Du führst diesen Befehl in allen Umgebungen aus, um sicherzustellen, dass sie synchron sind. Wenn in einer Umgebung ausstehende Migrationen angezeigt werden, bedeutet dies, dass sie eine Bereitstellung oder einen manuellen Migrationslauf benötigt, um den Rückstand aufzuholen.
Rollback-Strategien und Datenbank-Backups
Allerdings sind nicht alle Migrationen vollständig umkehrbar. Während du eine Tabelle einfach löschen kannst, um ihre Erstellung rückgängig zu machen, ist eine Migration, bei der Daten gelöscht werden, eine dauerhafte Aktion. Manchmal kann dir down() sagen, warum ein Rollback nicht möglich ist:
public function down(): void
{
// This migration cannot be reversed as we're deleting data
Log::warning("Migration cannot be reversed - data permanently deleted");
}Es ist gut, diese Einschränkungen zu dokumentieren. Die automatischen Backups von Kinsta bieten ein Sicherheitsnetz. Deshalb ist es auch wichtig, ein manuelles Backup zu erstellen, bevor du eine Migration durchführst, die Probleme verursachen könnte:
Navigiere zu deiner Website, klicke auf Backups und erstelle ein Backup mit einem aussagekräftigen Namen. Wenn eine Migration unerwartete Probleme in der Produktion verursacht, stellst du sie über MyKinsta aus diesem Backup wieder her.
Bei Migrations-Rollbacks stellst du nur die Datenbank in der Produktionsumgebung wieder her. Die Wiederherstellung ist innerhalb weniger Minuten abgeschlossen und bringt deine Datenbank in den exakten Zustand, der im Backup erfasst wurde.
Zuverlässige Datenbank-Workflows für WordPress erstellen
Laravel-Migrationen durch die Acorn-Implementierung von Radicle machen aus dem, was oft für Unruhe sorgt, einen vorhersehbaren, versionskontrollierten Prozess. Die Kombination aus Migrationen als Code, den Staging-Umgebungen von Kinsta und Database Studio zur Überprüfung schafft einen Workflow, mit dem du Schemaprobleme erkennst, bevor sie die Produktion erreichen.
Moderne WordPress-Entwicklung mit Tools wie Radicle und Acorn bedeutet also, dass du dich nicht zwischen dem WordPress-Ökosystem und professionellen Tooling-Frameworks entscheiden musst. Das gleiche Muster gilt für Laravel-Warteschlangen, Blade-Templating und benutzerdefinierte WP-CLI-Befehle über Acorn.
Wenn du bereit bist, diesen Arbeitsablauf zu übernehmen, ist der nächste Schritt die Festlegung von Migrationskonventionen, wie z. B. die Definition von Namensmustern für Migrationsdateien, die Prozessdokumentation und die Festlegung von Testanforderungen vor wichtigen Zusammenführungen. Kinsta’s Managed Hosting für WordPress bietet integrierte Entwickler-Tools (z. B. SSH-Zugang, Staging-Umgebungen und Database Studio), die moderne Arbeitsabläufe, einschließlich Radicle- und Acorn-Migrationen, unterstützen.
Joel ist Frontend-Entwickler und arbeitet bei Kinsta als Technical Editor. Er ist ein leidenschaftlicher Lehrer mit einer Vorliebe für Open Source und hat über 200 technische Artikel geschrieben, die sich hauptsächlich um JavaScript und seine Frameworks drehen.
