12 WordPress-beheerklussen die makkelijker worden met WP-CLI commando’s

Met deze WP-CLI’s commando’s wordt het beheren van je WordPress website een fluitje van een cent.

Wie WordPress beheert, brengt waarschijnlijk behoorlijk wat tijd door in wp-admin. Plugin bijwerken, cache legen, gebruiker aanpassen, permalinks opnieuw opslaan: voor vrijwel alles is wel ergens een knop te vinden.

Maar die knop is niet altijd de makkelijkste manier.

Voor veel beheerwerkzaamheden gebruik ik liever WP-CLI. WP-CLI is, zoals de naam al aangeeft, een Command Line Interface voor WordPress. Je voert opdrachten dus niet uit door met de muis door wp-admin te klikken, maar door een commando in te typen.

Dat klinkt misschien ingewikkelder dan het is.

Sterker nog: voor sommige werkzaamheden vind ik WP-CLI juist overzichtelijker. En wanneer een website niet meer goed functioneert en je helemaal niet meer in wp-admin kunt komen, kan WP-CLI zelfs een uitkomst zijn.

Enkele jaren terug heb ik al eerder ‘iets’ over WP-CLI commando’s geschreven en enkele voorbeelden gegeven, wat je hiermee kan doen, maar in deze post wil ik verder doorborduren op ‘wat je met WP-CLI commando’s kunt doen’. Om te weten hoe je deze tool moet installeren, mocht je hem nog niet hebben, verwijs ik je graag naar het eerdere artikel.

In dit artikel begin ik eenvoudig. We gaan eerst alleen maar kijken. Daarna gaan we dingen wijzigen en onderhouden. Vervolgens gebruiken we WP-CLI om problemen te onderzoeken en uiteindelijk komen we terecht bij twee werkzaamheden waarvoor ik de commandline bijzonder handig vind: het migreren en stagen van websites.

De hamvraag: Heb ik WP-CLI en kan ik het installeren?

Een eerste belangrijke vraag is natuurlijk of je WP-CLI hebt. En als je het niet hebt, of je het kan installeren. Als je het hebt, hoeft het niet altijd zichtbaar te zijn in het beheerspaneel van je hoster. Dat komt, omdat je WP-CLI geacht wordt vanaf de systeemprompt te gebruiken.

Om bij WP-CLI te kunnen komen, moet je in je beheerspaneel opzoek naar een optie als ‘SSH’ of ‘Terminal’. Heb je dat gevonden, dan heb je onder deze optie een tweetal mogelijkheden:

1. Wanneer je klikt op SSH dan krijg je een ’terminal emulatie’ binnen je browser. Je kunt dus binnen de browser command line opdrachten intikken
2. Je krijgt informatie hoe je vanuit je eigen computer kan verbinden met de server. Dat wordt een wat langer en ingewikkeld verhaal, maar gelukkig heb ik in mijn vroegere artikel over WP-CLI al beschreven wat je dan moet doen.

Belangrijke side-note: Sinds het beruchte PHP2Shell incident hebben veel hosting bedrijven de ‘shell_exec’ functie van WordPress geblokkeerd, of het aantal mogelijke commando’s wat via de shell_exec functie kan worden uitgevoerd beperkt. Dit heeft betrekking op de meeste Shared Hosting omgevingen, wat minder vaak op VPS omgevingen. Het is hierdoor mogelijk dat bepaalde commando’s niet zullen werken. Eén ervan is het backup commando voor MySQL/MariaDB, de databases waaronder WordPress draait. Wanneer de meeste WP-CLI commando’s wel draaien, maar enkele -vooral commando’s die met andere diensten te maken hebben- niet, dan is dat de oorzaak. De commando’s waarbij dit mogelijk een rol speelt heb ik hier met een asterisk in de titel aangegeven.

Eerst: hoe kom je bij WP-CLI?

WP-CLI gebruik je normaal gesproken via SSH. Je logt in op de server en gaat naar de directory waarin WordPress staat.

Daar kun je bijvoorbeeld typen:

wp core version

Als alles goed is, krijg je simpelweg de geïnstalleerde WordPress-versie terug. Wanneer WP-CLI niet bij je host is geïnstalleerd, dan zal je een melding krijgen, dat je een onbekend commando hebt ingegeven.

