WordPress hosting - Web Design | Creazione Siti Internet https://www.mrtux.it Sviluppo Siti Web - Assistenza WordPress Sat, 27 Jun 2026 09:34:09 +0000 it-IT hourly 1 https://wordpress.org/?v=7.0.1 https://www.mrtux.it/wp-content/uploads/2022/06/favicon-150x150.png WordPress hosting - Web Design | Creazione Siti Internet https://www.mrtux.it 32 32 WordPress PHP thread 2026: come i bot AI li stanno esaurendo https://www.mrtux.it/php-thread-exhaustion-wordpress-bot-ai-2026 https://www.mrtux.it/php-thread-exhaustion-wordpress-bot-ai-2026#respond Sat, 27 Jun 2026 09:34:07 +0000 https://www.mrtux.it/wordpress-php-thread-2026-come-i-bot-ai-li-stanno-esaurendo Se hai un sito WordPress o WooCommerce che ha cominciato a restituire 504 error improvvisi nel 2026 senza un picco di traffico reale, la causa non è il tuo hosting, non è un attacco DDoS, non è Google: è quasi certamente un singolo bot AI che sta riempiendo il tuo pool di PHP thread con richieste dinamiche ad alta durata. Non è una storia di SEO, non è una storia di sicurezza informatica: è una storia di capacity planning che nessuno aveva previsto prima dell'esplosione dei crawler AI.

In Bot WordPress: il vero costo dei thread PHP riservati nel 2026 abbiamo iniziato a mettere a fuoco il problema dei thread come risorsa scarsa. Qui costruiamo sopra quel ragionamento un framework operativo: come misurare, come diagnosticare, come intervenire quando un singolo bot AI mette in ginocchio un e-commerce in pieno giorno.

Perché il 2026 è diverso dal 2024

Fino al 2024 il traffico bot era un fastidio misurabile in percentuale. Googlebot passava, indicizzava, se ne andava. I bot malevoli colpivano login e wp-admin. Le soluzioni esistenti — WAF, robots.txt, captcha — bastavano perché la stragrande maggioranza del traffico era umana, leggera, e per lo più servita da cache.

Dal 2025 la composizione è cambiata radicalmente. Secondo i dati pubblicati da Kinsta su 10 miliardi di richieste analizzate, GPTBot è cresciuto del 305% tra maggio 2024 e maggio 2025, e il rapporto di visite AI bot sul totale è passato da 1 su 200 a 1 su 31. Sulle reti Cloudflare la percentuale di richieste HTML da AI crawler è arrivata al 4,2% a fine 2025, con picchi del 6,4% a giugno.

Ma il numero assoluto non racconta il punto. Il punto è che questi crawler AI:

  • non si comportano come Googlebot (che indicizza e se ne va);
  • non si comportano come bot malevoli (che cercano wp-login);
  • non rispettano i rate limit impliciti del robots.txt;
  • colpiscono preferenzialmente endpoint dinamici che richiedono PHP + database.

Quando un crawler AI incontra un endpoint uncached come /cart, /checkout, ?add-to-cart=1234, ?s=ricerca, ogni richiesta diventa una nuova elaborazione PHP completa. Non c'è HTML statico da servire. Non c'è cache LSCache o WP Rocket che tenga. Il thread PHP viene occupato per 200-500 millisecondi (più a lungo se la pagina è complessa), e finché non rilascia non può servire nessun altro.

Anatomia di una richiesta dinamica su WooCommerce

Per capire perché il 2026 è una categoria nuova di problema, devi capire cosa succede davvero sul tuo server quando un bot AI colpisce il carrello di un WooCommerce.

Una richiesta POST /cart?add-to-cart=1234 fa, in ordine:

  1. Avvia una sessione WooCommerce (scrittura su wp_woocommerce_sessions o su Redis se configurato).
  2. Riserva un PHP-FPM worker dal pool, tipicamente pm.max_children tra 10 e 60 su hosting condiviso, 100-300 su managed.
  3. Carica il core WordPress + plugin attivi + theme functions.php — circa 80-150 MB di RAM.
  4. Esegue la query prodotto (SELECT * FROM wp_posts WHERE ID=1234) con i suoi meta associati.
  5. Aggiorna lo stato del carrello in sessione.
  6. Restituisce una redirect HTTP 302 al cliente.

Tutto questo per una richiesta che non convertirà mai in un ordine, perché arriva da un bot che sta solo enumerando URL. E mentre quel worker è occupato, non può servire nessun altro visitatore.

