Als je dit combineert met de infrastructuur en tools van Kinsta, krijg je een manier om de uitvoering van migraties tijdens implementaties te automatiseren.<\/p>\n
Waarom WordPress databasewijzigingen versiebeheer nodig hebben<\/h2>\n
Handmatige databasewijzigingen behandelen schemawijzigingen als eenmalige operaties in plaats van code met versiebeheer. Je voert bijvoorbeeld een SQL query<\/a> uit om een custom tabel toe te voegen, voert een Testomgevingen beginnen vaak af te wijken van lokale omgevingen zodra je vergeet om kleinere wijzigingen te documenteren (zoals het toevoegen van een kolom aan de lokale database), waardoor ook productie deployments mislukken. Dit betekent ook dat er een auditspoor ontbreekt.<\/p>\n Laravel migraties<\/a> zijn een goede manier om deze co\u00f6rdinatiefouten te elimineren, omdat ze database wijzigingen behandelen als code onder versiebeheer die in je Git repository staat. Deze wordt samen met je applicatie gedeployd en in elke omgeving in dezelfde volgorde uitgevoerd.<\/p>\n Laravel migraties zijn PHP bestanden die database schemawijzigingen defini\u00ebren via twee methoden: Het migratiesysteem houdt bij welke wijzigingen zijn uitgevoerd met behulp van een Dit bijhouden voorkomt dat migraties meerdere keren worden uitgevoerd en laat je precies zien welke schemawijzigingen zijn toegepast op een omgeving.<\/p>\n Acorn integreert Laravel’s schema builder, die een vloeiende PHP syntaxis biedt voor het maken en wijzigen van databasetabellen. In plaats van ruwe SQL te schrijven, gebruik je methoden zoals Je maakt migraties via WP-CLI<\/a>:<\/p>\n Dit genereert een nieuw migratiebestand in de map De methode Je voert lopende migraties uit met het commando Als je de laatste batch migraties moet terugdraaien, gebruik je het commando Na het uitvoeren van migraties kun je met Database Studio van Kinsta<\/a> (of een ander databasetool) controleren of de verwachte tabellen en kolommen bestaan met de juiste structuur. Je opent Database Studio via het MyKinsta dashboard door naar een site te navigeren en op het tabblad Database<\/strong> te klikken:<\/p>\n Met de meegeleverde SQL Console kun je verificatiequery’s uitvoeren om te bevestigen dat je migraties de verwachte structuur hebben gecre\u00eberd.<\/p>\n Nadat je de tabel Met filteren kun je specifieke records of kolommen onderzoeken zonder SQL-query’s te schrijven. Hier klik je op kolomkoppen om te sorteren, filters toe te passen om de resultaten te beperken en je gegevens te exporteren:<\/p>\n Deze exportopties zijn handig voor het testen van rollbackprocedures.<\/p>\n Kinsta biedt SSH-toegang<\/a> en WP-CLI voor alle pakketten. Dit betekent dat je migratieopdrachten direct op je test- en productieomgevingen kunt uitvoeren zonder extra instellingen.<\/p>\n Om migraties uit te voeren op een Kinsta omgeving, maak je eerst verbinding met de omgeving via SSH<\/a>. De inloggegevens staan op het Info<\/strong> scherm voor elke site binnen MyKinsta:<\/p>\n Nadat je verbinding hebt gemaakt en je hebt geverifieerd, navigeer je naar de document root van je site. Voor Radicle sites is dit de Het migratieproces geeft uitvoer weer die laat zien welke migraties worden uitgevoerd en wat de voltooiingsstatus van elke migratie is. Dit werkt ook op test- en productieomgevingen<\/a> omdat Acorn migraties onafhankelijk bijhoudt in de database van elke omgeving.<\/p>\n Kinsta’s testomgevingen<\/a> zijn een veilige ruimte om migraties te testen voordat ze worden uitgerold naar productie, maar je hebt een betrouwbare workflow nodig om ze te testen. Zodra je de migratiewijzigingen binnen Database Studio hebt gecontroleerd, kun je rollback testen om er zeker van te zijn dat de Schakel hiervoor over naar je testomgeving in MyKinsta, navigeer naar het tabblad Database<\/strong> en inspecteer de tabellen die je migraties hebben gemaakt of gewijzigd.<\/p>\n Als je tijdens het testen problemen ontdekt, kun je met het commando Met Kinsta’s Selective Push kun je alleen de wijzigingen deployen die je hebt getest, dus je kunt ervoor kiezen om alleen je bestanden naar productie te pushen, of zowel de bestanden als de database:<\/p>\n Voor migratieworkflows push je meestal alleen bestanden, omdat migraties op de bestaande productiedatabase worden uitgevoerd in plaats van deze te overschrijven met testomgevingdata.<\/p>\n Geautomatiseerde migratieworkflows voeren databaseschemawijzigingen uit wanneer code wordt gedeployd, wat handmatige stappen elimineert en deploymentfouten vermindert. Je bereikt dit door migratiecommando’s toe te voegen aan je deploymentproces, of dat nu handmatige SSH scripts zijn, GitHub Actions<\/a> automatisering, of tools zoals Trellis<\/a> van Roots.<\/p>\n Voor handmatige deployments met SSH maak je verbinding met je productieomgeving en navigeer je naar de document root. Voer vervolgens achtereenvolgens deze commando’s uit:<\/p>\n De flag Als je GitHub Actions gebruikt voor continue implementatie, automatiseer je migraties in je workflow bestand. Radicle bevat een De deployment workflow maakt verbinding via SSH, navigeert naar je site directory en voert het migratiecommando uit.<\/p>\n Bij deployments met Trellis worden migraties ge\u00efntegreerd in de deploymenthooks. Je neemt het volgende op door Hiermee worden migraties uitgevoerd nadat Trellis andere deploymenttaken heeft voltooid. De migraties worden uitgevoerd in de nieuwe release map en Trellis zorgt voor rollback als de deployment mislukt.<\/p>\n Migratiebestanden staan in de De commit workflow voor migraties volgt een consistent patroon:<\/p>\n Als je de migratie hebt beoordeeld, voeg je de feature branch samen naar Het Niet alle migraties zijn echter volledig terug te draaien. Terwijl je een tabel eenvoudig kunt laten vallen om de creatie ervan ongedaan te maken, is een migratie waarbij gegevens worden verwijderd een permanente actie. Soms kan Het is goed om deze beperkingen te documenteren. Kinsta’s geautomatiseerde backups<\/a> bieden een vangnet, dus het is ook belangrijk om een handmatige backup te maken voordat je een migratie uitvoert die problemen kan veroorzaken:<\/p>\n Navigeer naar je site, klik op Backups<\/strong> en genereer een backup met een beschrijvende naam. Als een migratie onverwachte problemen veroorzaakt in productie, herstel je vanaf deze backup via MyKinsta.<\/p>\n Voor migratierollbacks herstel je alleen de database naar de productieomgeving. Het herstel is binnen enkele minuten voltooid en brengt je database terug naar de exacte staat die is vastgelegd in de backup.<\/p>\n Laravel migraties via Radicle’s<\/a> implementatie van Acorn<\/a> verandert wat vaak een bron van angst is in een voorspelbaar, versie-gecontroleerd proces. De combinatie van migraties-als-code, Kinsta’s testomgevingen en Database Studio voor verificatie cre\u00ebert een workflow waarbij je schema problemen opvangt voordat ze de productie bereiken.<\/p>\n Moderne WordPress ontwikkeling met tools als Radicle en Acorn betekent dat je niet hoeft te kiezen tussen het ecosysteem van WordPress en professionele frameworks voor tooling. Hetzelfde patroon geldt voor Laravel queue’s<\/a>, Blade templating<\/a> en custom WP-CLI commando’s via Acorn.<\/p>\nALTER TABLE<\/code> statement uit om kolommen toe te voegen of vertrouwt op plugin activeringshooks om updates af te handelen. Deze oplossingen werken in eerste instantie, maar lopen spaak als je meerdere omgevingen beheert of met een team werkt.<\/p>\nHoe Laravel migraties werken in WordPress met Acorn<\/h2>\n
up()<\/code> past de wijzigingen toe en down()<\/code> draait ze terug. Elk migratiebestand krijgt een timestamp prefix die de uitvoeringsvolgorde bepaalt. Roots’ Acorn<\/a> brengt dit migratiesysteem (en meer) naar WordPress zonder dat je een volledige Laravel installatie nodig hebt.<\/p>\nmigrations<\/code> tabel in je WordPress database. Wanneer je wp acorn migrate<\/code> uitvoert, voert Acorn een paar taken uit:<\/p>\n\n
$table->string('key')->unique()<\/code> of $table->json('value')->nullable()<\/code>. Deze aanpak biedt database-agnostische syntaxis, typeveiligheid en leesbaardere code dan SQL statements met aaneengeschakelde strings.<\/p>\nJe eerste migratie maken en uitvoeren<\/h3>\n
wp acorn make:migration create_app_settings_table<\/code><\/pre>\ndatabase\/migrations\/<\/code> met de huidige tijdstempel en de door jou opgegeven naam:<\/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> maakt de tabel aan met kolommen voor het opslaan van sleutelwaardeparen, groeperingsinstellingen en om bij te houden wanneer items zijn aangemaakt of gewijzigd. De indexen op group<\/code> en is_public<\/code> verbeteren de queryprestaties. De methode down()<\/code> verwijdert de tabel volledig, waardoor je de migratie kunt terugdraaien.<\/p>\nwp acorn migrate<\/code>. Dit voert alle migraties uit die nog niet zijn uitgevoerd, maakt tabellen aan en wijzigt je databaseschema. Je controleert welke migraties zijn uitgevoerd met het commando wp acorn migrate:status<\/code>. De statusuitvoer toont elk migratiebestand met indicatoren of het is uitgevoerd.<\/p>\nwp acorn migrate:rollback<\/code>. Dit voert de methode down()<\/code> uit voor elke migratie in de laatste batch om de wijzigingen ongedaan te maken.<\/p>\nMigraties controleren met Database Studio<\/h2>\n
![\"Het](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/01\/database-studio.png\")
app_settings<\/code> hebt gemaakt, kun je met de query DESCRIBE app_settings;<\/code> de kolommen controleren. Deze retourneert de tabelstructuur met kolomnamen, -types en -indexen. Een andere query: SELECT * FROM app_settings;<\/code>, laat je testen of de tabel invoegingen accepteert.<\/p>\n![\"Een](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/01\/database-filters.png\")
Migraties uitvoeren met SSH en WP-CLI op Kinsta<\/h2>\n
![\"Het](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/01\/ssh-credentials.png\")
public<\/code> directory. Vervolgens voert u wp acorn migrate<\/code> uit.<\/p>\nMigraties testen in Kinsta testomgevingen<\/h3>\n
![\"De](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/01\/create-environment.png\")
down()<\/code> methode correct werkt.<\/p>\nwp acorn migrate:rollback<\/code> de laatste batch migraties terugdraaien en correcties aanbrengen zonder de productie te be\u00efnvloeden. Je kunt dan je migratiebestanden aanpassen, de wijzigingen vastleggen, opnieuw naar staging implementeren en opnieuw testen.<\/p>\n![\"De](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/01\/selective-push.png\")
Deploymentworkflow met geautomatiseerde migraties<\/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> vertelt Acorn om migraties uit te voeren zonder bevestigingsvragen, wat essentieel is voor geautomatiseerde deployments waarbij je geen interactie met de terminal kunt hebben. Het uitvoeren van dit commando na wp acorn optimize<\/code> zorgt ervoor dat de applicatiecache up-to-date is voordat de migraties worden uitgevoerd.<\/p>\n.github\/workflows\/deploy.yml<\/code> configuratie die je aanpast om een migratiestap op te nemen na het bouwproces:<\/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> aan te passen:<\/p>\n- name: Run Acorn migrations\n command: wp acorn migrate --force\n args:\n chdir: \"{{ deploy_helper.new_release_path }}\"<\/code><\/pre>\nVersiebeheer van migratiebestanden met Git<\/h3>\n
database\/migrations\/<\/code> map binnen je Radicle projectstructuur. Deze map is onderdeel van je Git repo<\/a>, wat betekent dat migraties met je code meereizen via versiebeheer. De workflow weerspiegelt de standaard ontwikkeling: maak migraties lokaal, commit ze naar een feature branch en voeg ze samen naar main na het testen.<\/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>. Dit maakt de migratie beschikbaar voor staging en productie implementaties.<\/p>\nwp acorn migrate:status<\/code> commando controleert of op alle omgevingen dezelfde migraties zijn toegepast. Je voert dit uit op alle omgevingen om te bevestigen dat ze synchroon zijn. Als een omgeving hangende migraties toont, geeft dit aan dat er een deployment of handmatige migratie moet worden uitgevoerd om de achterstand in te halen.<\/p>\nTerugdraaistrategie\u00ebn en database-backups<\/h2>\n
down()<\/code> je vertellen waarom een rollback niet mogelijk is:<\/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![\"Het](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/01\/manual-backups.png\")
Betrouwbare databaseworkflows bouwen voor WordPress<\/h2>\n