Dat wp-commando is overigens niet op iedere server exact hetzelfde ingericht. Op een server met meerdere PHP-versies kan het bijvoorbeeld noodzakelijk zijn WP-CLI expliciet met een bepaalde PHP-versie uit te voeren:

php8.4 /usr/bin/wp core version

Dat is belangrijk om te onthouden. De PHP-versie waarmee je website via de webserver draait, hoeft niet automatisch dezelfde PHP-versie te zijn die je op de commandline krijgt. Iets om goed op te letten, want het is in incidentele gevallen mogelijk het gebruik van verschillende PHP versies voor de command line en voor de webserver voor onprettige verrassingen kan leiden. Bijvoorbeeld omdat bepaalde PHP functies tussen twee verschillende versies verschillend kunnen werken.

Met:

wp cli info

kun je informatie opvragen over de omgeving waarin WP-CLI zelf draait. WP-CLI heeft bovendien globale opties voor onder andere het WordPress-pad, de URL, SSH, het overslaan van plugins en themes en debugging.

En dan kunnen we aan het werk.

1. Gewoon eens kijken wat er geïnstalleerd is

Een mooie manier om met WP-CLI te beginnen is door helemaal niets te veranderen.

Bijvoorbeeld:

wp core version

voor de WordPress-versie en:

wp plugin list

voor de geïnstalleerde plugins.

Voor de themes:

wp theme list

Het aardige van wp plugin list is dat je in één overzicht onder andere kunt zien welke plugins actief zijn en welke versie geïnstalleerd is.

Dat klinkt misschien niet spectaculair. Maar wanneer ik via SSH op een website kom om een probleem te onderzoeken, is dit vaak veel sneller dan eerst inloggen op wp-admin en door verschillende schermen klikken.

WP-CLI bevat hiervoor niet alleen commando’s voor plugins en themes, maar voor vrijwel alle belangrijke WordPress-onderdelen.

Je eerste kennismaking met WP-CLI hoeft dus helemaal niet spannend te zijn. Begin gewoon eens met kijken.

2. WordPress, plugins en themes bijwerken

De volgende stap is daadwerkelijk iets veranderen.

Een plugin bijwerken kan bijvoorbeeld met:

wp plugin update woocommerce

Alle plugins bijwerken kan ook:

wp plugin update --all

En hetzelfde principe bestaat voor themes en WordPress zelf.

Voordat je enthousiast --all gaat gebruiken, wil ik daar wel een kanttekening bij plaatsen.

Dat iets met één commando kan, betekent nog niet dat het altijd verstandig is. Gaat er iets mis tijdens de update, dan is het mogelijk dat je een back-up terug moet zetten. Dan is het best handig, wanneer je er ook daadwerkelijk één hebt gemaakt. Aan de andere kant, een update commando uitvoeren direct na de back-up, dat is toch wel de beste tijd om het te doen.

Bij een website die ik beheer wil ik meestal eerst weten welke updates er klaarstaan:

wp plugin list --update=available

Daarna kan ik beslissen welke updates ik uitvoer.

Voor pluginupdates bestaat bovendien een --dry-run, waarmee je eerst kunt bekijken wat WP-CLI zou gaan bijwerken zonder de update daadwerkelijk uit te voeren.

WP-CLI maakt onderhoud sneller. Het neemt niet de verantwoordelijkheid van de beheerder over.

En natuurlijk geldt ook hier: zorg dat je een bruikbare back-up hebt voordat je grotere updates uitvoert.

3. Een verloren WordPress-wachtwoord herstellen

Je kent waarschijnlijk de standaardprocedure. Je klikt op ‘Wachtwoord vergeten?’, WordPress stuurt een e-mail en via die e-mail stel je een nieuw wachtwoord in. Totdat die e-mail niet aankomt. Zoals bijvoorbeeld in een testomgeving, of een omgeving waar de mailserver niet goed is geconfigureerd.

Eén van de opties is om phpMyAdmin te openen en rechtstreeks iets in de tabel wp_users te veranderen. Tenminste, dat werkte goed tot WP versie 6.7, in 6.8 is er iets veranderd en lijkt het niet meer te werken.

De nette manier is via WP-CLI, eerst kijken we of de user ook bestaat:

wp user list

Vervolgens kunnen we bijvoorbeeld het wachtwoord van gebruiker wilko veranderen:

wp user update wilko --user_pass='NieuwSterkWachtwoord'