Su un hosting con 30 PHP-FPM worker, bastano 30 richieste dinamiche simultanee da bot per saturare completamente il pool. Il visitatore umano numero 31 entra in coda. Se la coda si riempie (pm.backlog_limit), Nginx restituisce 502 o 502/504. Il cliente vede una pagina bianca durante il checkout e abbandona il carrello. Tu vedi nel log connect() failed (111: Connection refused) while connecting to upstream e pensi che sia un problema del tuo hosting provider.

Non lo è. È un problema di capacity planning, e fino al 2024 non esisteva perché il volume di traffico dinamico non automatizzato era troppo basso per saturare i pool.

Il caso ClaudeBot che ha generato 3,75 milioni di add-to-cart

Kinsta ha pubblicato un dato che merita di essere raccontato per intero: un singolo bot, identificato come ClaudeBot, ha generato 3,75 milioni di richieste ?add-to-cart= su un singolo store WooCommerce gestito in 24 ore. Fanno circa una richiesta ogni 23 millisecondi, 24 ore su 24, 7 giorni su 7.

Facciamo i conti. Una richiesta add-to-cart tipo occupa un PHP-FPM worker per circa 300 millisecondi (start sessione + query prodotto + scrittura carrello). In 24 ore ClaudeBot ha quindi consumato:

  • 3.750.000 × 0,3 secondi = 1.125.000 secondi-worker.
  • Su un pool di 50 PHP-FPM worker (un managed hosting medio), il pool è stato saturato al 100% per 1.125.000 / 50 = 22.500 secondi, pari a 6,25 ore di lavoro "pieno" solo da quel singolo bot.

Ma la distribuzione non è uniforme: quando ClaudeBot ha colpito in momenti di basso traffico umano (le 3 di notte, ad esempio) il pool è stato saturato al 100% solo per il bot, e i visitatori diurni non ne hanno risentito. Quando ha colpito in momenti di picco (le 12 o le 19, fasce di punta di un e-commerce), il 20-40% della capacità del pool è stata dirottata su richieste bot, allungando i tempi di risposta del checkout da 1,2 secondi a 4-8 secondi — esattamente il range in cui il tasso di abbandono carrello sale dal 30% al 70%.

C'è un secondo dato ancora più inquietante: un pattern di loop non malevolo ma "vibe coded male" ha generato 550 milioni di richieste su 30 giorni per un singolo store, giustificando da solo una regola di mitigazione dedicata nell'infrastruttura Kinsta. Non è un attacco, non è malware: è una persona che ieri non sapeva cosa stesse facendo e oggi ha fatto vibrare un bot e lo ha lasciato andare. Suo malgrado, è la causa principale del tuo 504.

Il framework operativo: la "PHP thread economy"

Per gestire questa categoria di problema servono cinque passi, in ordine. Non sono alternativi, sono cumulativi.

Misura il tuo PHP-FPM pool reale, non quello dichiarato

Il primo errore è pensare che il tuo hosting abbia "PHP illimitati" perché il pannello lo dichiara. La realtà è:

# controlla il pool effettivo di PHP-FPM
ssh tuo_server 'cat /etc/php/*/fpm/pool.d/www.conf | grep -E "pm.max_children|pm.start_servers|pm.min_spare_servers|pm.max_spare_servers"'

Annota pm.max_children: è il numero massimo di PHP-FPM worker attivi. Su hosting condiviso è spesso 10-20. Su managed è 50-300. Su VPS è quello che hai configurato tu, spesso male.

Poi misura il consumo reale:

# script: monitor php-fpm status via curl + parsing JSON
curl -s "YOUR_PHP_FPM_STATUS_ENDPOINT" |   python3 -c "import json,sys; d=json.load(sys.stdin);   print(f"active={d['active processes']} idle={d['idle processes']} total={d['total processes']} max_active={d['max active processes']} max_children_reached={d['max children reached']}")"

L'output ti dice max children reached: se è maggiore di zero nell'ultima ora, hai già saturo il pool almeno una volta. Questo è il tuo problema.

Identifica i 5 endpoint dinamici più colpiti dai bot

Non tutti gli endpoint sono uguali. Su un WooCommerce tipico, il 90% del danno arriva da:

# analizza i log Nginx per endpoint dinamici
awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -30 |   grep -E "add-to-cart|/cart|/checkout|/my-account|/?s=|/?wc-api="

Se ?add-to-cart= è in cima alla classifica con centinaia di migliaia di richieste al giorno e il tuo negozio riceve solo 500 ordini reali al giorno, hai il problema.

Calcola il tuo "throughput dinamico sostenibile"

Ecco la formula che ti serve: throughput_max = max_children / durata_media_richiesta_dinamica.

Con max_children = 30 e durata_media_dinamica = 0,4s (carrello + checkout tipici):

