Maarten
WP-CLI developer
WP-CLI · Deploys · Cron · Multisite
WP-CLI developer
WP-CLI developer inhuren voor eigen commands, deploys die elke keer hetzelfde verlopen, veilige migraties en geplande taken die ook 's nachts draaien: freelance, met 25 jaar ervaring, vanuit Nijmegen en remote door heel Nederland.
Eerder gebouwd voor Autovisie.
Eén ervaren freelancer
WP-CLI developer inhuren voor je WordPress-beheer
Een inventarisatie van het terugkerende handwerk, de releases en de geplande taken, gevolgd door commando's en scripts die dat werk herhaalbaar maken. Alles in Git, met een dry-run waar het kan. Vooraf is er een gesprek nodig om te weten wat er speelt, niet andersom.
- Inventarisatie van terugkerend handwerk
- Eigen commands, deploys en echte cron
- Scripts in Git, met dry-run en logging
- Direct contact, geen tussenlagen
Voorbeelden van opgeleverd werk
Het autoplatform voor een toonaangevend automerk
Website, abonnementsmodel en een prettige redactieomgeving, ontwikkeld op WordPress.
Waarom een WP-CLI developer meer doet dan commando's typen
WP-CLI is de officiële command-line interface voor WordPress. Alles wat in wp-admin met klikken gebeurt, kan ook met een commando vanaf de server: plug-ins bijwerken, gebruikers aanmaken, de database exporteren of een URL vervangen in alle tabellen. Leren hoe je wp plugin update --all typt, kost weinig tijd. Een deploy die op staging en productie precies hetzelfde verloopt, een migratie van een grote hoeveelheid content die na een onderbreking kan worden hervat, of een geplande taak die ook 's nachts zonder bezoekers draait, vraagt om meer. Daar zit het werk van een WP-CLI developer: niet in het kennen van de commando's, maar in het bouwen van processen die herhaalbaar, gelogd en veilig zijn.
Een freelance WP-CLI developer inhuren betekent, in de praktijk, iemand die WordPress van binnenuit kent en ook thuis is op de server: SSH, Bash, Git, Composer en de CI-pipeline waar een deploy doorheen loopt. Vanuit Nijmegen wordt er gewerkt voor opdrachtgevers door heel Nederland, meestal op afstand. Vijfentwintig jaar ervaring met websites en webshops betekent vooral: weten dat de meeste fouten bij een release of migratie niet uit de code komen, maar uit een handmatige stap die net even anders ging dan de vorige keer.
Elk traject begint met een inventarisatie: welk werk in wp-admin komt elke week terug, hoe gaat een release nu in zijn werk, welke geplande taken zijn er en waar gaat het weleens mis? Daarna volgt een aanpak die past bij de situatie. Vaak is dat een set eigen commando's in een kleine plug-in, geregistreerd met WP_CLI::add_command, met een --dry-run om eerst te zien wat er zou gebeuren en batches met een voortgangsbalk voor grote bewerkingen. Soms is het een deploy-script dat code uitrolt, migraties draait, de cache leegt en een healthcheck doet. En vaak hoort er een echte cron bij, zodat taken niet langer afhangen van toevallig bezoek aan de site.
Voor wie dit werkt, loopt uiteen: een WooCommerce-shop waar prijzen of producten in bulk moeten worden aangepast zonder time-outs in de browser, een multisite-netwerk waar een instelling op alle subsites tegelijk moet veranderen, een bureau dat releases wil automatiseren over een hele reeks klantsites, of een team dat nieuwe developers sneller een werkende lokale omgeving wil geven. In alle gevallen gaat het om dezelfde behoefte: minder handwerk op de plekken waar een fout het meest kost, en scripts die in Git staan, zodat iedereen kan nalezen wat ze doen.
Welke taak zich het best leent om als eerste te automatiseren, is zonder de site en de server gezien lastig te zeggen. Daarom begint het meestal met een kennismakingsgesprek: een half uur om te horen waar nu de tijd en de risico's zitten, gevolgd door een eerlijk beeld van wat WP-CLI daar kan betekenen. Geen verplichting, en geen pleidooi voor automatiseren als een taak zo zelden voorkomt dat een goede checklist volstaat.
Gebouwd voor
Klaar om het handwerk in wp-admin kwijt te raken?
Wat een WP-CLI developer oplevert
Zelden is een nieuwe hostingomgeving of een ander platform nodig; meestal levert het automatiseren van de paar taken met het meeste risico al het meeste op. Een paar voorbeelden van wat er dan concreet verandert.
-
Deploys die elke keer hetzelfde verlopen
Code uitrollen, migraties draaien, de cache legen en een healthcheck doen in één script, via GitHub Actions of GitLab CI. Geen release-avond meer met een checklist en een open FTP-venster.
-
Een veilige search-replace bij een domeinwissel
wp search-replace begrijpt geserialiseerde PHP-data, waar een simpele vervanging in de database widgets, menu's en velden breekt. Eerst een dry-run met rapport, daarna de echte run.
-
Bulkbewerkingen zonder time-outs
Producten herberekenen, content opschonen of taxonomieën herindelen via een eigen command met batches, een voortgangsbalk en de mogelijkheid om te hervatten. Geen browsertab die urenlang open moet blijven.
-
Geplande taken die ook 's nachts draaien
WP-Cron start alleen bij bezoek. Met DISABLE_WP_CRON en een systeemcron die wp cron event run aanroept, draaien imports en opschoontaken op het afgesproken moment, met een melding als een taak faalt.
-
Multisite-beheer in één run
Een plug-in activeren, een instelling wijzigen of een controle draaien over alle subsites tegelijk, met een rapport per site en de mogelijkheid om sites uit te sluiten.
-
Advies over wat als eerste automatiseren loont
Eén eigen command voor het meest tijdrovende handwerk, een complete deploy-pipeline, of eerst alleen een echte cron: een korte inventarisatie van het huidige beheer maakt meestal al duidelijk waar automatiseren via WP-CLI het meest oplevert.
Benieuwd welke taak als eerste een eigen WP-CLI command verdient?
WP-CLI voor grote WordPress-platformen
Voor Autovisie, onderdeel van de Telegraaf Mediagroep (tegenwoordig Mediahuis), is het online autoplatform op WordPress ontwikkeld: gebouwd voor hoge bezoekersaantallen, met een abonnementenmodel en een redactieomgeving. Geen WP-CLI-project als zodanig, wel precies het soort WordPress-platform waar beheer vanaf de command-line het meeste oplevert.
Bij een site met veel content en veel bezoekers is klikken in wp-admin voor grote bewerkingen geen goed idee: een bulkactie in de browser loopt tegen time-outs aan en belast dezelfde server die ook de lezers bedient. Een eigen WP-CLI command verwerkt zulke bewerkingen in batches, buiten de bezoekersstroom om, en kan na een onderbreking verder waar het was gebleven.
Hetzelfde geldt voor releases. Hoe groter het platform, hoe duurder een fout bij het uitrollen. Een deploy-script dat elke stap in dezelfde volgorde uitvoert en stopt zodra een stap faalt, is saaier dan een handmatige release, maar wel een stuk voorspelbaarder.
WP-CLI in de deploy-pipeline
Het meeste rendement van WP-CLI zit vaak niet in losse commando's, maar in de pipeline eromheen. Na een merge naar de hoofdbranch rolt GitHub Actions of GitLab CI de code uit, installeert Composer de afhankelijkheden, draait wp eval-file de databasemigraties en vervangt wp search-replace de omgevings-URL's. Daarna volgen een cache flush en een healthcheck; faalt die, dan faalt de hele deploy zichtbaar in plaats van ongemerkt.
Omdat WP-CLI met exitcodes werkt, weet de pipeline precies wanneer iets misgaat. Een eigen command dat bij een probleem WP_CLI::error aanroept, stopt de deploy en laat in het log zien waarom. Dat is het verschil tussen een release die meestal wel goed gaat en een release waarvan je weet dat hij goed is gegaan.
Dezelfde bouwstenen zijn bruikbaar voor een lokale ontwikkelomgeving: een script dat een geanonimiseerde database ophaalt, importeert, de URL's vervangt en de ontwikkelplug-ins activeert. Een nieuwe developer, of een reviewomgeving voor een pull request, heeft dan een werkende kopie zonder een lijst handmatige stappen.
Twijfel of automatiseren de moeite loont? Een half uur meedenken helpt vaak al.
WP-CLI-werk dat regelmatig terugkomt
Van één eigen command voor een terugkerende bulktaak tot een complete deploy-pipeline: onderstaand het werk dat het vaakst terugkomt, telkens toegesneden op de site, de hosting en het team dat ermee werkt. Alles wordt eerst op een testomgeving gedraaid en pas na controle op productie ingezet.
Custom WP-CLI commands
Eigen commando's in PHP met argumenten, flags, helptekst, --dry-run en een voortgangsbalk, gebundeld in een plug-in die met de site meegaat.
Deploy-scripts en CI/CD
Bash-scripts of een pipeline in GitHub Actions, GitLab CI of Bitbucket Pipelines: code uitrollen, migraties, cache flush en healthcheck.
Databasemigraties
Wijzigingen in data of instellingen als script via wp eval-file of een eigen command, herhaalbaar op staging, acceptatie en productie.
Search-replace en domeinwissels
URL-migraties en omgevingswissels die geserialiseerde data intact laten, met een dry-run en een rapport per tabel.
Echte cron en monitoring
WP-Cron vervangen door een systeemcron met wp cron event run, aangevuld met een heartbeat-melding als een taak niet draait.
Multisite-automatisering
Netwerkbrede updates, instellingen per subsite en nieuwe sites aanmaken via een script in plaats van via het netwerkdashboard.
- WP-CLI
- WordPress
- PHP
- WooCommerce
- WP All Import
- WordPress plug-in maken
- Bash
- Git
- Composer
- GitHub Actions
- GitLab CI
- Multisite
Veelgestelde vragen
Een aantal vragen dat regelmatig terugkomt bij het inhuren van een WP-CLI developer, van cron en multisite tot hosting en overdracht. Staat je eigen vraag er niet bij, stel 'm gewoon in het kennismakingsgesprek.
Wat is WP-CLI precies?
De officiële command-line interface voor WordPress, onderhouden als eigen project op wp-cli.org. Via een terminal op de server kan vrijwel alles wat in wp-admin kan, en een flink stuk meer: databases exporteren, geserialiseerde data vervangen, cron-events draaien of eigen commando's toevoegen. De commandoreferentie op developer.wordpress.org beschrijft alle standaardcommando's.
Wanneer loont een eigen WP-CLI command?
Als een handmatige taak regelmatig terugkomt, lang duurt of foutgevoelig is. Bulkbewerkingen op producten, content-imports, stappen in een release en herstelacties zijn typische kandidaten. Voor iets dat eens per jaar gebeurt, is een goede checklist vaak voldoende, en dat wordt dan ook zo benoemd. Bij het kennismakingsgesprek wordt daarom eerst geïnventariseerd welk werk in wp-admin of op de server het vaakst terugkomt, hoeveel tijd het kost en hoe vaak het misgaat door een gemiste stap. Een taak die wekelijks een uur kost en foutgevoelig is, verdient meestal eerder een eigen commando dan een taak die twee keer per jaar voorkomt en prima met een checklist te doen is. Ook releases die op meerdere sites moeten gebeuren, of bulkbewerkingen die in de browser tegen een time-out aanlopen, zijn goede kandidaten. Het uitgangspunt is steeds dat automatiseren zichzelf terugverdient in tijd of in voorkomen fouten, en dat wordt eerlijk benoemd als dat niet het geval lijkt te zijn.
Waarom is wp search-replace veiliger dan een vervanging in phpMyAdmin?
WordPress slaat veel instellingen op als geserialiseerde PHP, waarin de lengte van elke tekst is vastgelegd. Een simpele tekstvervanging laat die lengte niet meer kloppen, waardoor widgets, menu's of velden stilletjes verdwijnen. wp search-replace pakt die data uit, vervangt en slaat haar weer correct op, en toont met --dry-run eerst wat er zou veranderen.
Moet WP-Cron worden vervangen?
Op een site waar taken op een vast moment moeten draaien, meestal wel. WP-Cron wordt alleen gestart door een bezoek aan de site, dus op een rustig moment draait er niets. Met DISABLE_WP_CRON in wp-config.php en een systeemcron die wp cron event run --due-now aanroept, draaien taken op tijd, los van het bezoek.
Werkt WP-CLI ook met WooCommerce en multisite?
Ja. WooCommerce heeft eigen commando's onder wp wc, en eigen commands kunnen producten, orders en voorraad bewerken via de publieke functies van WooCommerce. Op multisite richt --url een commando op één subsite, en met wp site list is een run over het hele netwerk te scripten.
Wat als mijn hosting geen WP-CLI heeft?
Bij de meeste hosting die op WordPress is gericht, is WP-CLI via SSH beschikbaar. Bij eenvoudige shared hosting zonder SSH is dat niet altijd zo; dan is een overstap naar andere hosting soms de verstandigste stap, maar dat hangt af van wat er verder op die hosting draait.
Hoe houd je grote bewerkingen onder controle?
Met batches, een voortgangsbalk, het tussentijds legen van de objectcache en een optie om te hervatten na een onderbreking. Commando's draaien op de CLI-configuratie van PHP, die meestal ruimere limieten heeft dan een verzoek via de browser. Een dry-run laat vooraf zien wat er gaat gebeuren.
Wat kost een WP-CLI-traject?
Dat hangt af van de omvang: één command is iets anders dan een complete deploy-pipeline. Een eigen commando voor één terugkerende bulktaak, met een dry-run en een voortgangsbalk, is een kleiner traject dan een pipeline die code uitrolt, migraties draait, de cache leegt en een healthcheck doet over meerdere omgevingen. Ook multisite-automatisering of een script voor een geanonimiseerde lokale omgeving vraagt een eigen inschatting. Er wordt gewerkt op uurtarief of met een vaste prijs per fase. Na een eerste inventarisatie van het huidige handwerk, de releases en de geplande taken ontstaat een concreet beeld met een reële inschatting per onderdeel, waarna je zelf beslist of en hoe je verder gaat, zonder verplichting vooraf.
Krijg ik de scripts in eigen beheer?
Toegang tot commands en scripts is er vanaf het begin, via een Git-repository met een README en helptekst bij elk commando. De rechten op het maatwerk gaan over na volledige betaling, zoals in de algemene voorwaarden staat. Daarna kan een andere PHP developer ze lezen, aanpassen en uitbreiden, en dat is ook de bedoeling.
Handwerk in WordPress dat weg mag?
Een half uur bellen om de releases, de geplande taken en het terugkerende handwerk door te nemen, en welke taak als eerste een script verdient. Geen verplichting, en ook geen kant-en-klaar advies voordat er is meegekeken naar de site en de server.