WP-CLI geeft het wachtwoord door aan WordPress, waarna WordPress zelf voor de correcte verwerking zorgt. wp user update accepteert hiervoor expliciet de optie --user_pass.

Er bestaat inmiddels trouwens ook een specifiek wp user reset-password commando. WP-CLI biedt daarnaast commando’s voor onder andere gebruikers aanmaken, rollen veranderen, sessies verwijderen en application passwords beheren.

Dat vind ik een stuk prettiger dan rechtstreeks rommelen met gebruikersrecords in de database.

4. Cache en transients opruimen *)

‘Heb je de cache al geleegd?’

Het is waarschijnlijk één van de meest gebruikte zinnen bij het oplossen van WordPress-problemen.

Met WP-CLI kun je bijvoorbeeld de WordPress Object Cache legen:

wp cache flush

En transients verwijderen:

wp transient delete --all

Maar hier moeten we meteen iets rechtzetten.

De cache bestaat niet.

Een WordPress-website kan verschillende cachinglagen hebben. Er kan een object cache zijn, een page cache van een plugin, server-side caching via bijvoorbeeld NGINX of LiteSpeed en vervolgens misschien ook nog caching via een CDN. En wanneer je een plugin als Elementor gebruikt, heeft die ook nog eens een eigen cache voor de Elementor CSS en JavaScript code.

wp cache flush betekent dus niet automatisch: maak iedere mogelijke cache van mijn website leeg.

Hetzelfde geldt voor transients. Dat zijn tijdelijke waarden die WordPress en plugins kunnen opslaan. Standaard gebeurt dat in de WordPress-database, maar bij een persistente object cache zoals Redis of Memcached kan dat anders verlopen.

WP-CLI is krachtig, maar je moet nog steeds weten wát je aan het legen bent.

5. Permalinks en rewrite rules herstellen

Soms werkt een website op het eerste gezicht prima, maar leveren bepaalde pagina’s ineens een 404 op.

Een bekende WordPress-truc is dan:

Instellingen → Permalinks → Wijzigingen opslaan.

Ook als je helemaal niets gewijzigd hebt.

Wat je daarmee onder andere veroorzaakt, is dat WordPress zijn rewrite rules opnieuw opbouwt.

Dat kan ook:

wp rewrite flush

Je kunt de huidige regels bovendien bekijken:

wp rewrite list

WP-CLI kan via wp rewrite rewrite rules tonen of flushen en de permalinkstructuur beheren.

Opnieuw geen revolutionaire toepassing, maar wel eentje waardoor je begint te merken dat veel handelingen waarvoor je normaal wp-admin opent ook rechtstreeks kunnen worden uitgevoerd.

6. Afbeeldingen opnieuw genereren *)

Stel dat je een nieuw theme installeert of nieuwe afbeeldingsformaten toevoegt.

Nieuwe afbeeldingen worden vervolgens keurig in die formaten aangemaakt, maar je bestaande mediabibliotheek natuurlijk niet automatisch.

Dan kun je thumbnails opnieuw laten genereren:

wp media regenerate

Heb je een grote mediabibliotheek, dan kan dat behoorlijk wat werk zijn. Juist bij zulke langlopende processen vind ik de commandline prettiger dan een proces dat via de browser moet blijven draaien.

Je kunt ook alleen ontbrekende formaten genereren:

wp media regenerate --only-missing

Of één bepaalde image size opnieuw laten maken. WP-CLI ondersteunt daarnaast onder meer het importeren van media en het opvragen van geregistreerde afbeeldingsformaten.

Dit is een mooi voorbeeld van een klus die in wp-admin niet onmogelijk is, maar waarvoor WP-CLI simpelweg beter gereedschap kan zijn.

7. Uitzoeken waarom geplande taken niet worden uitgevoerd

WordPress gebruikt WP-Cron voor allerlei geplande werkzaamheden.

Denk aan geplande berichten, periodieke opruimtaken en processen die plugins op bepaalde momenten willen uitvoeren.

Je kunt de geplande cron-events bekijken:

wp cron event list

En een bepaald event uitvoeren:

wp cron event run naam_van_de_hook

WP-CLI kan cron-events testen, uitvoeren en verwijderen en cron schedules beheren.

Dat is vooral handig wanneer iets zou moeten gebeuren, maar blijkbaar niet gebeurt.

