De meeste WordPress-beheerders kennen maar één manier om iets aan hun website te veranderen: inloggen op wp-admin en klikken. Dat werkt prima voor één website met tien plugins. Maar zodra je twintig sites onderhoudt, een verhuizing moet uitvoeren of een zoek-en-vervangactie over een database van een gigabyte wilt doen, wordt klikken de langzaamste route die er is. Daarvoor bestaat WP-CLI: dezelfde WordPress, maar bediend vanaf de commandline. Wie er eenmaal aan gewend is, gaat niet meer terug.

Wat is WP-CLI precies?

WP-CLI is de officiële commandline-tool voor WordPress. Je typt een commando in een terminal op de server en WordPress voert het uit — precies dezelfde functies die de beheeromgeving achter de schermen ook aanroept, alleen zonder de omweg van een browser. Je installeert plugins, draait updates, maakt gebruikers aan, exporteert de database of leest een instelling uit, allemaal met één regel. Bij vrijwel elke serieuze hostingpartij staat de tool al klaar; je hebt alleen SSH-toegang nodig.

Belangrijk om te begrijpen: WP-CLI is geen los systeem dat langs WordPress heen werkt. Het laadt je hele installatie, inclusief je thema en plugins. Wat je met een commando doet, is dus exact wat er via de beheeromgeving zou gebeuren — alleen sneller en herhaalbaar.

Waar het echt tijd scheelt

• Updates over meerdere sites: plugins bijwerken op tien websites is via wp-admin tien keer inloggen. Met een commando en een lijstje sites is het één handeling die je bovendien in een script kunt vastleggen.
• Verhuizingen: na het overzetten van een site moeten alle oude domeinnamen in de database vervangen worden. Dat is exact waar WP-CLI in uitblinkt, ook in geserialiseerde data waar een gewone SQL-vervanging je site sloopt.
• Als je er niet meer in komt: een fatale fout door een plugin sluit je buiten wp-admin. Vanaf de commandline deactiveer je die plugin alsnog, ook als de voorkant plat ligt.
• Opruimen: revisies, spamreacties, verlopen transients en oude ordergegevens verwijder je in seconden, zonder plugin die je er permanent bij moet installeren.
• Herhaalbaar werk: een reeks commando’s in een script is een procedure die volgende keer identiek verloopt. Klikwerk is dat nooit.

Zoeken en vervangen: de belangrijkste reden

Als één functie WP-CLI rechtvaardigt, is het deze. WordPress slaat veel instellingen op als geserialiseerde data: een tekstformaat waarin de lengte van elke waarde is meegeschreven. Vervang je daarin met een gewone databasequery een lange domeinnaam door een kortere, dan klopt die lengte niet meer en wordt de hele waarde onbruikbaar. Het gevolg is een site waarvan de widgets leeg zijn, de thema-instellingen verdwenen en de paginabouwer niets meer terugvindt.

WP-CLI pakt geserialiseerde data correct uit, vervangt de tekst en pakt het weer in. Bovendien kun je de actie eerst als proefdraai uitvoeren: je ziet dan precies hoeveel vervangingen er in welke tabellen zouden plaatsvinden, zonder dat er iets verandert. Die proefdraai is bij elke verhuizing de stap die je nooit overslaat.

Waar je moet opletten

De commandline vraagt geen bevestiging en kent geen prullenbak. Een verkeerd getypt commando dat berichten verwijdert, is meteen definitief. Maak dus altijd eerst een export van je database — met WP-CLI zelf is dat één regel — en werk waar mogelijk eerst op een testomgeving. Let er ook op dat je commando’s uitvoert als de juiste gebruiker: draai je als root, dan kunnen bestanden ontstaan die je webserver daarna niet meer mag beschrijven.

Een laatste praktisch punt: sommige plugins zijn niet gebouwd voor gebruik buiten de browser en kunnen een commando laten vastlopen of onverwacht veel geheugen opeisen. Loopt een commando vast, dan is het tijdelijk overslaan van die ene plugin bijna altijd de oplossing.

Wil je onderhoud, migraties of maatwerkscripts laten uitvoeren door iemand die dit dagelijks doet? Bekijk onze dienst codeerwerk op maat.

Conclusie