# esempio codice
throughput_max = 30 / 0,4 = 75 richieste dinamiche/secondo

Questo è il tuo tetto. Qualsiasi combinazione di bot + visitatori umani che supera 75 richieste/secondo verso endpoint dinamici manderà in saturazione il pool. Su un e-commerce medio con 500 ordini/giorno, significa che bastano 50 bot aggressivi per esaurire la capacità di servire ordini reali nei momenti di punta.

Implementa le 4 leve in ordine di priorità

Una volta misurato, agisci in quest'ordine:

  1. Edge cache differenziata per AI bot: Cloudflare o Varnish possono servire una versione cached delle pagine dinamiche solo ai bot AI, con TTL breve (6 ore). Implementazione Nginx:
# in nginx.conf o nella conf del sito
map $http_user_agent $is_ai_bot {
    default 0;
    ~*GPTBot 1;
    ~*ClaudeBot 1;
    ~*PerplexityBot 1;
    ~*OAI-SearchBot 1;
    ~*CCBot 1;
    ~*Google-Extended 1;
    ~*Bytespider 1;
}

# imposta TTL differenziato
proxy_cache_valid 200 6h if $is_ai_bot = 1;
proxy_cache_valid 200 1h if $is_ai_bot = 0;

L'AI bot riceve una versione cached della pagina carrello (utile per il suo scopo di retrieval), il visitatore umano riceve sempre la versione dinamica reale.

  1. Rate limiting su endpoint dinamici specifici:
# limita solo i bot dinamici, non gli umani
limit_req_zone $binary_remote_addr zone=dyn_bot:10m rate=10r/s;
location ~* ^/(cart|checkout|my-account|wc-api/) {
    limit_req zone=dyn_bot burst=20 nodelay;
    limit_req_status 429;
}

Un bot che tenta 50 add-to-cart al secondo riceverà 429 dopo i primi 30, e il tuo pool PHP sarà salvo.

  1. Kill switch su loop: se identifichi un IP che genera più di 100 richieste dinamiche in 60 secondi, bloccalo per 1 ora.
# fail2ban filter per WooCommerce bot loop
cat > /etc/fail2ban/filter.d/woocommerce-bot-loop.conf << 'EOF'
[Definition]
failregex = ^<HOST> .* "(GET|POST) /(cart|checkout|my-account|.*add-to-cart=).*"
ignoreregex =
EOF
  1. PHP-FPM tuning mirato: se dopo le 3 precedenti sei ancora al limite, aumenta pm.max_children ma SOLO se il server ha RAM disponibile. Ogni worker PHP consuma 80-150 MB. Se il server ha 4 GB di RAM e 20 worker, puoi arrivare a 30-35. Oltre comincerai a swappare e il degrado sarà peggiore.

Monitora e allerta proattivamente

Il framework non serve a nulla senza monitoring continuo. Lo script che segue gira via cron ogni 5 minuti e ti avvisa su Telegram (o email) quando il pool si avvicina alla saturazione:

#!/bin/bash
# /usr/local/bin/php-pool-watch.sh
# monitor saturazione PHP-FPM e invia alert se > 80% per 3 check consecutivi

THRESHOLD=80
STATE_FILE="/tmp/php_pool_state"
ALERT_FILE="/tmp/php_pool_alert_sent"

ACTIVE=$(curl -s "YOUR_PHP_FPM_STATUS_ENDPOINT" | python3 -c "import json,sys; print(json.load(sys.stdin)['active processes'])")
MAX=$(curl -s "YOUR_PHP_FPM_STATUS_ENDPOINT" | python3 -c "import json,sys; print(json.load(sys.stdin)['max children reached'])")
PERCENT=$((ACTIVE * 100 / MAX_CHILDREN))

echo "$(date +%s) $PERCENT" >> "$STATE_FILE"

# alert se >80% per 3 check consecutivi (15 minuti)
if [ "$PERCENT" -gt "$THRESHOLD" ]; then
    CONSECUTIVE=$(tail -3 "$STATE_FILE" | awk '{print $2}' | grep -c "$PERCENT")
    if [ "$CONSECUTIVE" -ge 3 ] && [ ! -f "$ALERT_FILE" ]; then
        curl -s -X POST "https://api.telegram.org/bot${TELEGRAM_BOT_TOKEN}/sendMessage"           -d "chat_id=${TELEGRAM_CHAT_ID}"           -d "text=⚠️ PHP-FPM al ${PERCENT}% da 15+ minuti. Bot AI probabile causa. Controlla log: $(date)"
        touch "$ALERT_FILE"
    fi
else
    rm -f "$ALERT_FILE"
fi

Le 3 trappole che anche i team senior cadono