Daarbij is het goed om te weten dat WP-Cron geen gewone server-cron is. Standaard wordt WP-Cron aangeroepen naar aanleiding van bezoeken aan WordPress. Op websites met weinig verkeer kan dat betekenen dat taken later worden uitgevoerd dan je verwacht.

Op websites waar timing belangrijk is, configureer ik daarom liever een echte server-cron die WordPress periodiek aanroept.

Maar wanneer er vervolgens iets misgaat, geeft WP-CLI je uitstekend gereedschap om te onderzoeken wat WordPress denkt dat er gepland staat.

8. Een WordPress-site onderzoeken die niet meer werkt

Tot nu toe konden we alles ook min of meer vanuit wp-admin doen.

Maar wat nu als wp-admin zelf niet meer werkt?

Bijvoorbeeld omdat een plugin na een update een fatale fout veroorzaakt.

Dan wordt WP-CLI ineens veel interessanter.

Je kunt nog steeds proberen:

wp plugin list

Maar wanneer het probleem tijdens het laden van een plugin ontstaat, kan zelfs een WP-CLI-opdracht problemen geven.

Dan kunnen we WordPress starten zonder de gewone plugins te laden:

wp --skip-plugins plugin list

Of zonder een specifieke plugin:

wp --skip-plugins=plugin-slug plugin list

Ook themes kunnen worden overgeslagen:

wp --skip-themes plugin list

--skip-plugins en --skip-themes zijn globale WP-CLI-parameters. Bij --skip-plugins kunnen ook specifieke plugins worden opgegeven; mu-plugins worden daarbij overigens niet overgeslagen.

Een verdachte plugin kun je vervolgens bijvoorbeeld deactiveren:

wp plugin deactivate plugin-slug

En precies hier wordt WP-CLI voor mij meer dan een snellere manier om dingen te doen.

Het wordt gereedschap waarmee ik een WordPress-installatie kan onderzoeken die via de normale gebruikersinterface niet meer bereikbaar is.

Plugins overslaan is niet altijd de oplossing

Er zit wel een belangrijke nuance aan --skip-plugins.

Soms wil je plugins juist niet overslaan.

Plugins kunnen eigen datatypes, objecten en hooks registreren die noodzakelijk zijn om gegevens correct te verwerken. Zeker bij complexere databasebewerkingen kan het blind uitschakelen van alle plugins daarom ook ongewenste gevolgen hebben.

De vraag is dus niet: Kan ik plugins overslaan?
De betere vraag is: Heb ik voor deze opdracht de code van deze plugin nodig?

Dat verschil wordt verderop, bij het migreren van websites, nog belangrijk.

9. De database onderzoeken *)

Nu komen we bij werkzaamheden waarvoor enige databasekennis verstandig is.

Een eenvoudige controle:

wp db check

Of optimaliseren:

wp db optimize

Je kunt ook kijken hoe groot de database is:

wp db size

Maar één van mijn favoriete toepassingen is zoeken.

Stel dat een website vroeger draaide op:

https://oudedomein.nl

en inmiddels op:

https://nieuwedomein.nl

Dan kun je zoeken of het oude domein nog ergens voorkomt:

wp db search 'oudedomein.nl'

Dat is buitengewoon handig na een migratie.

Je kunt met WP-CLI ook rechtstreeks SQL uitvoeren. Daarmee kom je echter op een punt waarop de veiligheidsrails steeds verder verdwijnen.

Dat een commando beschikbaar is, betekent niet dat het verstandig is om het zonder goede databasekennis te gebruiken.

Maak een back-up.

En controleer of die back-up ook werkelijk teruggezet kan worden.

10. Waarden veilig zoeken en vervangen

En dan komen we bij één van de WP-CLI-commando’s die ik bijzonder vaak gebruik:

wp search-replace

Stel dat:

https://oudedomein.nl

moet veranderen in:

https://nieuwedomein.nl

Dan kunnen we eerst kijken wat er zou gebeuren:

wp search-replace \
'https://oudedomein.nl' \
'https://nieuwedomein.nl' \
--dry-run

Die --dry-run vind ik belangrijk.

Er wordt dan nog niets gewijzigd. WP-CLI laat eerst zien wat het van plan is.

Pas wanneer dat resultaat klopt, voer je dezelfde opdracht zonder --dry-run uit.

Waarom niet gewoon SQL?

Omdat WordPress-data niet altijd uit simpele tekstvelden bestaat.