WP-CLI verandert WordPress-beheer van klikwerk in een handeling die je kunt herhalen, vastleggen en overdragen. Voor eenvoudige sites is het een luxe, maar zodra je meerdere websites beheert, verhuist of een database moet aanpassen, is het het verschil tussen een middag werk en twee minuten. Begin klein: een proefdraai van een zoek-en-vervangactie, of een database-export voor je aan het werk gaat. De rest volgt vanzelf.

Er komt een bestelling binnen in je webshop — en binnen een seconde staat er een melding in je team-chat, is de klant toegevoegd aan je mailinglijst en ligt er een conceptfactuur klaar in je boekhoudpakket. Geen nachtelijke synchronisatie, geen medewerker die het overtikt: de systemen hebben elkaar zelf op de hoogte gebracht. De techniek achter dit soort kettingreacties heet webhooks, en het is een van de simpelste én nuttigste bouwstenen om je website met de rest van je bedrijf te verbinden.

Wat is een webhook precies?

Een webhook is niets meer dan een automatisch berichtje van het ene systeem aan het andere op het moment dat er iets gebeurt. Systeem A (je webshop) krijgt de instructie: “als er een bestelling binnenkomt, stuur dan de gegevens naar dít webadres.” Dat webadres hoort bij systeem B (je boekhoudpakket, een koppelplatform, een eigen script), dat het bericht ontvangt en ermee aan de slag gaat. Het bericht zelf is een pakketje gestructureerde data — ordernummer, klant, bedrag — dat systeem B direct kan verwerken.

Webhook of API: wat is het verschil?

Beide laten systemen samenwerken, maar de richting verschilt. Een API werkt op afroep: systeem B moet stéllen (“zijn er nog nieuwe bestellingen?”) en doet dat bijvoorbeeld elke vijf minuten — ook als er niets is. Dat heet polling: veel loze vragen, en toch altijd een vertraging. Een webhook draait het om: systeem A méldt zich alleen als er echt iets gebeurd is. Realtime, zonder loze rondvragen. Vandaar de klassieke vergelijking: een API is zelf steeds de brievenbus checken, een webhook is een deurbel. In de praktijk vullen ze elkaar aan — de webhook meldt dát er iets is, en via de API haalt het ontvangende systeem eventueel aanvullende details op.

Wat je er in de praktijk mee doet

• WooCommerce heeft webhooks ingebouwd (WooCommerce → Instellingen → Geavanceerd → Webhooks): bij een nieuwe, gewijzigde of geannuleerde bestelling, nieuwe klant of productwijziging stuurt je shop automatisch een bericht naar elk adres dat jij instelt.
• Koppelplatformen als Make en Zapier zijn de makkelijkste ontvangers: zij geven je een webhook-adres, en jij klikt vervolgens zonder programmeren de vervolgacties aan elkaar — melding in Slack of Teams, regel in een spreadsheet, contact in je CRM, taak in je projecttool.
• Formulier-plugins kunnen aanvragen via een webhook direct doorzetten naar je CRM of opvolgsysteem — geen overgetikte leads meer.
• Andersom kan ook: je betaalprovider (zoals Mollie) meldt via een webhook aan jóuw site dat een betaling gelukt is — zo werkt vrijwel elke webshopbetaling al, zonder dat je het wist.

Waar je op moet letten

Webhooks zijn krachtig maar hebben spelregels. Beveiliging: het ontvangende adres is openbaar bereikbaar, dus controleer dat berichten echt van jouw systeem komen — WooCommerce ondertekent elk bericht met een geheime sleutel die de ontvanger kan verifiëren, en het hele verkeer hoort over HTTPS te lopen. Betrouwbaarheid: een webhook is een enkel seintje; is de ontvanger nét offline, dan mist hij het. Goede systemen proberen het daarom automatisch opnieuw, maar bouw voor cruciale processen (facturen!) een vangnet: een periodieke controle of alles is aangekomen. Dubbelingen: door die herhaalpogingen kan hetzelfde bericht twee keer aankomen; de verwerking moet daar tegen kunnen. En stuur nooit meer persoonsgegevens mee dan de ontvanger nodig heeft — ook een webhook valt onder de AVG.

Een webhook-koppeling tussen je webshop en je boekhouding, planning of magazijn laten bouwen — inclusief vangnet en beveiliging? Bekijk onze dienst codeerwerk op maat.

Conclusie