Trappola 1: scalare il piano hosting come prima risposta

Quando il pool satura, la prima reazione è "aumentiamo il piano". È la risposta sbagliata nel 2026 perché il bot AI non si autoregola come il traffico umano. Più capacità dai al bot, più ne consuma. Su Kinsta hanno documentato un caso in cui l'aumento di 4 volte della capacità del pool è stato interamente assorbito da bot AI in 72 ore, senza alcun beneficio per il visitatore umano.

In Scalare hosting WordPress contro i bot AI: guida completa abbiamo approfondito perché la scalabilità senza differenziazione del traffico è una perdita netta.

Trappola 2: bloccare indiscriminatamente il bot

Alcuni hosting provider hanno introdotto regole aggressive "block all AI bots by default". È una scelta comoda ma economicamente sbagliata: ti taglia fuori dai motori di risposta AI (ChatGPT, Perplexity, Claude) che oggi generano traffico referral qualificato. In AEO WordPress 2026: llms.txt e infrastruttura per AI bot abbiamo mostrato come un blocco totale può ridurre il referral AI del 100% — non una semplificazione, un danno.

Trappola 3: affidarsi solo al WAF commerciale

WAF come Cloudflare, Sucuri o Wordfence offrono regole "AI bot" già pronte, ma sono spesso troppo permissive (consentono bot che hanno User-Agent legittimo ma comportamento malevolo) o troppo aggressive (bloccano bot utili come Applebot-Extended che alimenta Siri). Vanno usate come complemento, mai come unica linea di difesa. Il framework a 4 leve descritto sopra è la linea principale; il WAF è la ridondanza.

Roadmap operativa per i prossimi 30 giorni

Per implementare il framework su un sito WooCommerce tipico:

Settimana 1: diagnostica

  • Misura pm.max_children reale e consumi RAM del pool.
  • Identifica i 5 endpoint dinamici più colpiti via log analysis.
  • Calcola il tuo throughput dinamico sostenibile con la formula sopra.
  • Stabilisci la baseline: quanti 504/429 ricevi oggi?

Settimana 2: contromisura leggera

  • Implementa la mappa Nginx $is_ai_bot con cache differenziata.
  • Aggiungi rate limiting sui 5 endpoint dinamici.
  • Attiva fail2ban con il filter WooCommerce bot loop.

Settimana 3: monitoraggio

  • Deploya lo script php-pool-watch.sh via cron ogni 5 minuti.
  • Configura alert Telegram/email al superamento dell'80% per 3 check consecutivi.
  • Traccia per 7 giorni la correlazione tra saturazione pool e richieste bot.

Settimana 4: ottimizzazione

  • Se i dati confermano la correlazione bot-saturazione, attiva la regola PHP-FPM tuning.
  • Se il 30%+ delle richieste bot proviene da un singolo User-Agent, valuta una block list chirurgica (non blanket, specifica per endpoint).
  • Documenta le soglie di intervento nel tuo runbook operations.

Domande frequenti

Come faccio a sapere se il mio PHP-FPM pool satura davvero?

Il modo più diretto è esporre lo status endpoint di PHP-FPM e leggerlo ogni minuto via script. Se max children reached è maggiore di zero in qualunque momento dell'ultima ora, hai saturato. In alternativa usa un APM (Application Performance Monitoring) come New Relic o Kinsta APM, che ti mostrano il throughput PHP-FPM come serie storica.

Un WAF commerciale è sufficiente?

No. Un WAF blocca pattern noti ma non protegge dalla saturazione del pool causata da bot AI legittimi (User-Agent dichiarato, IP pulito, comportamento "normale" ma a volume troppo alto). Il WAF è una ridondanza; il framework a 4 leve è la difesa primaria.

Posso aumentare semplicemente pm.max_children?

Sì, ma solo se hai RAM disponibile. Ogni worker PHP consuma 80-150 MB. Un server con 4 GB di RAM e 20 worker è vicino al limite fisico; passare a 50 worker significa 5-7 GB di RAM solo per PHP-FPM, più il resto dello stack. Se swappi, il degrado è peggiore della saturazione. Misura sempre la RAM disponibile prima di toccare pm.max_children.

I bot AI rispettano robots.txt?

Alcuni sì, altri no, e anche quelli che lo rispettano non rispettano necessariamente i rate limit impliciti. Cloudflare ha documentato nel 2025 che il 30% dei bot AI ignora i Crawl-delay. Non fare affidamento solo su robots.txt.

Esiste un plugin WordPress che fa tutto questo?

