WordPress: un altro aggiornamento è in corso

Questa guida approfondisce WordPress un altro aggiornamento è in corso con verifiche progressive e reversibili. Non inviare password, cookie, token, chiavi private, codici 2FA o file di configurazione completi nei ticket.

Che cosa significa

Il lock protegge l’integrità dei file. Rimuoverlo mentre un processo di aggiornamento è ancora attivo può avviare due sostituzioni concorrenti.

Prima di intervenire bisogna verificare processi PHP, cron, log, modalità manutenzione e data dell’ultimo tentativo. Spesso attendere alcuni minuti è sufficiente.

Come riconoscere il problema

• La pagina Aggiornamenti mostra il messaggio.
• Il core non può essere aggiornato ma plugin e temi sì.
• L’errore appare subito dopo un timeout.
• Nel database esiste l’opzione core_updater.lock.
• Il sito può essere ancora in modalità manutenzione.

Cause più frequenti

1. Aggiornamento realmente attivo

Un processo sta ancora scaricando o copiando file. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla schermata mostrata dal client.

2. Processo interrotto

Il lock non è stato rimosso. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla schermata mostrata dal client.

3. Cron o update automatico

Un task in background è partito nello stesso momento. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla schermata mostrata dal client.

4. Risorse lente

L’operazione richiede più tempo del previsto. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla schermata mostrata dal client.

5. Database o cache oggetti

Il lock persiste o viene letto da cache. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla schermata mostrata dal client.

6. Tentativi simultanei

Più amministratori avviano l’update. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla schermata mostrata dal client.

Diagnosi passo per passo

1. Attendi il tempo di scadenza. Non intervenire immediatamente. Salva il risultato prima di passare al controllo successivo, così potrai individuare il punto preciso nel quale il comportamento cambia.
2. Controlla processi e log. Cerca update attivo, timeout e fatal error. Salva il risultato prima di passare al controllo successivo, così potrai individuare il punto preciso nel quale il comportamento cambia.
3. Verifica `.maintenance`. Individua una operazione incompleta. Salva il risultato prima di passare al controllo successivo, così potrai individuare il punto preciso nel quale il comportamento cambia.
4. Leggi l’opzione senza modificarla. Usa WP-CLI `option get core_updater.lock`. Salva il risultato prima di passare al controllo successivo, così potrai individuare il punto preciso nel quale il comportamento cambia.
5. Controlla cron e aggiornamenti automatici. Evita sovrapposizioni. Salva il risultato prima di passare al controllo successivo, così potrai individuare il punto preciso nel quale il comportamento cambia.
6. Verifica spazio e permessi. Cause frequenti di update interrotto. Salva il risultato prima di passare al controllo successivo, così potrai individuare il punto preciso nel quale il comportamento cambia.
7. Crea backup. Prima di rimuovere un lock orfano. Salva il risultato prima di passare al controllo successivo, così potrai individuare il punto preciso nel quale il comportamento cambia.

Metodo sicuro di diagnosi

Prima di modificare la configurazione, registra URL o servizio coinvolto, messaggio completo, data e ora, ultima modifica nota, client o rete e risultato ottenuto con un secondo strumento. Questa fotografia iniziale permette di confrontare i test e di tornare alla configurazione precedente quando una modifica non produce il risultato atteso.

Applica una sola correzione alla volta. Dopo ogni intervento ripeti esattamente la stessa operazione e controlla i log dello stesso intervallo temporale. Modificare contemporaneamente DNS, cache, PHP, plugin, proxy e firewall elimina la possibilità di attribuire il risultato a una causa precisa.

Controllo incrociato

Usa almeno due fonti indipendenti. Per HTTP confronta browser, curl e log; per WordPress confronta frontend, wp-admin, Site Health e WP-CLI; per DNS interroga nameserver autoritativi e resolver pubblici; per la posta confronta Webmail, intestazioni originali e Track Delivery. Cache, TTL e code possono mostrare stati differenti per alcuni minuti.

Quando il problema sembra risolto, esegui una seconda prova con una nuova sessione, un secondo utente o una seconda rete quando applicabile. Verifica inoltre che TLS, autenticazione, WAF, permessi e controlli antispam restino attivi: una correzione che disabilita stabilmente le protezioni non è una soluzione definitiva.

Verifica prolungata dopo la correzione

Conserva temporaneamente backup, valori precedenti ed estratti dei log. Ripeti il controllo dopo il normale ciclo di cache, cron, coda o TTL. Se l’anomalia ricompare a intervalli regolari, confronta l’orario con backup, aggiornamenti, rinnovi SSL, rotazioni DNS, processi pianificati e servizi esterni.

Documenta il risultato finale con data, comando o schermata utilizzata e condizione verificata. Questa nota evita interventi duplicati e rende più rapida una futura analisi da parte dell’assistenza.

Procedura di risoluzione

1. Attendi e ricarica. Il lock normale viene eliminato o scade. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
2. Completa o interrompi in sicurezza il processo. Non avviare un secondo update. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
3. Rimuovi il lock solo se orfano. Usa WP-CLI o database dopo la verifica. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
4. Rimuovi `.maintenance` se l’update è terminato. Poi controlla integrità dei file. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
5. Correggi spazio e permessi. Prima di ritentare. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
6. Aggiorna una sola volta. Coordina amministratori e automazioni. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
7. Verifica versione e checksum. Conferma che il core sia completo. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.

Come raccogliere prove utili

Quando riproduci il problema, conserva soltanto i dati tecnici necessari: codice di risposta, URL priva di token, orario con fuso, request ID, nome del client, dimensione del file o del messaggio e una breve descrizione dell’operazione. Evita screenshot parziali quando puoi esportare il testo originale, perché header, log e messaggi completi permettono una diagnosi più precisa.

Prima di chiudere il controllo, confronta il comportamento con una configurazione nota e funzionante. Per una API usa un payload minimo; per WordPress prova una funzione core senza plugin aggiuntivi; per DNS interroga direttamente i nameserver; per la posta usa Webmail e conserva il file `.eml`. Questo confronto riduce le ipotesi e impedisce modifiche inutili.

Controlli finali

• Nessun lock orfano.
• Core aggiornato.
• Modalità manutenzione disattiva.
• Checksum coerenti.
• Nessun update concorrente.

Prevenzione

• Aggiornamenti coordinati.
• Backup.
• Spazio libero.
• Cron monitorato.
• Staging.

Errori da evitare

• Non cancellare il lock immediatamente.
• Non avviare update simultanei.
• Non modificare opzioni senza backup.
• Non ignorare `.maintenance`.
• Non sovrascrivere il core con pacchetti non ufficiali.

Quando contattare l’assistenza Xlogic

Apri un ticket quando il problema persiste dopo i controlli di base, coinvolge più servizi oppure richiede log e configurazioni non disponibili nel pannello. Indica:

• versione WordPress
• orario tentativo
• valore lock
• log
• processi o cron

Non inviare credenziali. URL, orari, codici, header non sensibili e messaggi di errore sono sufficienti per iniziare la diagnosi.

Fonti tecniche ufficiali

• WordPress Core_Upgrader
• WordPress Updating WordPress

Domande frequenti su WordPress un altro aggiornamento è in corso