Webhooks zijn de deurbel tussen je systemen: je website meldt gebeurtenissen direct bij je chat, CRM of boekhouding, zonder polling en zonder overtypen. WooCommerce heeft ze standaard aan boord en koppelplatformen maken de ontvangst klikbaar — let alleen op beveiliging, herhaalpogingen en een vangnet voor het cruciale werk. Zo wordt je website van eilandje het kloppende hart van je administratie.

Er draait onder je WordPress-site een motor waar je waarschijnlijk nooit naar omkijkt: PHP, de programmeertaal waarin WordPress en vrijwel al je plugins geschreven zijn. Welke versie van die motor er draait, merk je normaal niet — tot het misgaat. Een verouderde PHP-versie is een van de meest voorkomende stille problemen bij websites die “gewoon al jaren draaien”: trager dan nodig, zonder beveiligingsupdates, en op een dag weigert een plugin-update dienst met een witte pagina. Het goede nieuws: controleren kost één minuut en de overstap is, mits goed aangepakt, een klein en veilig klusje.

Waarom die versie ertoe doet

Drie redenen. Veiligheid: elke PHP-versie krijgt maar een beperkte tijd (actieve) ondersteuning en daarna nog een periode alleen beveiligingsupdates — daarna is hij “end of life” en worden nieuw ontdekte lekken simpelweg nooit meer gedicht. Een site op een end-of-life-versie draait op een motor waarvan bekende gebreken openbaar gedocumenteerd staan. Snelheid: nieuwere PHP-versies zijn aantoonbaar sneller; de sprong van de oude 7.x-reeks naar een recente 8.x-versie scheelt op veel sites tientallen procenten verwerkingstijd — gratis winst, zonder één aanpassing aan je site. Compatibiliteit: plugin- en themabouwers ontwikkelen voor recente versies. Wie te lang blijft hangen, komt in een klem: nieuwe plugin-versies eisen nieuwer PHP, terwijl je oude plugins juist op de oude versie leunen. Hoe langer je wacht, hoe kleiner het gaatje waar je doorheen moet.

Zo controleer je waar je nu op draait

In WordPress zie je het zonder techniek: ga naar Gereedschap → Sitediagnose, tabblad Info, kopje Server — daar staat de PHP-versie. Sitediagnose waarschuwt ook zelf (“PHP-versie verouderd”) als je te laag zit. Vergelijk wat je ziet met de actuele stand op php.net: daar staat welke versies nog ondersteund worden. Vuistregel voor dit moment: alles onder PHP 8.1 verdient een plan, en een 7.x-versie is al jaren end-of-life en dus urgent. De versie wijzigen doe je overigens niet in WordPress maar bij je hostingpartij: in vrijwel elk hostingpaneel (DirectAdmin, Plesk, cPanel) is het een keuzemenu per domein.

Veilig overstappen in vier stappen

• Inventariseer eerst. Werk WordPress, thema en plugins volledig bij — nieuwe versies zijn op nieuwer PHP getest. Verwijder wat je niet gebruikt; verlaten plugins zijn de meest waarschijnlijke breekpunten.
• Test als het kan op een kopie. Een staging-omgeving met de nieuwe PHP-versie laat zien of alles werkt, zonder dat bezoekers iets merken. Geen staging? Kies dan in elk geval een rustig moment.
• Zet de versie om en loop de site na: homepage, formulieren, inloggen, en bij een webshop een testbestelling. Fouten tonen zich vrijwel direct — meestal als witte pagina of een foutmelding van één specifieke plugin.
• Gaat er iets stuk? Zet de PHP-versie in het hostingpaneel terug (dat is één klik, geen back-up-operatie), kijk in de foutenlog welke plugin of welk thema de boosdoener is, en los dát op — updaten, vervangen of laten repareren. Dan opnieuw omzetten.

Als oude code de blokkade is

Soms wijst de foutenlog naar code die niet zomaar te updaten valt: een maatwerk-thema van jaren terug, een plugin waarvan de maker gestopt is, een koppeling die ooit “even” gebouwd is. Dat is geen reden om op een onveilige PHP-versie te blijven — het is een teken dat er technisch onderhoud is blijven liggen. Meestal gaat het om overzichtelijk herstelwerk: verouderde functies vervangen, een plugin herbouwen of een modern alternatief koppelen. Dat kost eenmalig aandacht, maar het alternatief is een website die vastgroeit aan een motor die niemand meer onderhoudt.

Loopt jouw site vast op oude code bij een PHP-upgrade? Bekijk onze dienst codeerwerk op maat — we maken verouderde thema’s, plugins en koppelingen weer bij de tijd.

