Wenn du dies mit der Infrastruktur und den Tools von Kinsta kombinierst, erh\u00e4ltst du eine M\u00f6glichkeit, die Ausf\u00fchrung von Migrationen w\u00e4hrend der Bereitstellung zu automatisieren.<\/p>\n
Warum WordPress-Datenbank\u00e4nderungen Versionskontrolle brauchen<\/h2>\n
Bei manuellen Datenbank\u00e4nderungen werden Schema\u00e4nderungen als einmalige Operationen und nicht als versionierter Code behandelt. Du f\u00fchrst zum Beispiel eine SQL-Abfrage<\/a> aus, um eine benutzerdefinierte Tabelle hinzuzuf\u00fcgen, eine Die Staging-Umgebungen weichen oft von den lokalen Umgebungen ab, wenn du vergisst, kleinere \u00c4nderungen zu dokumentieren (z. B. das Hinzuf\u00fcgen einer Spalte zur lokalen Datenbank), was auch dazu f\u00fchrt, dass der Produktionseinsatz fehlschl\u00e4gt. Das bedeutet auch, dass es keinen Pr\u00fcfpfad gibt.<\/p>\n Laravel-Migrationen<\/a> sind eine gute M\u00f6glichkeit, diese Koordinationsfehler zu beseitigen, da sie Datenbank\u00e4nderungen 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\u00fchrt.<\/p>\n Laravel-Migrationen sind PHP-Dateien, die \u00c4nderungen am Datenbankschema durch zwei Methoden definieren: Das Migrationssystem verfolgt anhand einer Diese Nachverfolgung verhindert, dass Migrationen mehrfach ausgef\u00fchrt werden, und zeigt dir genau, welche Schema\u00e4nderungen in einer Umgebung durchgef\u00fchrt wurden.<\/p>\n Acorn integriert den Schema-Builder von Laravel, der eine fl\u00fcssige PHP-Syntax zum Erstellen und \u00c4ndern von Datenbanktabellen bietet. Anstatt rohes SQL zu schreiben, verwendest du Methoden wie Du erstellst Migrationen \u00fcber WP-CLI<\/a>:<\/p>\n Dabei wird eine neue Migrationsdatei im Verzeichnis Die Methode Ausstehende Migrationen f\u00fchrst du mit dem Befehl Wenn du den letzten Stack von Migrationen r\u00fcckg\u00e4ngig machen musst, verwendest du den Befehl Nachdem du die Migrationen ausgef\u00fchrt hast, kannst du mit dem Database Studio von Kinsta<\/a> (oder einem anderen Datenbankwerkzeug) \u00fcberpr\u00fcfen, ob die erwarteten Tabellen und Spalten in der richtigen Struktur vorhanden sind. Du erreichst das Database Studio \u00fcber das MyKinsta-Dashboard, indem du zu einer beliebigen Seite navigierst und auf die Registerkarte Datenbank<\/strong> klickst:<\/p>\n Mit der mitgelieferten SQL-Konsole kannst du \u00dcberpr\u00fcfungsabfragen durchf\u00fchren, um zu best\u00e4tigen, dass deine Migrationen die erwartete Struktur erstellt haben.<\/p>\n Nachdem du die Tabelle Mit der Filterfunktion kannst du bestimmte Datens\u00e4tze oder Spalten untersuchen, ohne SQL-Abfragen zu schreiben. Hier klickst du auf die Spalten\u00fcberschriften, um zu sortieren, wendest Filter an, um die Ergebnisse einzugrenzen, und exportierst deine Daten:<\/p>\n Diese Exportoptionen sind n\u00fctzlich, um Rollback-Prozeduren zu testen.<\/p>\n Kinsta bietet in allen Paketen SSH-Zugang<\/a> und WP-CLI. Das bedeutet, dass du Migrationsbefehle direkt in deinen Staging- und Produktionsumgebungen ausf\u00fchren kannst, ohne dass zus\u00e4tzliche Einstellungen erforderlich sind.<\/p>\n Um Migrationen in einer Kinsta-Umgebung durchzuf\u00fchren, musst du dich zun\u00e4chst per SSH mit ihr verbinden<\/a>. Die Zugangsdaten findest du auf dem Info-Bildschirm<\/strong> f\u00fcr jede Seite in MyKinsta:<\/p>\n Nachdem du dich verbunden und authentifiziert hast, navigierst du zum Stammverzeichnis deiner Website. Bei Radicle-Seiten ist dies das Verzeichnis Der Migrationsprozess zeigt in der Ausgabe an, welche Migrationen laufen und welchen Status sie haben. Dies funktioniert auch in Staging- und Produktionsumgebungen<\/a>, da Acorn die Migrationen unabh\u00e4ngig voneinander in der Datenbank der jeweiligen Umgebung verfolgt.<\/p>\n Die Staging-Umgebungen von Kinsta<\/a> sind ein sicherer Ort, um Migrationen zu testen, bevor du sie in die Produktion \u00fcberf\u00fchrst, aber du brauchst einen zuverl\u00e4ssigen Workflow, um sie zu testen. Sobald du die Migrations\u00e4nderungen in Database Studio \u00fcberpr\u00fcft hast, solltest du das Rollback testen, um sicherzustellen, dass die Methode Wechsle dazu in MyKinsta zu deiner Staging-Umgebung, gehe auf die Registerkarte Datenbank<\/strong> und \u00fcberpr\u00fcfe die Tabellen, die deine Migrationen erstellt oder ge\u00e4ndert haben.<\/p>\n Wenn du w\u00e4hrend der Staging-Tests Probleme entdeckst, kannst du mit dem Befehl Mit dem selektiven Push von Kinsta kannst du nur die \u00c4nderungen verteilen, die du getestet hast. Du kannst also w\u00e4hlen, ob du nur deine Dateien oder sowohl die Dateien als auch die Datenbank in die Produktion \u00fcbertragen willst:<\/p>\n 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 \u00fcberschrieben wird.<\/p>\n Automatisierte Migrations-Workflows f\u00fchren Datenbankschema\u00e4nderungen durch, wenn der Code bereitgestellt wird, wodurch manuelle Schritte entfallen und Bereitstellungsfehler reduziert werden. Dies erreichst du, indem du Migrationsbefehle zu deinem Bereitstellungsprozess hinzuf\u00fcgst, egal ob es sich dabei um manuelle SSH-Skripte, die Automatisierung von GitHub-Aktionen<\/a> oder Tools wie Trellis<\/a> von Roots handelt.<\/p>\n F\u00fcr die manuelle Bereitstellung per SSH verbindest du dich mit deiner Produktionsumgebung und navigierst zum Stammverzeichnis des Dokuments. Dann f\u00fchrst du die folgenden Befehle nacheinander aus:<\/p>\n Das Flag Wenn du GitHub Actions f\u00fcr die kontinuierliche Bereitstellung verwendest, automatisierst du Migrationen in deiner Workflow-Datei. Radicle enth\u00e4lt eine Der Deployment-Workflow verbindet sich \u00fcber SSH, navigiert zu deinem Site-Verzeichnis und f\u00fchrt den Migrationsbefehl aus.<\/p>\n Bei der Bereitstellung mit Trellis werden die Migrationen in die Bereitstellungshooks integriert. Sie werden durch die \u00c4nderung von Dadurch werden Migrationen ausgef\u00fchrt, nachdem Trellis andere Bereitstellungsaufgaben abgeschlossen hat. Die Migrationen werden im neuen Release-Verzeichnis ausgef\u00fchrt, und Trellis k\u00fcmmert sich um das Rollback, wenn die Bereitstellung fehlschl\u00e4gt.<\/p>\n Die Migrationsdateien befinden sich im Verzeichnis Der Commit-Workflow f\u00fcr Migrationen folgt einem einheitlichen Muster:<\/p>\n Sobald du die Migration \u00fcberpr\u00fcft hast, f\u00fchrst du den Funktionszweig auf Der Befehl Allerdings sind nicht alle Migrationen vollst\u00e4ndig umkehrbar. W\u00e4hrend du eine Tabelle einfach l\u00f6schen kannst, um ihre Erstellung r\u00fcckg\u00e4ngig zu machen, ist eine Migration, bei der Daten gel\u00f6scht werden, eine dauerhafte Aktion. Manchmal kann dir Es ist gut, diese Einschr\u00e4nkungen zu dokumentieren. Die automatischen Backups<\/a> von Kinsta bieten ein Sicherheitsnetz. Deshalb ist es auch wichtig, ein manuelles Backup zu erstellen, bevor du eine Migration durchf\u00fchrst, die Probleme verursachen k\u00f6nnte:<\/p>\n Navigiere zu deiner Website, klicke auf Backups<\/strong> und erstelle ein Backup mit einem aussagekr\u00e4ftigen Namen. Wenn eine Migration unerwartete Probleme in der Produktion verursacht, stellst du sie \u00fcber MyKinsta aus diesem Backup wieder her.<\/p>\n 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.<\/p>\n Laravel-Migrationen durch die Acorn-Implementierung<\/a> von Radicle<\/a> machen aus dem, was oft f\u00fcr Unruhe sorgt, einen vorhersehbaren, versionskontrollierten Prozess. Die Kombination aus Migrationen als Code, den Staging-Umgebungen von Kinsta und Database Studio zur \u00dcberpr\u00fcfung schafft einen Workflow, mit dem du Schemaprobleme erkennst, bevor sie die Produktion erreichen.<\/p>\n Moderne WordPress-Entwicklung mit Tools wie Radicle und Acorn bedeutet also, dass du dich nicht zwischen dem WordPress-\u00d6kosystem und professionellen Tooling-Frameworks entscheiden musst. Das gleiche Muster gilt f\u00fcr Laravel-Warteschlangen<\/a>, Blade-Templating<\/a> und benutzerdefinierte WP-CLI-Befehle \u00fcber Acorn.<\/p>\nALTER TABLE<\/code>-Anweisung, um Spalten hinzuzuf\u00fcgen, oder verl\u00e4sst dich auf Plugin-Aktivierungshooks, um Aktualisierungen durchzuf\u00fchren. Diese L\u00f6sungen funktionieren anfangs, aber sie versagen, wenn du mehrere Umgebungen verwaltest oder mit einem Team zusammenarbeitest.<\/p>\nWie Laravel-Migrationen in WordPress mit Acorn funktionieren<\/h2>\n
up()<\/code> wendet die \u00c4nderungen an und down()<\/code> macht sie r\u00fcckg\u00e4ngig. Jede Migrationsdatei erh\u00e4lt einen Zeitstempel-Pr\u00e4fix, der die Reihenfolge der Ausf\u00fchrung bestimmt. Acorn von Roots<\/a> bringt dieses Migrationssystem (und mehr) zu WordPress, ohne dass eine vollst\u00e4ndige Laravel-Installation erforderlich ist.<\/p>\nmigrations<\/code> Tabelle in deiner WordPress-Datenbank, welche \u00c4nderungen durchgef\u00fchrt wurden. Wenn du wp acorn migrate<\/code> ausf\u00fchrst, f\u00fchrt Acorn einige Aufgaben aus:<\/p>\n\n
$table->string('key')->unique()<\/code> oder $table->json('value')->nullable()<\/code>. Dieser Ansatz bietet eine datenbankunabh\u00e4ngige Syntax, Typsicherheit und einen lesbareren Code als SQL-Anweisungen mit verketteten Strings.<\/p>\nErstellen und Ausf\u00fchren deiner ersten Migration<\/h3>\n
wp acorn make:migration create_app_settings_table<\/code><\/pre>\ndatabase\/migrations\/<\/code> mit dem aktuellen Zeitstempel und dem von dir angegebenen Namen erstellt:<\/p>\n<?php\nuse IlluminateDatabaseMigrationsMigration;\nuse IlluminateDatabaseSchemaBlueprint;\nuse IlluminateSupportFacadesSchema;\n\nreturn new class extends Migration\n{\n public function up(): void\n {\n Schema::create('app_settings', function (Blueprint $table) {\n $table->id();\n $table->string('key')->unique();\n $table->json('value')->nullable();\n $table->string('group')->default('general');\n $table->boolean('is_public')->default(false);\n $table->text('description')->nullable();\n $table->timestamps();\n $table->index('group');\n $table->index('is_public');\n });\n }\n\n public function down(): void\n {\n Schema::dropIfExists('app_settings');\n }\n};<\/code><\/pre>\nup()<\/code> erstellt die Tabelle mit Spalten zum Speichern von Schl\u00fcssel-Wert-Paaren, Gruppierungseinstellungen und zur Nachverfolgung, wann Eintr\u00e4ge erstellt oder ge\u00e4ndert wurden. Die Indizes auf group<\/code> und is_public<\/code> verbessern die Abfrageleistung. Die Methode down()<\/code> l\u00f6scht die Tabelle vollst\u00e4ndig, so dass du die Migration r\u00fcckg\u00e4ngig machen kannst.<\/p>\nwp acorn migrate<\/code> aus. Dadurch werden alle noch nicht ausgef\u00fchrten Migrationen ausgef\u00fchrt, Tabellen erstellt und dein Datenbankschema ge\u00e4ndert. Mit dem Befehl wp acorn migrate:status<\/code> kannst du \u00fcberpr\u00fcfen, welche Migrationen ausgef\u00fchrt wurden. Die Statusausgabe zeigt jede Migrationsdatei mit Indikatoren an, ob sie ausgef\u00fchrt wurde.<\/p>\nwp acorn migrate:rollback<\/code>. Dieser f\u00fchrt die Methode down() <\/code>f\u00fcr jede Migration im letzten Stack aus, um die \u00c4nderungen r\u00fcckg\u00e4ngig zu machen.<\/p>\n\u00dcberpr\u00fcfen von Migrationen mit Database Studio<\/h2>\n
![\"Die](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/01\/database-studio.png\")
app_settings<\/code> erstellt hast, kannst du mit der Abfrage DESCRIBE app_settings;<\/code> die Spalten verifizieren. Sie liefert die Tabellenstruktur mit Spaltennamen, Typen und Indizes. Eine weitere Abfrage: SELECT * FROM app_settings;<\/code> mit der du \u00fcberpr\u00fcfen kannst, ob die Tabelle Einf\u00fcgungen zul\u00e4sst.<\/p>\n![\"Eine](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/01\/database-filters.png\")
Migrationen mit SSH und WP-CLI auf Kinsta durchf\u00fchren<\/h2>\n
![\"Der](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/01\/ssh-credentials.png\")
public<\/code>. Als N\u00e4chstes f\u00fchrst du wp acorn migrate<\/code> aus.<\/p>\nMigrationen in Kinsta-Staging-Umgebungen testen<\/h3>\n
![\"Der](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/01\/create-environment.png\")
down()<\/code> korrekt funktioniert.<\/p>\nwp acorn migrate:rollback<\/code> den letzten Stack von Migrationen r\u00fcckg\u00e4ngig machen und Korrekturen vornehmen, ohne die Produktion zu beeintr\u00e4chtigen. Du kannst dann deine Migrationsdateien \u00e4ndern, die \u00c4nderungen festschreiben, erneut im Staging einsetzen und erneut testen.<\/p>\n![\"Die](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/01\/selective-push.png\")
Bereitstellungsworkflow mit automatisierten Migrationen<\/h2>\n
git pull origin main\ncomposer install --no-dev\nnpm install && npm run build\nwp acorn optimize\nwp acorn migrate --force<\/code><\/pre>\n--force<\/code> weist Acorn an, Migrationen ohne Best\u00e4tigungsaufforderung auszuf\u00fchren, was f\u00fcr automatisierte Verteilungen wichtig ist, bei denen du nicht mit dem Terminal interagieren kannst. Die Ausf\u00fchrung dieses Befehls nach wp acorn optimize<\/code> stellt sicher, dass der Anwendungscache frisch ist, bevor die Migrationen ausgef\u00fchrt werden.<\/p>\n.github\/workflows\/deploy.yml<\/code> Konfiguration, die du anpasst, um einen Migrationsschritt nach dem Build-Prozess einzubauen:<\/p>\n- name: Run migrations\n run: |\n ssh user@host -p port 'cd \/path\/to\/site && wp acorn migrate --force'<\/code><\/pre>\ndeploy-hooks\/finalize-after.yml<\/code> eingebunden:<\/p>\n- name: Run Acorn migrations\n command: wp acorn migrate --force\n args:\n chdir: \"{{ deploy_helper.new_release_path }}\"<\/code><\/pre>\nVersionskontrolle der Migrationsdateien mit Git<\/h3>\n
database\/migrations\/<\/code> in deiner Radicle-Projektstruktur. Dieses Verzeichnis ist Teil deines Git-Repos<\/a>, was bedeutet, dass die Migrationen zusammen mit deinem Code durch die Versionskontrolle laufen. Der Arbeitsablauf entspricht dem der Standardentwicklung: Erstelle die Migrationen lokal, \u00fcbertrage sie in einen Funktionszweig und f\u00fchre sie nach dem Testen in den Hauptzweig ein.<\/p>\ngit add database\/migrations\/2025_01_03_140000_create_app_settings_table.php\ngit commit -m \"Add app_settings table migration\"\ngit push origin feature-branch<\/code><\/pre>\nmain<\/code> zusammen. Dadurch wird die Migration f\u00fcr den Staging- und Produktionseinsatz verf\u00fcgbar.<\/p>\nwp acorn migrate:status<\/code> stellt sicher, dass in allen Umgebungen die gleichen Migrationen angewendet werden. Du f\u00fchrst 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\u00f6tigt, um den R\u00fcckstand aufzuholen.<\/p>\nRollback-Strategien und Datenbank-Backups<\/h2>\n
down()<\/code> sagen, warum ein Rollback nicht m\u00f6glich ist:<\/p>\npublic function down(): void\n{\n \/\/ This migration cannot be reversed as we're deleting data\n Log::warning(\"Migration cannot be reversed - data permanently deleted\");\n}<\/code><\/pre>\n![\"Der](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/01\/manual-backups.png\")
Zuverl\u00e4ssige Datenbank-Workflows f\u00fcr WordPress erstellen<\/h2>\n