Non un plugin unico, perché il problema è a livello di web server (Nginx/Apache) e PHP runtime, non di applicazione. Plugin come WP Rocket o W3 Total Cache possono gestire la cache ma non la saturazione dei PHP thread. Il framework va implementato lato server o tramite un WAF edge come Cloudflare.

Quando devo considerare un hosting gestito specializzato?

Quando il tuo tasso di saturazione supera il 5% delle ore diurne e il tuo business dipende da conversioni WooCommerce time-sensitive. A quel punto il costo orario del degrado (carrelli abbandonati) supera il costo dell'upgrade a un hosting gestito con bot protection integrata. In WooCommerce protezione bot AI performance abbiamo calcolato i numeri per uno store medio da 12.000 SKU.

Checklist operativa finale

  • pm.max_children misurato e documentato
  • Top 5 endpoint dinamici identificati via log analysis
  • Throughput dinamico sostenibile calcolato
  • Mappa Nginx $is_ai_bot attiva con cache differenziata
  • Rate limiting su endpoint dinamici (limit_req_zone)
  • Fail2ban WooCommerce bot loop configurato
  • Script di monitoraggio PHP-FPM attivo via cron
  • Alert Telegram/email al superamento soglia
  • WAF commerciale attivo come ridondanza
  • Runbook operations con soglie di intervento documentato

Riferimenti utili per approfondire

]]> https://www.mrtux.it/php-thread-exhaustion-wordpress-bot-ai-2026/feed 0 StellarWP dissolve: guida alla migrazione dei plugin nel 2026 https://www.mrtux.it/stellarwp-liquidweb-dissolution-migrazione-wordpress-2026 https://www.mrtux.it/stellarwp-liquidweb-dissolution-migrazione-wordpress-2026#respond Sat, 20 Jun 2026 03:16:28 +0000 https://www.mrtux.it/stellarwp-dissolve-guida-alla-migrazione-dei-plugin-nel-2026 Cosa è davvero successo a StellarWP e perché riguarda anche te

Se gestisci un sito WordPress con GiveWP per le donazioni, LearnDash per la formazione o SolidWP per i backup, la notizia è arrivata il 20 maggio 2026: StellarWP, l'ombrello che dal 2021 raggruppava questi plugin sotto Liquid Web, è in fase di dissoluzione completa. Lo ha annunciato Liquid Web stessa in un post sul proprio blog aziendale (Liquid Web: The End of StellarWP).

Sul momento sembra un'operazione di facciata societaria, ma non lo è. Una dissoluzione (diversa da una vendita o da un'acquisizione) significa che il brand sparisce e che ogni prodotto torna a una gestione indipendente. Le licenze restano valide, il codice resta GPL, ma l'ecosistema di supporto, aggiornamenti congiunti, integrazioni cross-product e roadmap condivise si dissolve. Chi ha costruito workflow su quel "brand unico" ora deve ripensare 4 cose concrete: manutenzione, billing, integrazioni, roadmap di medio periodo.

In questo articolo vediamo cosa cambia davvero, cosa rischi a non muoverti e come gestire la migrazione in modo operativo. È un caso di scuola per chiunque venda prodotti digitali basati su WordPress: la stabilità di un plugin non dipende solo dalla qualità del codice ma dalla sostenibilità economica di chi lo mantiene. Su questo tema ho già scritto di supply chain AI in plugin (Supply chain attack nei plugin WordPress) e di Plugin Team AI triage (Plugin Team triage AI): qui l'angolo è più operativo, focalizzato sulla continuità del tuo business.

Le tre famiglie di prodotti e la loro posizione attuale

StellarWP non era un insieme casuale: era una strategia di up-sell incrociato tra prodotti complementari. Le tre famiglie principali avevano posizioni diverse nel mercato e quindi impatti diversi dalla dissoluzione.

GiveWP: il player dominante delle donazioni

GiveWP controlla circa il 40% del mercato WordPress delle donazioni (stima basata sui download attivi nel repository ufficiale). È il plugin usato da ONG, università, chiese e comitati. La sua forza storica era l'integrazione con StellarPayments e con i report fiscali di SolidWP. Con la dissoluzione, GiveWP torna a un brand indipendente mantenendo la stessa base di codice, ma perde:

  • il coordinamento marketing con gli altri prodotti StellarWP
  • la roadmap congiunta che includeva StellarPayments v2
  • il supporto tecnico di primo livello "unified"

LearnDash: il player LMS in fase di consolidamento

LearnDash è uno dei tre LMS più diffusi su WordPress (insieme a Tutor LMS e LifterLMS). Negli ultimi anni ha puntato molto su AI-generated quiz e su integrazioni con WooCommerce per la vendita dei corsi. La dissoluzione non cambia le funzionalità esistenti ma congela di fatto lo sviluppo AI-driven che dipendeva dalla roadmap unificata StellarWP.

