WP-CLI: i comandi essenziali per gestire WordPress da remoto

Cos’è WP-CLI e perché si usa per gestire WordPress da remoto

Chi amministra più siti WordPress, prima o poi si scontra con lo stesso limite: il pannello di amministrazione è comodo per singole modifiche, ma diventa lento e macchinoso quando il lavoro da fare è ripetitivo o va fatto su un server senza interfaccia grafica veloce. WP-CLI (l’acronimo sta per WordPress Command Line Interface) è lo strumento ufficiale che permette di gestire WordPress da riga di comando, via [LINK GLOSSARIO]SSH[/LINK], senza passare dal browser. In pratica si tratta di un set di comandi che parlano direttamente con il core di WordPress, con il database e con i file, restituendo output immediato invece di caricare pagine PHP intere.

Perché conviene rispetto al pannello di amministrazione

Il motivo principale per cui un amministratore di sistema o un webmaster esperto preferisce WP-CLI è la velocità di esecuzione su operazioni che nel pannello richiederebbero decine di click. Aggiornare venti plugin uno per uno dal backend significa aprire venti pagine, aspettare venti caricamenti e sperare che nessuna richiesta vada in timeout: lo stesso risultato con wp plugin update --all è una singola riga eseguita in pochi secondi, e se qualcosa va storto l’errore compare subito nel terminale invece di restare nascosto in un log da andare a cercare.

Quando serve davvero (e quando non serve)

WP-CLI diventa indispensabile in scenari precisi: siti con il pannello di amministrazione inaccessibile (backend bloccato da un plugin in conflitto, per esempio), gestione di più installazioni WordPress in [LINK GLOSSARIO]multisite[/LINK], script di manutenzione automatizzata via [LINK GLOSSARIO]cron[/LINK], deploy dove l’accesso grafico non è nemmeno previsto. Non serve, invece, per la gestione occasionale di un singolo sito da parte di chi non ha già dimestichezza con il terminale: in quel caso il rischio di un comando digitato male su un ambiente di produzione supera il beneficio di velocità.

Il requisito che spesso si dà per scontato

La causa più comune per cui WP-CLI non funziona su hosting condiviso non è un problema del comando in sé, ma l’assenza dei requisiti minimi sul server: accesso SSH abilitato dall’hosting, PHP CLI disponibile (non sempre coincide con la versione PHP usata dal sito via web) e permessi utente sufficienti sulla cartella di WordPress. Su hosting condiviso economico questi tre elementi non sono sempre garantiti tutti insieme, ed è la ragione per cui molte guide generiche “non funzionano” per chi le segue senza verificare prima l’ambiente — mentre su un piano VPS o su un hosting gestito questi limiti quasi sempre non si presentano.

Come capire se il tuo ambiente è pronto per WP-CLI

Prima di lanciarsi nei comandi, va verificato che l’ambiente lo supporti davvero. Questo passaggio evita l’errore più frequente per chi prova WP-CLI per la prima volta: scoprire a metà configurazione che l’hosting non fornisce accesso SSH.

Verifica 1: accesso SSH attivo

Il primo test è collegarsi via SSH con le credenziali fornite dal hosting (di solito nel pannello cPanel, Plesk o nell’area clienti). L’esito è binario e va letto così: se si apre un prompt del terminale con il nome utente e il nome del server, il requisito è soddisfatto e si passa alla verifica successiva; se invece compare un errore di connessione rifiutata (connection refused) o un timeout, l’hosting attuale non supporta questo tipo di gestione e non ha senso proseguire con gli step successivi finché SSH non viene abilitato.

Verifica 2: WP-CLI è già installato sul server

Molti hosting gestiti orientati a WordPress (es. ambienti con stack ottimizzato) includono WP-CLI preinstallato. Basta digitare wp --info dopo essersi collegati via SSH e posizionati nella cartella del sito: se il comando restituisce versione di WP-CLI, versione PHP e percorso di WordPress, è già tutto pronto. Se invece il terminale risponde con “wp: command not found”, WP-CLI va installato manualmente (il comando non trovato è di per sé la diagnosi: manca il file eseguibile, non un problema di configurazione di WordPress).