WordPress en plugins kunnen gegevens opslaan als geserialiseerde PHP-data. Wanneer je daar met een simpele SQL REPLACE() de lengte van een tekst verandert, kan de opgeslagen datastructuur ongeldig worden.

wp search-replace houdt rekening met PHP serialized data en verandert bovendien geen primary-keywaarden. Je kunt de operatie beperken tot bepaalde tabellen of kolommen en er bestaat dus een --dry-run.

Dat maakt het veel geschikter voor WordPress dan een willekeurige zoek-en-vervangactie rechtstreeks op de database.

Maar ook hier geldt weer: plugins kunnen hun eigen complexe gegevensstructuren gebruiken. Pagebuilders zoals Elementor zijn daar een goed voorbeeld van.

Soms wil je daarom juist dat WordPress en plugins normaal geladen worden tijdens een operatie. Waarschuwingen dat bepaalde classes niet geïnitialiseerd konden worden, zou ik niet zonder meer negeren. Een opdracht kan technisch eindigen zonder dat je daarmee automatisch weet dat werkelijk alle relevante gegevens correct verwerkt zijn.

Controle achteraf blijft noodzakelijk.

Bijvoorbeeld:

wp db search 'oudedomein.nl'

Geen resultaat is dan een stuk geruststellender dan alleen de melding dat je search-replace klaar is.

11. Een WordPress-website migreren *)

Nu kunnen we een aantal voorgaande onderdelen combineren.

Een website migreren bestaat grofweg uit twee zaken:

• de bestanden moeten naar een andere locatie;
• de database moet mee.

WP-CLI doet niet noodzakelijk het hele transport van de bestanden. Daarvoor kun je bijvoorbeeld rsync, scp of andere servertools gebruiken.

Maar voor de WordPress-kant is WP-CLI bijzonder handig.

Op de oude omgeving kun je bijvoorbeeld de database exporteren:

wp db export database.sql

Daarna kopieer je bestanden en database-export naar de nieuwe server.

Op de nieuwe server importeer je de database:

wp db import database.sql

Vervolgens controleer ik eerst wat WordPress zelf denkt dat zijn URL is:

wp option get home
wp option get siteurl

Verandert bij de migratie ook het domein, dan kunnen we onze inmiddels bekende search-replace gebruiken:

wp search-replace \
'https://oudedomein.nl' \
'https://nieuwedomein.nl' \
--dry-run

Resultaat goed?

Dan pas zonder --dry-run.

Daarna kun je onder andere:

wp rewrite flush
wp cache flush

uitvoeren en met:

wp db search 'oudedomein.nl'

controleren of er nog oude verwijzingen bestaan.

En natuurlijk controleer je de website zelf.

Een migratie is daarmee geen magisch WP-CLI-commando.

Het is een workflow waarin verschillende eenvoudige commando’s die we eerder hebben gezien samen één complexere taak uitvoeren.

En precies daarom wilde ik migratie niet aan het begin van dit artikel behandelen.

Wanneer je begrijpt wat de afzonderlijke gereedschappen doen, wordt de complete migratie ineens een stuk minder mysterieus.

12. Een stagingomgeving maken *)

We doen er nog één stap bovenop.

We willen geen website verhuizen, maar een kopie maken waarop we veilig kunnen werken.

Bijvoorbeeld:

https://www.mijnwebsite.nl

naar:

https://staging.mijnwebsite.nl

Technisch lijkt het eerste gedeelte sterk op een migratie.

We kopiëren bestanden, exporteren en importeren de database en vervangen de URL.

Bijvoorbeeld:

wp search-replace \
'https://www.mijnwebsite.nl' \
'https://staging.mijnwebsite.nl' \
--dry-run

en daarna de echte vervanging.

Vervolgens kunnen we staging-specifieke instellingen aanpassen.

Bijvoorbeeld zoekmachines verzoeken de stagingomgeving niet te indexeren:

wp option update blog_public 0

Maar daarmee zijn we er nog niet.

Een stagingwebsite mag bijvoorbeeld niet ineens echte e-mails naar klanten gaan sturen. Een WooCommerce-stagingomgeving moet niet per ongeluk betalingen gaan verwerken alsof het productie is. Webhooks, externe API’s en koppelingen verdienen eveneens aandacht.

Een stagingwebsite is niet alleen een kopie van productie met een andere URL.

En hoe gaat staging weer terug naar productie?

