Het beheren van database schemawijzigingen in WordPress omgevingen is vaak een foutgevoelige en tijdrovende taak. Een enkele misplaatste SQL query of vergeten databasewijziging kan een site-slopende actie zijn tijdens deployment. Bovendien ontbreekt het bij acties zoals handmatige SQL scripts en directe bewerkingen aan versiebeheer, audit trails en coördinatie tussen omgevingen.
Het gebruik van Roots’ Radicle (specifiek Acorn) is één oplossing, omdat het Laravel migraties naar WordPress brengt. Je krijgt versiegestuurde databasewijzigingen die samen met je code worden uitgerold, automatische tracering van welke wijzigingen zijn uitgevoerd en de mogelijkheid om schemawijzigingen terug te draaien als dat nodig is.
Als je dit combineert met de infrastructuur en tools van Kinsta, krijg je een manier om de uitvoering van migraties tijdens implementaties te automatiseren.
Waarom WordPress databasewijzigingen versiebeheer nodig hebben
Handmatige databasewijzigingen behandelen schemawijzigingen als eenmalige operaties in plaats van code met versiebeheer. Je voert bijvoorbeeld een SQL query uit om een custom tabel toe te voegen, voert een ALTER TABLE 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.
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.
Laravel migraties zijn een goede manier om deze coördinatiefouten 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.
Hoe Laravel migraties werken in WordPress met Acorn
Laravel migraties zijn PHP bestanden die database schemawijzigingen definiëren via twee methoden: up() past de wijzigingen toe en down() draait ze terug. Elk migratiebestand krijgt een timestamp prefix die de uitvoeringsvolgorde bepaalt. Roots’ Acorn brengt dit migratiesysteem (en meer) naar WordPress zonder dat je een volledige Laravel installatie nodig hebt.
Het migratiesysteem houdt bij welke wijzigingen zijn uitgevoerd met behulp van een migrations tabel in je WordPress database. Wanneer je wp acorn migrate uitvoert, voert Acorn een paar taken uit:
- Controleert de tabel om lopende migraties te identificeren.
- Voert tabellen in chronologische volgorde uit op basis van de tijdstempels.
- Registreert elke succesvolle migratie.
Dit bijhouden voorkomt dat migraties meerdere keren worden uitgevoerd en laat je precies zien welke schemawijzigingen zijn toegepast op een omgeving.
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 $table->string('key')->unique() of $table->json('value')->nullable(). Deze aanpak biedt database-agnostische syntaxis, typeveiligheid en leesbaardere code dan SQL statements met aaneengeschakelde strings.
Je eerste migratie maken en uitvoeren
Je maakt migraties via WP-CLI:
wp acorn make:migration create_app_settings_tableDit genereert een nieuw migratiebestand in de map database/migrations/ met de huidige tijdstempel en de door jou opgegeven naam:
<?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');
}
};De methode up() 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 en is_public verbeteren de queryprestaties. De methode down() verwijdert de tabel volledig, waardoor je de migratie kunt terugdraaien.
Je voert lopende migraties uit met het commando wp acorn migrate. 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. De statusuitvoer toont elk migratiebestand met indicatoren of het is uitgevoerd.
Als je de laatste batch migraties moet terugdraaien, gebruik je het commando wp acorn migrate:rollback. Dit voert de methode down() uit voor elke migratie in de laatste batch om de wijzigingen ongedaan te maken.
Migraties controleren met Database Studio
Na het uitvoeren van migraties kun je met Database Studio van Kinsta (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 te klikken:
Met de meegeleverde SQL Console kun je verificatiequery’s uitvoeren om te bevestigen dat je migraties de verwachte structuur hebben gecreëerd.
Nadat je de tabel app_settings hebt gemaakt, kun je met de query DESCRIBE app_settings; de kolommen controleren. Deze retourneert de tabelstructuur met kolomnamen, -types en -indexen. Een andere query: SELECT * FROM app_settings;, laat je testen of de tabel invoegingen accepteert.
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:
Deze exportopties zijn handig voor het testen van rollbackprocedures.
Migraties uitvoeren met SSH en WP-CLI op Kinsta
Kinsta biedt SSH-toegang en WP-CLI voor alle pakketten. Dit betekent dat je migratieopdrachten direct op je test- en productieomgevingen kunt uitvoeren zonder extra instellingen.
Om migraties uit te voeren op een Kinsta omgeving, maak je eerst verbinding met de omgeving via SSH. De inloggegevens staan op het Info scherm voor elke site binnen MyKinsta:
Nadat je verbinding hebt gemaakt en je hebt geverifieerd, navigeer je naar de document root van je site. Voor Radicle sites is dit de public directory. Vervolgens voert u wp acorn migrate uit.
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 omdat Acorn migraties onafhankelijk bijhoudt in de database van elke omgeving.
Migraties testen in Kinsta testomgevingen
Kinsta’s testomgevingen 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 down() methode correct werkt.
Schakel hiervoor over naar je testomgeving in MyKinsta, navigeer naar het tabblad Database en inspecteer de tabellen die je migraties hebben gemaakt of gewijzigd.
Als je tijdens het testen problemen ontdekt, kun je met het commando wp acorn migrate:rollback de laatste batch migraties terugdraaien en correcties aanbrengen zonder de productie te beïnvloeden. Je kunt dan je migratiebestanden aanpassen, de wijzigingen vastleggen, opnieuw naar staging implementeren en opnieuw testen.
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:
Voor migratieworkflows push je meestal alleen bestanden, omdat migraties op de bestaande productiedatabase worden uitgevoerd in plaats van deze te overschrijven met testomgevingdata.
Deploymentworkflow met geautomatiseerde migraties
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 automatisering, of tools zoals Trellis van Roots.
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:
git pull origin main
composer install --no-dev
npm install && npm run build
wp acorn optimize
wp acorn migrate --forceDe flag --force 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 zorgt ervoor dat de applicatiecache up-to-date is voordat de migraties worden uitgevoerd.
Als je GitHub Actions gebruikt voor continue implementatie, automatiseer je migraties in je workflow bestand. Radicle bevat een .github/workflows/deploy.yml configuratie die je aanpast om een migratiestap op te nemen na het bouwproces:
- name: Run migrations
run: |
ssh user@host -p port 'cd /path/to/site && wp acorn migrate --force'De deployment workflow maakt verbinding via SSH, navigeert naar je site directory en voert het migratiecommando uit.
Bij deployments met Trellis worden migraties geïntegreerd in de deploymenthooks. Je neemt het volgende op door deploy-hooks/finalize-after.yml aan te passen:
- name: Run Acorn migrations
command: wp acorn migrate --force
args:
chdir: "{{ deploy_helper.new_release_path }}"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.
Versiebeheer van migratiebestanden met Git
Migratiebestanden staan in de database/migrations/ map binnen je Radicle projectstructuur. Deze map is onderdeel van je Git repo, 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.
De commit workflow voor migraties volgt een consistent patroon:
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-branchAls je de migratie hebt beoordeeld, voeg je de feature branch samen naar main. Dit maakt de migratie beschikbaar voor staging en productie implementaties.
Het wp acorn migrate:status 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.
Terugdraaistrategieën en database-backups
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 down() je vertellen waarom een rollback niet mogelijk is:
public function down(): void
{
// This migration cannot be reversed as we're deleting data
Log::warning("Migration cannot be reversed - data permanently deleted");
}Het is goed om deze beperkingen te documenteren. Kinsta’s geautomatiseerde backups bieden een vangnet, dus het is ook belangrijk om een handmatige backup te maken voordat je een migratie uitvoert die problemen kan veroorzaken:
Navigeer naar je site, klik op Backups en genereer een backup met een beschrijvende naam. Als een migratie onverwachte problemen veroorzaakt in productie, herstel je vanaf deze backup via MyKinsta.
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.
Betrouwbare databaseworkflows bouwen voor WordPress
Laravel migraties via Radicle’s implementatie van Acorn 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ëert een workflow waarbij je schema problemen opvangt voordat ze de productie bereiken.
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, Blade templating en custom WP-CLI commando’s via Acorn.
Als je klaar bent voor deze workflow, is de volgende stap het vaststellen van migratieconventies, zoals het definiëren van naamgevingspatronen voor migratiebestanden, procesdocumentatie en het vaststellen van testvereisten voordat belangrijke samenvoegingen plaatsvinden. Kinsta’s managed hosting voor WordPress biedt ingebouwde hulpmiddelen voor ontwikkelaars (zoals SSH-toegang, staging-omgevingen en Database Studio) die moderne workflows ondersteunen, waaronder Radicle en Acorn migraties.