Se l’installazione non è quella standard scaricata da WordPress.org (per esempio uno stack gestito con Composer/Bedrock, oppure un multisite), vale la pena controllarlo prima di procedere: sono le due varianti di ambiente che più spesso causano un comportamento diverso da quello descritto nelle guide generiche, come mostrato nelle ultime due righe della tabella sopra.

Installare WP-CLI: la soluzione più semplice

Se il server ha SSH attivo ma WP-CLI non è ancora installato, il percorso più diretto è scaricare il file eseguibile ufficiale e renderlo disponibile come comando globale.

Scaricare il file phar

Dopo essersi collegati via SSH, si scarica l’archivio ufficiale con curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar. Questo comando recupera direttamente il file eseguibile dal repository ufficiale del progetto, senza passare da pacchetti di terze parti.

Renderlo eseguibile e verificarlo

Il passo successivo è verificare che il file funzioni con php wp-cli.phar --info, che deve restituire un output con numero di versione e percorso PHP. Se questo test passa, il file va reso eseguibile con chmod +x wp-cli.phar e spostato in una cartella inclusa nel PATH di sistema, tipicamente con sudo mv wp-cli.phar /usr/local/bin/wp (su hosting condiviso senza permessi sudo, va usato un percorso locale nella home utente e aggiunto manualmente al PATH nel file .bashrc).

Verifica finale osservabile

A questo punto digitando semplicemente wp --info da qualsiasi cartella del server deve comparire l’output con versione WP-CLI, versione PHP e percorso di ricerca WordPress — se il sito attuale è nella cartella corrente, comparirà anche il percorso assoluto di WordPress rilevato. Se compare ancora “command not found”, il problema non è più l’installazione ma il PATH di sistema che non include la cartella dove si trova il file.

Se non hai accesso SSH o permessi sufficienti

Su alcuni hosting condivisi l’accesso SSH è del tutto assente, oppure l’utente non ha permessi per scrivere fuori dalla propria home. In questi casi il problema non si risolve lato WordPress: serve verificare direttamente con l’hosting se è possibile abilitare SSH sul piano attuale, o valutare un cambio di piano/hosting se la gestione da remoto è un requisito ricorrente.

I comandi essenziali una volta installato

Una volta verificato che l’ambiente funziona, l’uso quotidiano di WP-CLI ruota attorno a poche famiglie di comandi che coprono la quasi totalità della manutenzione ordinaria.

Aggiornamenti (core, plugin, temi)

Per aggiornare WordPress da SSH senza passare dal pannello, wp core update aggiorna il core alla versione più recente, mentre wp plugin update --all e wp theme update --all fanno lo stesso per tutti i plugin e i temi installati in un’unica esecuzione. Per un singolo plugin si usa wp plugin update nome-plugin, utile quando si vuole isolare un aggiornamento specifico prima di applicarlo a tutti gli altri.

Gestione utenti e password

Quando il backend è inaccessibile ma il server risponde, wp user update nome-utente --user_pass=nuovapassword permette di resettare la password di accesso senza passare dal form “password dimenticata” (che richiede l’invio email, non sempre affidabile se il sito ha problemi di invio SMTP). È uno dei comandi più cercati da chi si trova bloccato fuori dal proprio sito.

Database e cache: i comandi WP-CLI più usati

wp db export backup.sql crea un backup del database in un file locale prima di qualunque intervento rischioso, mentre wp cache flush svuota la cache degli oggetti se il sito usa un [LINK GLOSSARIO]object cache[/LINK] persistente (es. Redis o Memcached). Quest’ultimo comando è spesso il passaggio dimenticato dopo un aggiornamento: se le modifiche non sembrano avere effetto sul sito pubblico, prima di sospettare un errore va sempre controllato se una cache — a livello di plugin, server o CDN — sta ancora servendo la versione precedente.

Manutenzione e diagnostica