Hier wordt het echt interessant.

Stel dat je maandag een stagingkopie maakt.

Dinsdag pas je op staging het design aan.

Maar ondertussen gebeurt op productie gewoon van alles:

• een klant plaatst een bestelling;
• iemand maakt een account aan;
• een formulier wordt ingevuld;
• een redacteur publiceert een bericht.

Wanneer je vrijdag simpelweg de stagingdatabase over productie heen zet, verdwijnen die wijzigingen.

Daarom is ‘push staging naar productie’ veel minder eenvoudig dan sommige hostinginterfaces doen vermoeden.

Code kun je vaak prima gecontroleerd terugzetten.

Voor databasewijzigingen moet je veel beter weten welke tabellen en welke gegevens je werkelijk wilt overzetten.

WP-CLI kan daarbij uitstekend helpen. Je kunt gegevens onderzoeken, exporteren, wijzigen en gericht verwerken.

Maar WP-CLI kan niet voor jou beslissen welke gegevens belangrijk zijn.

Dat blijft de taak van degene achter het toetsenbord.

En als je twintig websites beheert?

Tot nu toe ben ik er steeds vanuit gegaan dat je via SSH bent ingelogd op één server en daar je commando’s uitvoert.

Maar WP-CLI kan ook op afstand werken.

Een globale optie is bijvoorbeeld:

--ssh=

waarmee WP-CLI een opdracht tegen een WordPress-installatie op een andere server kan uitvoeren. WP-CLI ondersteunt hiervoor onder andere SSH en verschillende containeromgevingen.

Nog interessanter worden aliases.

Je kunt bijvoorbeeld omgevingen namen geven als:

@production
@staging

waarna opdrachten mogelijk worden in de vorm van:

wp @production plugin list

of:

wp @staging plugin list

WP-CLI heeft hiervoor ingebouwd beheer van aliases.

En dan verandert WP-CLI opnieuw van karakter.

We begonnen dit artikel met:

wp core version

Een simpele manier om te kijken welke versie van WordPress geïnstalleerd is.

Aan het eind zitten we bij het beheren van verschillende WordPress-installaties op verschillende omgevingen.

En uiteindelijk is dat wat WP-CLI voor mij interessant maakt.

Je hoeft de commando’s niet uit je hoofd te kennen

Misschien kijk je inmiddels naar alle voorbeelden hierboven en denk je:

Moet ik dat allemaal onthouden?

Nee.

Ik doe dit werk al lang genoeg om te weten dat het veel belangrijker is dat je weet wat mogelijk is dan dat je iedere parameter uit je hoofd kent.

WP-CLI heeft zelf uitgebreide help:

wp help

En voor een specifiek commando bijvoorbeeld:

wp help search-replace

Daarnaast is er uitgebreide officiële documentatie. De huidige WP-CLI-documentatie omvat commando’s voor onder meer core, plugins, themes, gebruikers, media, cron, databasebeheer, rewrites, transients, zoeken en vervangen en nog veel meer.

Begin dus klein.

Log eens via SSH in op een WordPress-website en probeer:

wp core version
wp plugin list
wp theme list

Daar kun je weinig mee kapotmaken.

Wanneer dat vertrouwd begint te voelen, probeer je eens een pluginupdate. Daarna misschien een cache flush, een databasecontrole of een search-replace --dry-run.

Voor je het weet gebruik je de wp-cli commandline voor werkzaamheden waarvoor je vroeger eerst moest inloggen op wp-admin, phpMyAdmin moest openen en misschien ook nog een extra plugin installeerde.

En dat is voor mij de kracht van WP-CLI.

Niet dat alles ineens met één magisch commando kan.

Maar dat je voor steeds meer WordPress-beheerwerkzaamheden hetzelfde gereedschap kunt gebruiken — van even kijken welke versie geïnstalleerd is tot het compleet migreren van een website.

Meer WP-CLI commando’s – enkele voorbeelden

Zoals ik al eerder heb aangegeven, zowel in mijn vorige als dit artikel over WP-CLI is het ook mogelijk dat bepaalde plugins de functionaliteiten van het WP-CLI commando uitbreiden. Hieronder een korte lijst met een aantal voorbeelden van populaire plugins en een voorbeeld van hun WP-CLI ondersteuning. De namen van de plugins zelf linken naar de complete WP-CLI handleiding van die plugin.