SolidWP: backup e manutenzione

SolidWP era il brand meno visibile ma strategico: plugin di backup, manutenzione e sicurezza base. Plugin come Solid Backups (ex BackupBuddy) e Solid Security (ex iThemes Security) hanno base utenti enorme. La loro forza era il cross-sell con gli altri prodotti StellarWP; da soli tornano a brand indipendenti con la necessità di rifare go-to-market.

Cosa cambia operativamente per i siti in produzione

Il rischio concreto: license server, rinnovi, changelog congelato

Quando un brand dissolto viene mantenuto da una nuova entità operativa, succedono tre cose nei primi 90 giorni che devi monitorare:

  1. License server instabile: la piattaforma che gestisce le chiavi di licenza può cambiare dominio o backend, con rischio di disconnessioni temporanee. Pianifica un controllo settimanale delle licenze per i primi 3 mesi.
  2. Rinnovi più cari o interrotti: i prezzi di listino cambiano. Liquid Web ha comunicato che manterrà i prezzi attuali per il 2026, ma dal 2027 ogni prodotto avrà pricing indipendente. Blocca un budget di contingenza.
  3. Changelog più lento: i team di sviluppo vengono riorganizzati. Bug fix critici e patch di sicurezza arrivano comunque (perché il codice è GPL e deve restare nel repository), ma feature nuove rallentano.

Integrazioni cross-product da rifare

Molti siti hanno costruito workflow basati su integrazioni tra GiveWP + Solid Backups + LearnDash (es. report aggregati di donazioni, sincronizzazione profili utenti donatori con studenti LMS). Queste integrazioni erano supportate a livello di brand; ora vanno gestite via singoli plugin o custom hook.

Un check rapido da fare subito è capire quante integrazioni cross-product hai in produzione. Lo snippet bash che segue individua tutte le chiamate a funzioni StellarWP nei temi e plugin custom del tuo sito:

# cerca tutte le occorrenze di funzioni StellarWP nel codice custom
find /home/your-user/your-site/wp-content/themes /home/your-user/your-site/wp-content/plugins -type f -name '*.php' \
  -exec grep -lE 'stellarwp_|StellarWP|stellar_payments' {} \;

Il comando restituisce l'elenco dei file che usano API StellarWP. Per ciascuno, valuta se l'integrazione resta valida o se va riscritta. Su un'installazione media ci si aspettano 5-15 file toccati.

Audit pre-migrazione in 5 step

Una migrazione vera inizia con un audit, non con una sostituzione affrettata. Ecco una procedura testata su installazioni GiveWP di medie dimensioni (10k-100k donazioni annue):

  1. Inventario plugin: usa WP-CLI per elencare tutte le plugin StellarWP attive con versione e ultimo aggiornamento. Il comando wp plugin list --status=active --format=table ti dà lo stato; aggiungi --format=json | jq '.[] | select(.name|test("GiveWP|LearnDash|Solid"))' per filtrare.
  2. Verifica licenze attive: per ogni plugin commerciale, controlla lo stato della chiave di licenza. Plugin come Solid Backups usano wp option get solid_backup_license (nome opzione varia per prodotto).
  3. Backup completo: prima di qualsiasi modifica, snapshot di file system + database. Se sei su managed hosting Kinsta o WP Engine, hai backup automatici giornalieri; se sei su VPS, un wp db export + tar.gz della wp-content è la baseline.
  4. Analisi integrazioni: mappa tutte le personalizzazioni custom che dipendono dalle API StellarWP. Lo snippet bash sopra è il punto di partenza.
  5. Test di regressione: prima di toccare la produzione, replica l'ambiente in staging e verifica che il workflow donazioni / LMS / backup continui a funzionare con la nuova configurazione.

Alternative concrete per ogni prodotto

Per ogni plugin StellarWP esistono alternative credibili sul mercato. La scelta dipende da quanto sei già integrato con l'ecosistema e da quanto budget hai per la migrazione.

Confronto rapido alternative

Per GiveWP le alternative più solide nel 2026 sono Donorbox (SaaS ibrido con plugin leggero), Charitable (lightweight, ottimo per setup medio) e WPForms + Stripe per chi vuole una soluzione modulare. Donorbox ha un piano gratuito fino a 5.000$/mese di donazioni processate, poi passa a 4$/mese più percentuale; Charitable è completamente self-hosted con donazioni illimitate e costo una tantum di 249$ per il Pro.