wp plugin list --status=active elenca solo i plugin attivi con relativa versione, utile per un controllo rapido prima di un aggiornamento massivo. wp core verify-checksums confronta i file del core con i checksum ufficiali e segnala eventuali file modificati: è un controllo diagnostico concreto quando si sospetta una compromissione, molto più affidabile di un semplice “il sito sembra strano”.

Automatizzare la manutenzione con cron e script

Un uso avanzato ma molto comune di WP-CLI è la programmazione automatica di operazioni ricorrenti tramite [LINK GLOSSARIO]cron job[/LINK] a livello di sistema operativo (diverso dal WP-Cron interno di WordPress, che dipende dal traffico del sito per essere eseguito). Uno script bash che lancia wp core update, wp plugin update --all e un backup del database in sequenza, schedulato una volta a settimana, riduce drasticamente il lavoro manuale su installazioni multiple. Questo scenario è tipico di chi gestisce diversi siti WordPress per conto di clienti e ha bisogno di uniformare la manutenzione senza intervenire uno per uno dal pannello.

Non riesci a usare WP-CLI o a gestire il sito da remoto? Intervento tecnico a distanza

Non tutti gli hosting sono configurati allo stesso modo, e non sempre chi gestisce un sito ha il tempo o la competenza tecnica per risolvere da solo un errore di permessi, un PATH mal configurato o un conflitto tra la versione PHP CLI e quella usata dal sito. Se dopo aver seguito questi passaggi WP-CLI continua a non funzionare, oppure il vero obiettivo non è installare uno strumento ma risolvere un problema specifico sul sito (backend bloccato, aggiornamenti falliti, sito lento), è possibile richiedere una verifica diretta: invia l’accesso SSH o FTP del tuo hosting e viene fatta una diagnosi mirata, senza dover imparare tu stesso la sintassi dei comandi. È un intervento pensato per chi vuole il risultato — sito aggiornato e funzionante — senza passare mesi a familiarizzare con il terminale.

Domande frequenti su WP-CLI

WP-CLI funziona su qualsiasi hosting WordPress? No. Serve un hosting che fornisca accesso SSH e permetta l’esecuzione di PHP da riga di comando. Molti hosting condivisi economici non includono questa possibilità di default, mentre è quasi sempre presente su VPS, server dedicati e hosting gestiti orientati a WordPress.

Devo essere uno sviluppatore per usare WP-CLI? Non è strettamente necessario, ma serve una minima familiarità con il terminale e con concetti come percorsi di cartelle e permessi file. Per operazioni singole e occasionali il pannello di amministrazione resta più adatto a chi non ha esperienza da riga di comando.

WP-CLI può rompere il mio sito se sbaglio un comando? Sì, come qualunque operazione diretta su database o file: per questo prima di comandi che modificano dati (aggiornamenti, modifiche a utenti, operazioni sul database) è sempre consigliato un backup con wp db export, esattamente come si farebbe da pannello prima di un aggiornamento importante.

Perché wp –info restituisce una versione PHP diversa da quella del mio sito? Perché il PHP usato dal server web (Apache/Nginx) e il PHP CLI usato dal terminale possono essere due binari distinti, specialmente su hosting condivisi con più versioni PHP installate. Va verificato quale versione CLI è attiva con php -v e, se necessario, allineata a quella del sito.

Posso usare WP-CLI se il backend di WordPress è bloccato? Sì, ed è uno dei casi d’uso più utili: se il pannello risulta inaccessibile per un plugin in conflitto o un PHP Fatal error che blocca il caricamento del backend, WP-CLI permette di disattivare plugin (wp plugin deactivate nome-plugin) o correggere impostazioni direttamente dal database, senza passare dal backend.

Vuoi risolverlo con un intervento diretto? Se preferisci non gestire da solo l’installazione o la diagnosi via terminale, → Ricevi assistenza professionale: invia l’accesso al tuo hosting e viene verificato lo stato del sito, con eventuale intervento tramite WP-CLI dove serve, senza che tu debba configurare nulla in prima persona.