WP-CLI Batch: Aggiorna 50+ Siti WordPress da Terminale

Name: AgencyPilot
Author: AgencyPilot

Juan Camilo Auriti

Perché WP-CLI è essenziale per le agenzie

Quando gestisci più di 10-15 siti WordPress client, l’idea di accedere manualmente a ogni bacheca per aggiornare plugin, temi o core diventa insostenibile. WP-CLI risolve questo problema permettendo di eseguire operazioni batch da terminale.

I vantaggi sono evidenti: un’operazione che richiederebbe 2-3 ore via interfaccia grafica si completa in 10-15 minuti con uno script ben scritto. Inoltre, hai pieno controllo sui log, puoi automatizzare backup pre-aggiornamento e gestire rollback in caso di problemi.

Secondo i dati del WordPress Performance Team del 2025, oltre il 68% delle agenzie con più di 50 siti in gestione utilizza WP-CLI per le operazioni di manutenzione ordinaria.

Setup iniziale: preparare l’ambiente

Installazione WP-CLI

Prima di iniziare con le operazioni batch, assicurati che WP-CLI sia installato su tutti i server che ospitano i tuoi siti WordPress. La procedura standard è:

curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
php wp-cli.phar --info
chmod +x wp-cli.phar
sudo mv wp-cli.phar /usr/local/bin/wp

Verifica l’installazione con wp --info. Se gestisci siti su server diversi, questa operazione va ripetuta su ogni macchina.

Configurazione SSH e accessi

Per operazioni batch efficienti, configura l’accesso SSH senza password usando chiavi pubbliche. Crea un file di configurazione SSH (~/.ssh/config) con alias per ogni server:

Host client1
  HostName 192.168.1.10
  User www-data
  IdentityFile ~/.ssh/id_rsa_clients

Host client2
  HostName 192.168.1.11
  User www-data
  IdentityFile ~/.ssh/id_rsa_clients

Questo ti permetterà di eseguire comandi remoti con sintassi semplificata: ssh client1 'wp core version'

Script base per operazioni batch

Struttura del file di configurazione

Il primo passo è creare un file CSV o JSON che elenchi tutti i siti da gestire. Esempio con CSV (sites.csv):

ssh_alias,path,backup,priority
client1,/var/www/sito1,yes,high
client1,/var/www/sito2,yes,medium
client2,/var/www/client-website,no,low

La colonna backup determina se creare un backup pre-aggiornamento, mentre priority può essere usata per ordinare le operazioni.

Script Bash per aggiornamenti core

Ecco uno script funzionante per aggiornare WordPress core su tutti i siti elencati:

#!/bin/bash

SITES_FILE="sites.csv"
LOG_FILE="update_$(date +%Y%m%d_%H%M%S).log"

tail -n +2 "$SITES_FILE" | while IFS=, read -r ssh_alias path backup priority; do
  echo "[$(date +%H:%M:%S)] Elaborazione: $ssh_alias - $path" | tee -a "$LOG_FILE"
  
  if [ "$backup" = "yes" ]; then
    ssh "$ssh_alias" "cd $path && wp db export backup-pre-update.sql --allow-root"
  fi
  
  ssh "$ssh_alias" "cd $path && wp core update --allow-root" 2>&1 | tee -a "$LOG_FILE"
  
  if [ $? -eq 0 ]; then
    echo "✓ Successo" | tee -a "$LOG_FILE"
  else
    echo "✗ Errore" | tee -a "$LOG_FILE"
  fi
  
  sleep 2
done

Lo script legge il CSV, esegue il backup se richiesto, aggiorna WordPress e logga tutto in un file timestampato.

Operazioni batch avanzate

Aggiornamento selettivo dei plugin

Spesso non vuoi aggiornare tutti i plugin indiscriminatamente. Puoi creare una whitelist di plugin sicuri da aggiornare automaticamente:

SAFE_PLUGINS=("yoast-seo" "wordpress-seo" "akismet" "wordfence")

for plugin in "${SAFE_PLUGINS[@]}"; do
  ssh "$ssh_alias" "cd $path && wp plugin update $plugin --allow-root"
done

Per plugin più critici (page builder, e-commerce), mantieni una blacklist e gestiscili manualmente o in ambiente staging prima.

Controllo versioni e reportistica

Prima di aggiornare, è utile generare un report sullo stato di tutti i siti:

ssh "$ssh_alias" "cd $path && wp core version && wp plugin list --format=csv" > "report_$ssh_alias.csv"

Puoi aggregare questi dati in un foglio Google Sheets o dashboard personalizzata per avere visibilità completa.

Gestione errori e rollback

Gli script di produzione devono prevedere il fallimento. Aggiungi controlli dopo ogni operazione critica:

Verifica che il sito sia raggiungibile via HTTP dopo l’aggiornamento
Controlla l’integrity del database con wp db check
Testa il login admin con wp user list
In caso di errore, ripristina il backup automaticamente

Esempio di check post-aggiornamento:

HTTP_CODE=$(curl -s -o /dev/null -w "%{http_code}" "https://$domain")
if [ "$HTTP_CODE" != "200" ]; then
  echo "Errore: sito non raggiungibile, ripristino backup"
  ssh "$ssh_alias" "cd $path && wp db import backup-pre-update.sql --allow-root"
fi

Parallelizzazione e performance

Con 50+ siti, l’esecuzione sequenziale diventa lenta. GNU Parallel permette di processare più siti contemporaneamente:

cat sites.csv | parallel --colsep ',' -j 5 'ssh {1} "cd {2} && wp core update --allow-root"'

Il flag -j 5 processa 5 siti in parallelo. Attenzione a non saturare la banda o i server: monitora il carico e regola il numero di job simultanei.

Ottimizzazioni pratiche

Connection pooling SSH: usa ControlMaster in ~/.ssh/config per riutilizzare connessioni
Timeout intelligenti: aggiungi timeout 300 prima dei comandi per evitare blocchi
Notifiche real-time: integra webhook Slack/Telegram per alert immediati su errori

Automazione con cron

Per aggiornamenti regolari degli small updates (traduzioni, minor releases), imposta un cron job settimanale:

0 3 * * 1 /home/admin/scripts/wp-batch-update.sh --minor-only >> /var/log/wp-updates.log 2>&1

Importante: gli aggiornamenti major vanno sempre testati manualmente prima. Crea una logica nello script che skippa major updates se lanciato via cron.

Alternative e tool complementari

WP-CLI è potente ma non l’unica opzione. Altri strumenti che le agenzie utilizzano:

ManageWP/MainWP: interfacce grafiche per chi preferisce GUI, con API per automazione
Ansible playbook: orchestrazione più complessa con idempotenza garantita
Custom dashboard PHP: interfaccia web che wrappa i comandi WP-CLI

Se gestisci più di 100 siti, considera piattaforme dedicate come AgencyPilot che integrano monitoraggio, backup e aggiornamenti in un’unica dashboard, con fallback automatico su WP-CLI per operazioni batch custom.

Checklist pre-produzione

Prima di lanciare script batch su siti in produzione, verifica:

Backup completi (file + database) disponibili e testati
Script testato su almeno 3 siti staging con configurazioni diverse
Log attivi e leggibili per debugging rapido
Notifiche configurate per errori critici
Procedura di rollback documentata e provata
Manutenzione programmata comunicata ai client (se aggiornamenti major)
Controllo manuale pianificato post-esecuzione per siti ad alta priorità

FAQ

È sicuro aggiornare 50 siti WordPress contemporaneamente?

Con le giuste precauzioni sì. La chiave è: backup automatici verificati prima di ogni aggiornamento, esecuzione su batch ridotti (5-10 siti in parallelo massimo), monitoring attivo durante l’operazione, e test approfonditi su staging prima di procedere. Mai aggiornare tutti i siti di venerdì sera o prima di un weekend.

WP-CLI funziona con hosting condivisi senza accesso SSH?

No, WP-CLI richiede accesso shell al server. Se gestisci siti su hosting condivisi senza SSH, devi usare alternative come ManageWP, InfiniteWP o migrare i client su VPS/hosting managed con accesso terminale. Per agenzie serie, l’accesso SSH è un requisito minimo.

Come gestire siti con configurazioni multisite WordPress?

WP-CLI supporta multisite con flag specifici. Usa --network per operazioni globali o --url=https://sottodominio.example.com per singoli siti della rete. Esempio: wp plugin update --all --network aggiorna plugin su tutti i siti della multisite. Attenzione: testa prima su staging, gli errori si propagano a tutti i subsites.

Qual è il limite pratico di siti gestibili con script batch?

Dipende dall’infrastruttura. Con server dedicati e script ottimizzati, agenzie gestiscono 200-300 siti via WP-CLI. Oltre questa soglia, considera architetture più complesse: orchestratori come Ansible, distribuzione su più server di management, o piattaforme SaaS specializzate che astraggono la complessità mantenendo la flessibilità di WP-CLI come backend.

Gli aggiornamenti batch possono causare problemi di rate limiting o IP ban?

Sì, se interroghi repository WordPress.org da un singolo IP con centinaia di richieste simultanee. Mitigazioni: limita il parallelismo (max 10-15 job simultanei), aggiungi delay casuali tra batch (sleep $((RANDOM % 10))), distribuisci le operazioni su finestre temporali più ampie, o usa proxy/IP multipli per grandi volumi. In 4 anni di operazioni batch non ho mai avuto ban rispettando queste regole.