Per LearnDash il panorama è più frammentato: Tutor LMS (più adatto a MOOC accademici, modello freemium), LifterLMS (più focalizzato su membership e coaching, modello a plugin singolo 199$/anno) e MasterStudy (più orientato a corsi strutturati con gamification, modello freemium + Pro 199$/anno). Il breakpoint è il tipo di audience: se vendi corsi B2B con gamification e certificate, MasterStudy è imbattibile; se fai formazione interna o community, LifterLMS è più snello.

Per Solid Backups le opzioni più diffuse sono UpdraftPlus (250k+ install attive, modello freemium con Premium da 70$/anno), BlogVault (SaaS ibrido, 7.4$/mese per sito) e BackupBuddy di nuova generazione (se decidi di restare su iThemes). Per Solid Security il competitor dominante resta Wordfence (gratuito con Premium 119$/anno), affiancato da Solid Security Pro standalone (continua esistendo) e Shield Security (modello freemium).

La regola operativa è: non migrare tutto subito. Dai priorità ai plugin il cui vendor ha comunicato discontinuità di supporto. Il resto può restare com'è per i prossimi 12 mesi mentre osservi l'evoluzione del mercato.

Roadmap di migrazione realistica

Una migrazione vera, su un sito con 100k+ visitatori mensili e donazioni attive, si fa in 6-10 settimane. Non in un weekend.

Fase 1 (settimana 1-2): osservazione e audit

  • Blocca ogni decisione affrettata per 14 giorni. Aspetta che la polvere si depositi.
  • Esegui l'audit dei 5 step sopra. Documenta tutto in un foglio condiviso.
  • Identifica i 3-5 workflow critici che dipendono da StellarWP.
  • Mappa i costi reali: licenze annuali in scadenza, contratti di supporto attivi, integrazioni custom da rifare.

Fase 2 (settimana 3-4): staging e test

  • Clona la produzione in staging. Se usi Kinsta, è un click. Se sei su VPS, wp db export + duplicazione della wp-content.
  • Installa la prima alternativa (es. Donorbox) in staging. NON in produzione.
  • Migra 10 donazioni di test, verifica report, email, fiscali, integrazione con WooCommerce se presente.
  • Testa il rollback: deve funzionare in meno di 5 minuti.

Fase 3 (settimana 5-6): migrazione morbida in produzione

  • Vai in produzione durante una finestra a basso traffico (tipicamente martedì-giovedì, ore 10-14, quando le donazioni B2C sono al minimo).
  • Mantieni GiveWP attivo in "shadow mode" per 30 giorni: il plugin gira ancora ma non raccoglie nuove donazioni, mentre Donorbox raccoglie il 100% del nuovo traffico.
  • Monitora metriche: tasso di completamento donazione, errori 500, tempi di risposta del checkout, tasso di abbandono.

Fase 4 (settimana 7-10): consolidamento

  • Dopo 30 giorni di shadow mode, disattiva GiveWP ma tienilo installato per altri 60 giorni come fallback di emergenza.
  • Esporta lo storico delle donazioni passate. Plugin come WPForms + Add-on Migration o script custom SQL permettono di portare i dati storici nel nuovo sistema.
  • Aggiorna documentazione interna, runbook, contatti di supporto.

Monitoraggio post-migrazione: cosa controllare nei primi 90 giorni

La migrazione non finisce quando il nuovo plugin è attivo. I primi 90 giorni sono la fase più delicata, perché è qui che emergono bug di integrazione, differenze di comportamento nei workflow e cali di conversione.

Metriche di business da tracciare

Configura una dashboard con 5 metriche minime e confronta i 30 giorni pre-migrazione con i 30 giorni post-migrazione. La metrica più importante è il tasso di completamento donazione (o iscrizione corso, a seconda del prodotto): se cala più del 5%, c'è un problema di UX o di integrazione da indagare subito. La seconda metrica è il tempo medio di checkout, che non deve aumentare più del 10%. La terza sono gli errori 5xx durante il flusso di pagamento, che devono restare sotto lo 0.5%. La quarta è il tasso di abbandono carrello, che di solito migliora con plugin moderni (Donorbox, Charitable) ma può peggiorare se il checkout ha troppi passaggi. La quinta è il net promoter score dei donatori o studenti, misurabile con un singolo campo nel form di conferma.

Metriche tecniche da non perdere di vista

Oltre alle metriche di business, monitora i segnali tecnici che indicano problemi sottotraccia. Il tempo di risposta del checkout non deve peggiorare più del 20%. I log di errore PHP devono restare sotto le 50 entry giornaliere (puoi filtrarli con uno snippet WP-CLI che ti mostro tra poco). Le richieste al license server non devono fallire più del 2%. Le chiamate API esterne (Stripe, PayPal, gateway di pagamento) devono restare sotto i 500ms di latenza p95.