Conclusie

De PHP-versie is de motor onder je website: bepalend voor snelheid, veiligheid en of updates blijven werken. Controleer via Sitediagnose waar je op draait, plan de overstap naar een ondersteunde 8.x-versie, en doe het gecontroleerd — bijgewerkt, getest, met de log als gids. Een middagje aandacht, en je site is sneller én jaren vooruit.

Vraag een timmerman naar zijn gereedschap en hij noemt zijn zaag. Vraag een goede webdeveloper hetzelfde en het antwoord is: Git. Versiebeheer is het fundament onder professioneel ontwikkelwerk — en toch draait een verrassend groot deel van de zakelijke websites zonder. Wijzigingen gaan dan rechtstreeks de live server op, de vorige versie bestaat alleen nog in back-ups en niemand weet meer wie wat wanneer heeft aangepast. Als website-eigenaar hoef je Git niet te kunnen bedienen, maar je wilt wél begrijpen waarom het ertoe doet — al is het maar om er bij je webbouwer naar te vragen.

Wat is versiebeheer?

Versiebeheer is een systeem dat elke wijziging aan de code van je website vastlegt: wat er veranderde, wie het deed, wanneer en waarom. Git is daarvoor de wereldstandaard. De complete geschiedenis staat in een zogeheten repository, vaak gehost op een platform als GitHub of GitLab. Vergelijk het met de versiegeschiedenis van een Google-document, maar dan strenger: elke wijziging wordt als bewust “commit”-moment vastgelegd met een omschrijving erbij, en je kunt naar elk eerder punt in de geschiedenis terug — van vijf minuten tot vijf jaar geleden.

Wat levert dat concreet op voor jouw website?

• Elke wijziging is terug te draaien. Gaat een aanpassing mis, dan staat de vorige werkende versie één commando verderop — geen paniek-restore van een complete back-up nodig.
• Meerdere mensen, geen chaos. Developers werken in eigen “branches” aan losse features en voegen die gecontroleerd samen. Niemand overschrijft elkaars werk.
• Een logboek van je website. “Sinds wanneer doet het formulier raar?” is opzoekbaar: de historie toont exact welke wijziging wanneer live ging.
• Gecontroleerd live zetten. Vanuit Git kan een wijziging automatisch naar staging en productie worden uitgerold (deployment) — geen bestanden meer via FTP over de live site heen slepen.
• Onafhankelijkheid. De code van je site staat compleet en gedocumenteerd op een neutrale plek. Wissel je van bureau, dan draag je een repository over in plaats van een zip-bestand en losse eindjes.

Hoe zit dat bij WordPress?

Bij een WordPress-site hoort niet álles in Git thuis. De vuistregel: code wél, data en bijlagen niet. In de repository horen het (child-)thema, eigen plugins en configuratie — alles wat ontwikkeld wordt. De database (berichten, bestellingen, instellingen) en de uploads-map (afbeeldingen) horen in je back-upstrategie, niet in versiebeheer; die veranderen immers door gebruik, niet door ontwikkeling. Deze scheiding is precies waarom een professionele partij zowel Git áls back-ups regelt: het zijn twee verschillende vangnetten voor twee verschillende soorten wijzigingen.

De vraag die je je webbouwer mag stellen

“Staat de code van mijn website in versiebeheer, en kan ik bij de repository?” is een volstrekt redelijke vraag — vergelijkbaar met vragen of een aannemer een bouwtekening bijhoudt. Het antwoord zegt veel over de werkwijze: wie met Git, staging en gecontroleerde deployments werkt, levert aantoonbaar reproduceerbaar werk. Vraag ook of jij (of een toekomstige partij) toegang tot de repository kunt krijgen; het is tenslotte de code van jóuw website. Een professionele partij regelt dat zonder aarzelen.

Wij ontwikkelen alle maatwerk in Git, met staging en gecontroleerde livegang — ook als we verder bouwen op bestaande code. Bekijk onze dienst codeerwerk op maat.

Conclusie

Versiebeheer met Git maakt van websitecode een gedocumenteerd, terugdraaibaar en overdraagbaar geheel in plaats van een verzameling bestanden op een server. Voor jou als eigenaar betekent het minder risico bij wijzigingen, een opzoekbare historie en onafhankelijkheid van één partij. Je hoeft er zelf niets voor te leren — alleen de juiste vraag te stellen aan wie aan je site werkt.