Wanneer je weer een nieuwe plugin installeert, kan het goed zijn om eens te onderzoeken, welke ondersteuning die plugin voor WP-CLI biedt, en hoe jij jouw werk hierdoor efficienter kan maken.

Veilig oefenen met de WP-CLI

Oom Ben Parker wist het al: met grote krachten komen grote verantwoordelijkheden. En met WP-CLI haal je plotseling krachtige mogelijkheden in huis. En omdat je nergens een waarschuwing of een verzoek om bevestiging krijgt, kan je heel makkelijk iets kapot maken. Wanneer je dit op een live website een fout maakt met een commando, dan is afhankelijk van het type wp-cli commando soms het leed niet te overzien.

Maar ook -of eigenlijk juist– de gevaarlijke commando’s moet je oefenen. Gelukkig hoeft dat niet op je livesite. Sterker nog, het hoeft niet eens online.

Ik heb alweer een aantal jaren geleden geschreven over LocalWP, een complete WordPress omgeving die op je lokale computer kan draaien. Het aardige van LocalWP is dat hiermee ook WP-CLI direct geïnstalleerd wordt.

De rode pijl wijst naar de keuze voor de ‘site shell’.

Wanneer je een website hebt geïnstalleerd, hoef je alleen op ‘Site shell’ te klikken en er wordt een venster in de ‘document root’ van je WordPress site geopend. Vanuit hier kan je alle WP-CLI commando’s opgeven.

Op deze manier kun je veilig uittesten wat jouw commando’s doen op een kopie van je website.

WP-CLI in WordPress? En moet je dat willen?

Sommige hosting providers geven je wel toegang tot SSH, maar niet voldoende toegang om WP-CLI uit te mogen voeren. Daar kan je verder weinig meer aan doen.

Er zijn in principe twee manieren om in te loggen in SSH. Via een gebruikersnaam en wachtwoord of via een persoonlijk beveiligingscertificaat.

Sommige providers bieden je toegang via gebruikersnaam en wachtwoord. Op Linux en macOS is het vrij eenvoudig om een SSH verbinding te maken, op Windows bestaat het SSH commando pas sinds Windows 10. Heb je een oudere versie, dan is er het programma PuTTY wat je kan gebruiken.

Sommige providers bieden je alleen toegang via SSH vanaf computers waarop je een SSL/TLS-beveiligingscertificaat geïnstalleerd hebt. Dan kan je zonder wachtwoord inloggen, maar alleen vanaf een specifiek werkstation.

Dan is het handig om te weten, dat het ook mogelijk is om binnen WordPress zelf een terminal te installeren waarop je WP-CLI commando’s kan geven. De plugin heet ‘WP Term‘.

Let er wel op, dat dit een zeker gevaar inhoudt. Degene die dit programma gebruikt kan alles doen met je website, wat jij kan doen! En omzeilt eigenlijk alle beveiligingen die WordPress zelf heeft ingebouwd.

Zelf gebruik ik deze plugin uitsluitend in mijn eigen ontwikkelomgevingen (meestal lokaal of een afgeschermd VPS) omdat het makkelijk is om ‘snel een terminalvenster’ bij de hand te hebben. Ik gebruik deze plugin absoluut nooit in een productieomgeving.

Bedenk ook, dat wanneer het maken van een SSH verbinding met jouw website een ‘uitdaging’ is, deze plugin geen echte oplossing biedt. Maak je per ongeluk iets ‘stuk’ binnen een omgeving, dan word je opnieuw, maar nu onder tijdsdruk, geconfronteerd met de noodzaak SSH ‘aan de praat’ te krijgen.

Conclusie

WP-CLI is een krachtige tool. Voordat ik met WP-CLI begon te werken, moest ik vaak specifieke plugins installeren voor taken die ik slechts af en toe uitvoerde. Nu: Minder plugins, minder geklik en vaak ook ‘minder problemen’. Denk bijvoorbeeld aan ‘de eliminatietest’ bij het tegenkomen van plugin problemen. Wanneer je meerdere websites voor anderen beheert, is het eigenlijk een ‘must’ om de WP-CLI ‘in de vingers’ te krijgen. Vooral de mogelijkheid om -wanneer eenmaal geconfigureerd- andere websites vanuit één centraal punt te beheren scheelt je letterlijk enkele uren werk per week.

Wellicht een goed moment om aan een nieuwe hobby te beginnen?