Un trucco operativo per monitorare i log PHP senza dipendere da strumenti esterni è creare un alias WP-CLI che filtra solo gli errori rilevanti per il nuovo plugin. Lo snippet bash che segue crea un comando rapido wp-checkout-errors:

# alias per controllare errori checkout nelle ultime 24h
wp-checkout-errors() {
  find /home/your-user/your-site/wp-content/debug.log -mtime -1 \
    -exec grep -E 'donorbox|charitable|tutor|stripe|paypal' {} \; \
    | tail -50
}

Aggiungi questa funzione al tuo .bashrc e avrai un monitoraggio real-time pronto in 5 secondi. Se la coda di errori cresce, hai un problema e devi intervenire.

Checklist operativa finale

Questa è la checklist da stampare e attaccare al monitor del project manager:

  • [ ] Inventario plugin StellarWP attivi via WP-CLI
  • [ ] Verifica stato licenze per ciascun plugin commerciale
  • [ ] Backup completo pre-migrazione (file system + database)
  • [ ] Mappa integrazioni cross-product StellarWP
  • [ ] Analisi costi licenze attuali vs alternative (TCO 24 mesi)
  • [ ] Test in staging con almeno 3 donazioni/corse reali simulate
  • [ ] Migrazione in produzione in finestra a basso traffico
  • [ ] Shadow mode 30 giorni prima di disattivare il vecchio plugin
  • [ ] Esportazione storico dati verso il nuovo sistema
  • [ ] Aggiornamento runbook interni
  • [ ] Notifica stakeholder: team comunicazione, team fundraising, finance
  • [ ] Comunicazione pubblica sul sito (se donatori sono coinvolti)

Lezione di sistema: il rischio vendor è una variabile di business

La dissoluzione di StellarWP è un caso di scuola che va oltre i singoli plugin. Il punto chiave è questo: la continuità operativa del tuo sito WordPress dipende dalla sostenibilità economica di chi mantiene i plugin critici. Plugin con milioni di installazioni attive possono essere venduti, acquisiti, congelati o dissolti senza che il codice smetta di funzionare — ma il supporto, la roadmap e le integrazioni spariscono.

La regola operativa che ne deriva è semplice: tratta ogni plugin commerciale come una dipendenza critica, anche se è GPL. Mappalo, tienilo d'occhio, tieni pronta un'alternativa. Le 6-10 settimane di roadmap che ti ho descritto sopra sono il prezzo da pagare per non farsi trovare impreparati.

Il tema è più ampio e lo collego a quello che ho scritto su Toolchain agenzia WordPress moderna 2026: anche il modo in cui scegli e governi la toolchain è una scelta di business risk management, non solo tecnica.

FAQ

StellarWP continuerà a rilasciare aggiornamenti dei plugin?

Sì. Il codice è GPL e resta nel repository ufficiale di WordPress.org. Patch di sicurezza e bug fix critici continueranno. Le feature nuove sono però congelate in attesa della riorganizzazione.

Le mie licenze esistenti restano valide?

Sì, almeno fino alla scadenza naturale. Il rinnovo potrebbe avere condizioni diverse. Controlla la mail di Liquid Web per la tua situazione specifica.

Devo migrare subito?

No, non c'è urgenza tecnica. La decisione di migrare va presa dopo l'audit e la stima del TCO. Hai almeno 6 mesi di tempo per ragionare.

Le donazioni passate rimangono nel mio database?

Sì. Il database resta tuo e contiene lo storico completo. Plugin come GiveWP continueranno a leggere lo storico anche se non raccoglieranno nuove donazioni. L'esportazione verso il nuovo sistema è una fase separata.

StellarPayments continuerà a funzionare?

Sì. StellarPayments è integrato in GiveWP e continua a funzionare fino a decisione contraria. La roadmap StellarPayments v2 (annunciata nel 2025) è però sospesa.

Cosa rischio se non faccio nulla?

Nel breve periodo, poco: il codice continua a funzionare. Nel medio periodo, rischi un rallentamento degli aggiornamenti di sicurezza e un progressivo decadimento delle performance del checkout. Nel lungo periodo, un cambio di proprietà o una sunset del prodotto potrebbe sorprenderti senza preavviso.

Posso usare due sistemi in parallelo per le donazioni?

Tecnicamente sì, ma non è consigliato: confonde i donatori, raddoppia il lavoro di reportistica, e complica la fiscalità. Meglio scegliere un sistema, migrare, consolidare.

Riferimenti utili per approfondire

]]> https://www.mrtux.it/stellarwp-liquidweb-dissolution-migrazione-wordpress-2026/feed 0