File Core Modificati? Come Ripristinare i File Core di WordPress in Sicurezza

Stai guardando una schermata bianca dove prima c'era la tua homepage. Forse invece è un errore 500, o un avviso di un plugin di sicurezza che ti dice che i file principali di WordPress sono stati modificati.

Ho sostituito i file principali su siti che ho rotto io stesso e su siti che si sono presentati già rotti. Qualunque cosa ti abbia portato qui, la soluzione è la stessa, ed è meno distruttiva di quanto sembri.

Ripristinare i file principali di WordPress significa scambiare i file del programma di WordPress (quelli in wp-admin, wp-includes e la tua directory principale) con copie pulite da WordPress.org. I tuoi post, pagine, media, temi, plugin e impostazioni non si spostano. Vivono da qualche altra parte.

Due cose vanno storte quando le persone ci provano da sole.

Il primo consiste nel cancellare wp-content insieme alle cartelle principali, il che trasforma una riparazione di 20 minuti in una ricostruzione completa. Il secondo consiste nell'ottenere l'ultima versione di WordPress quando il sito sta eseguendo una versione precedente, il che impone un salto di versione principale su un sito già instabile.

In questo post, ti mostrerò come confermare che i file principali sono il problema prima di cancellare qualsiasi cosa, tre modi per sostituirli e cosa fare quando la sostituzione non è la vera soluzione.

Punti chiave:

• Verifica prima di cancellare qualsiasi cosa: wp core verify-checksums risponde in un solo comando se i file principali sono il problema, e un passaggio pulito significa che sostituiresti file che non sono mai stati danneggiati.
• Abbina la tua versione invece di prendere l'ultima: installare l'ultima versione di WordPress su un sito precedente impone un aggiornamento principale non pianificato e una modifica dello schema del database su un sito già instabile.
• Hai tre opzioni: il pulsante Reinstalla versione X.X.X se riesci ad accedere, un comando WP-CLI se hai SSH e uno scambio manuale via FTP se non hai nessuno dei due.
• Cancella le cartelle principali invece di sovrascriverle: sovrascrivere lascia file aggiunti dall'attaccante all'interno di wp-admin e wp-includes perché nulla nella build ufficiale sostituisce un file che non ne fa parte.
• I file principali puliti non ripuliscono un sito hackerato: backdoor in wp-content/uploads, mu-plugin dannosi e righe di database iniettate sopravvivono, che è il punto in cui un ripristino completo batte una riparazione file per file.

Indice

Quali file sono file principali di WordPress?

Prima di cancellare qualsiasi cosa, devi sapere quali cartelle contano come file principali di WordPress e quali sono i tuoi. Sbagliare questo è l'errore più costoso dell'intero processo.

Ecco cosa conta come file principale:

• Tutto in wp-admin. Questa è la dashboard di amministrazione stessa, ogni schermata a cui accedi.
• Tutto in wp-includes. Queste sono le librerie su cui si basa WordPress. È la cartella più grande per numero di file ed è quella più probabile che venga segnalata come modificata.
• I file PHP sciolti nella tua directory principale. File come index.php, wp-login.php, wp-settings.php e wp-cron.php si trovano accanto alle tue cartelle e vengono anch'essi sostituiti.

Quali file di WordPress non dovresti sostituire?

Ecco cosa dovresti lasciare stare:

• wp-content. Contiene caricamenti specifici del sito, plugin installati, temi, mu-plugin e talvolta artefatti dell'host o di distribuzione. WordPress distribuisce una copia di questa cartella, ma la tua è unica.
• wp-config.php. Contiene le credenziali del tuo database. Sovrascrivilo e il tuo sito non riuscirà a trovare i propri contenuti.
• .htaccess. Non è un file principale, ma WordPress ci scrive. Salva una copia e lascia l'originale al suo posto.
• Qualsiasi cosa aggiunta dal tuo host o dal tuo sviluppatore. File di verifica del dominio, script personalizzati, un robots.txt modificato manualmente. Se non proviene dal download di WordPress, resta.

Cancella wp-content e non starai più ripristinando i file principali. Stai ricostruendo il tuo sito da zero.

Quando è necessario ripristinare i file principali di WordPress?

I file principali rimangono intatti per mesi. Quando si rompono, è quasi sempre per una manciata di cause. Sapere quale stai riscontrando cambia il modo in cui gestisci la pulizia in seguito.

Ecco quando la sostituzione dei file principali è la scelta giusta:

• Un aggiornamento principale è fallito a metà. La connessione è caduta, il server è andato in timeout o PHP ha raggiunto il limite di memoria. Ti ritrovi con alcuni file della vecchia versione e alcuni della nuova, e WordPress non ha modo di riconciliarli.
• Una scansione ha segnalato che i file principali di WordPress sono stati modificati. Wordfence, Sucuri e molti host gestiti confrontano i tuoi file con le versioni ufficiali di WordPress.org. Un file principale modificato significa che qualcosa ha alterato il codice che nessuno dovrebbe modificare.
• Il tuo sito è stato violato. Gli aggressori iniettano codice nei file principali perché quei file vengono caricati ad ogni singola richiesta. Sostituirli elimina il codice iniettato (non eliminerà il resto dell'infezione, a cui tornerò più tardi).
• I file si sono corrotti durante un trasferimento. Una sessione FTP interrotta o una migrazione incompleta lascia file troncati. Sembrano normali in un elenco di file e falliscono la seconda volta che PHP tenta di eseguirli.
• Uno schermo bianco o un errore 500 sono sopravvissuti alla risoluzione dei problemi di base. Se hai disabilitato ogni plugin, sei passato a un tema predefinito e l'errore non si è spostato, i file principali sono il prossimo posto dove guardare.
• Qualcuno ha modificato intenzionalmente un file principale. Questo accade più spesso di quanto si pensi. La modifica persiste finché un aggiornamento non la sovrascrive o il file smette di corrispondere a ciò che WordPress si aspetta.

C'è una situazione in cui ripristinare i file principali non ti aiuterà affatto: un plugin o un tema danneggiato. Questo processo non tocca wp-content, quindi se il vero problema è lì, farai tutto il lavoro e ti ritroverai con lo stesso errore. Il passaggio 1 ti dice come scoprirlo prima di passarci un'ora.

Cosa Ti Serve Prima di Iniziare

Ecco cosa avere pronto prima di ripristinare i file principali di WordPress:

• Un backup completo effettuato ora. Conservalo da qualche parte separato dal server che stai per modificare (raccomando Duplicator Cloud). Se stai usando Duplicator Pro, questo è ciò che trasforma un brutto pomeriggio in un ripristino con un clic.
• Accesso tramite almeno uno dei seguenti: la dashboard di WordPress, SFTP o FTP (FileZilla è gratuito e fa il suo lavoro), il File Manager del tuo host o SSH. Ne basta uno, e quello che hai decide il tuo metodo nel passaggio 4.
• Il tuo numero esatto di versione di WordPress, scritto. Se la dashboard non è disponibile, apri wp-includes/version.php tramite FTP e leggi la riga $wp_version in alto.
• Copie locali di wp-config.php e .htaccess. Scarica entrambi prima di toccare qualsiasi cosa.
• Da 15 a 30 minuti, a seconda del metodo che finirai per utilizzare.

Se il tuo sito riceve traffico reale, fallo durante un'ora tranquilla. Sarà parzialmente interrotto mentre l'upload è in corso.

Come ripristinare i file principali di WordPress

Il processo si svolge in sei passaggi. Tre di essi sono sempre uguali, e il Passaggio 4 è dove scegli un percorso in base all'accesso che hai ancora.

Ecco come ripristinare i file core di WordPress:

• Passaggio 1: Conferma che i file core sono il problema. Una scansione del checksum ti dice se stai risolvendo la cosa giusta prima di eliminare qualsiasi cosa che non puoi annullare.
• Passaggio 2: Esegui il backup del sito prima di sostituire qualsiasi cosa. Un trasferimento che si interrompe a metà può mettere giù l'intero sito, e questo è il passaggio che lo rende recuperabile.
• Passaggio 3: Abbina la versione di WordPress che stai ripristinando. Scaricare la versione sbagliata trasforma una riparazione in un aggiornamento non pianificato sopra un sito rotto.
• Passaggio 4: Sostituisci i file core. Scegli la dashboard, WP-CLI o FTP in base all'accesso che hai, ed esegui solo uno dei tre.
• Passaggio 5: Esegui l'aggiornamento del database e cancella gli avanzi. Nuovo codice contro uno schema vecchio, un file .maintenance bloccato e cache obsolete vengono letti come "è ancora rotto" quando i file sono già a posto.
• Passaggio 6: Verifica che il ripristino abbia funzionato. Un sito che si carica non è prova di nulla, e un secondo passaggio di checksum pulito lo è.

Passaggio 1: Conferma che i file principali sono il problema

Salta questo passaggio e potresti passare un'ora a sostituire file che non erano mai stati rotti. L'ho fatto. Un file core corrotto e un errore fatale di un plugin sembrano identici dal front-end.

WP-CLI risolve la questione in un comando.

WP-CLI è lo strumento a riga di comando di WordPress, e lo esegui tramite SSH (una connessione terminale al tuo server). La maggior parte degli host gestiti lo ha già installato, quindi controlla prima di presumere che sia fuori discussione.

Connettiti tramite SSH, spostati nella tua directory WordPress ed esegui:

wp core verify-checksums

WordPress.org pubblica un checksum per ogni file in ogni release, che è un'impronta digitale breve del contenuto di quel file. Il comando scarica l'elenco per la tua versione e lo confronta con quello che si trova sul tuo server.

Un'installazione pulita restituisce una singola riga di successo. Una danneggiata elenca ogni file che non riesce a verificare:

Warning: File doesn't verify against checksum: wp-includes/version.php

Error: WordPress installation doesn't verify against checksums.

Un risultato è un falso allarme degno di nota. readme.html fallisce costantemente perché gli host lo modificano o lo eliminano. Il comando rileva automaticamente la lingua della tua installazione, quindi hai bisogno solo del flag --locale (ad esempio, wp core verify-checksums --locale=de_DE) se lo indovina male.

Quindi eseguilo di nuovo con --include-root:

wp core verify-checksums --include-root

Quel flag ti avverte dei file presenti nella tua directory principale che non fanno affatto parte di WordPress. Su un sito compromesso, è spesso lì che trovi qualunque cosa abbia causato il problema in primo luogo.

Se non hai accesso SSH, hai altri tre modi per controllare:

• Esegui una scansione Wordfence. Il suo confronto dei file core fa lo stesso lavoro dall'interno della dashboard e ti mostra esattamente cosa è cambiato in ogni file.
• Usa lo strumento di integrità dei file del tuo host. La maggior parte degli host gestiti ne ha uno, solitamente sotto una scheda sicurezza o strumenti.
• Confronta manualmente. Scarica una copia fresca della tua versione di WordPress, apri il file sospetto da entrambe le copie e leggili fianco a fianco.

Ora leggi onestamente i tuoi risultati prima di andare avanti. Se i checksum risultano puliti, i tuoi file core vanno bene e il tuo problema è un plugin, un tema o il tuo database.

La sostituzione dei file core non risolverà nessuno di questi problemi.

Sei pronto per il Passo 2 quando hai in mano un elenco di file specifici che non hanno superato la verifica o un passaggio pulito che ti dice di cercare altrove.

Passaggio 2: Esegui il backup del sito prima di sostituire qualsiasi cosa

Stai per eliminare due cartelle di cui WordPress ha bisogno per funzionare. Se l'upload che le sostituisce si interrompe a metà, il tuo sito passerà da rotto a inesistente.

Questo è un problema peggiore di quello che hai ora.

Esegui un backup completo che copra sia i tuoi file che il database. Assicurati di inviare una copia in un luogo diverso dal server che stai per modificare. Una copia off-site è l'unica che sopravvive a un guasto a livello di server.

Duplicator è il mio strumento preferito per questo. Vai su Duplicator Pro » Backups e fai clic su Add New.

Scegli il preset di backup Full Site e seleziona almeno due posizioni di archiviazione (a me piace usare Local e Duplicator Cloud).

Finirai con due file: l'archivio, che contiene il tuo sito compresso e il database, e l'installer, che è lo script PHP che ripristina tutto.

Se qualcosa va storto durante il processo di ripristino dei file, ri-carica questi file sul tuo server e avvia l'installer di Duplicator.

Se non stai usando Duplicator, esegui un backup manuale. Ecco il minimo indispensabile per questo passaggio:

• Scarica wp-content, wp-config.php e .htaccess sul tuo computer tramite FTP.
• Esporta il tuo database da phpMyAdmin come file .sql.

Sei pronto per andare avanti quando sai dove si trova il tuo backup e come lo ripristineresti.

Passo 3: Abbina la Versione di WordPress che Stai Ripristinando

Ogni tutorial su questo argomento ti dice di scaricare l'ultima versione di WordPress. Questo è un buon consiglio se il tuo sito sta già eseguendo l'ultima versione. È una trappola se non lo è.

Supponiamo che tu sia due versioni principali indietro. Inserisci i file core più recenti e non hai ancora riparato nulla. Quello che hai fatto è forzare un aggiornamento di versione principale più una modifica dello schema del database su un sito instabile, nel bel mezzo di un'emergenza, senza test.

Ripristina la versione che stai utilizzando. Aggiorna più tardi, di proposito, una volta che il sito è in salute.

Ecco come trovare il tuo numero di versione:

• Dal dashboard: vai su Dashboard » Aggiornamenti. La versione che stai eseguendo è indicata in cima alla schermata.
• Via FTP: apri wp-includes/version.php e leggi la riga $wp_version in cima al file. Questo funziona quando nient'altro lo fa.
• Via SSH: esegui wp core version e stamperà il numero.

Ora, scarica quella build esatta dall'archivio delle release di WordPress invece che dalla pagina di download principale. La pagina principale serve solo la release corrente.

Il download dei file core di WordPress è un singolo file zip contenente wp-admin, wp-includes, wp-content e i file root sciolti. Corrispondi alla stringa di versione completa, non solo al numero principale. Una release point di differenza è ancora un set di file diverso.

Se stai usando la via di WP-CLI, puoi saltare completamente il download. Il comando nel Metodo 2 qui sotto legge la tua versione e scarica i file corrispondenti in un unico passaggio.

Sei pronto per il Passaggio 4 quando hai uno zip di WordPress sul tuo computer che corrisponde al tuo sito o un terminale aperto e in attesa.

Passaggio 4: Sostituisci i file principali

Questo è il passaggio in cui i file danneggiati escono e quelli puliti entrano. Ci sono tre modi per farlo, e tutti sostituiscono i file del programma di WordPress con copie verificate da WordPress.org, lasciando intatti i tuoi contenuti e le tue impostazioni.

Quale usare dipende dall'accesso che hai:

• Metodo 1: Il pulsante della dashboard. Usalo se riesci ancora ad accedere a WordPress. È il più veloce con ampio margine.
• Metodo 2: WP-CLI. Usalo se hai SSH. È il più preciso, ed è l'unico che fissa la tua versione nello stesso comando.
• Metodo 3: FTP manuale. Usalo quando non hai nessuno dei due. Funziona su qualsiasi host e ha più modi per andare storto.

Metodo 1: Usa il pulsante Reinstalla nella Bacheca

Se wp-admin si carica ancora, inizia da qui. È il modo più veloce per reinstallare il core di WordPress e non dovrai toccare una singola cartella.

Vai su Dashboard » Aggiornamenti. Quando sei già alla versione corrente, WordPress lo dice e offre di reinstallare quella versione per te, con un pulsante Reinstalla versione X.X.X.

Cliccalo. WordPress scaricherà l'aggiornamento, decomprimerà l'aggiornamento del core, verificherà i file decompressi, installerà l'ultima versione e aggiornerà il database. Si conclude con un messaggio di successo nella stessa schermata.

Conosci una limitazione prima di iniziare. Questo reinstalla la versione che WordPress ritiene tu debba avere, quindi non può farti tornare indietro. Se un aggiornamento errato è ciò che ha rotto il tuo sito, questo pulsante non lo annullerà.

Sovrascrive anche i file invece di eliminare le cartelle, e così fa il Metodo 2. Qualsiasi cosa un attaccante abbia aggiunto all'interno di wp-admin o wp-includes rimane al suo posto. Se stai ripulendo un hack, usa il Metodo 3, o conferma in seguito con un controllo dei checksum che non sia rimasto nulla di extra.

Alcuni host interrompono il processo con una finestra di dialogo Informazioni di connessione che richiede le credenziali FTP. Questo è un problema di proprietà dei file e la sezione di risoluzione dei problemi qui sotto copre la soluzione.

Metodo 2: Usa WP-CLI

WP-CLI è quello che uso ogni volta che ho accesso al terminale. Connettiti tramite SSH, spostati nella tua directory di WordPress ed esegui:

wp core download --version=$(wp core version) --force --skip-content

Ecco cosa fa ogni pezzo:

• --version=$(wp core version) legge la versione che il tuo sito sta eseguendo e scarica quella release esatta.
• --force sovrascrive i file esistenti. Senza di esso, WP-CLI si rifiuta di toccare una directory che contiene già WordPress.
• --skip-content lascia wp-content fuori dal download, in modo che i tuoi temi, plugin e upload non vengano mai toccati dalla sovrascrittura.

Non usare wp core install qui, anche se il nome sembra giusto. Quel comando esegue la routine di installazione di WordPress su un sito nuovo di zecca, ed è lo strumento sbagliato per un sito che esiste già.

Prima di premere invio, sappi che --force non chiede conferma. Se qualcuno ha modificato deliberatamente un file core di questo sito, tale modifica scompare nel momento in cui il comando viene eseguito. Di solito è questo lo scopo, ma verifica con chiunque abbia creato il sito se non sei sicuro.

Quindi conferma il risultato:

wp core verify-checksums

Un passaggio pulito significa che la metà del problema relativa ai file è risolta.

Metodo 3: Sostituisci i file manualmente tramite FTP

Quando non riesci ad accedere alla bacheca e non hai accesso SSH, svolgi lo stesso lavoro manualmente: rimuovi le due cartelle core dal server e inserisci quelle nuove al loro posto.

Nessuna delle singole operazioni è difficile. La sequenza è ciò che protegge i file che devi conservare, quindi vale la pena seguirla in ordine.

1. Disattiva i tuoi plugin se riesci ancora ad accedere alla bacheca. Saltala se non ci riesci. Questa è una precauzione, non un requisito.
2. Decomprimi il download di WordPress sul tuo computer. Vedrai wp-admin, wp-includes, wp-content e una manciata di file sparsi.
3. Elimina wp-admin e wp-includes sul server. Entrambe le cartelle, completamente. Lascia tutto il resto esattamente dov'è.
4. Carica i nuovi wp-admin e wp-includes dalla tua copia decompressa nella stessa posizione.
5. Carica i file root sparsi dalla nuova build e sovrascrivi quelli vecchi. Non eliminare prima la tua cartella root. Con essa elimineresti anche wp-config.php e .htaccess.
6. Copia i file dall'interno del nuovo wp-content nel tuo wp-content esistente. Copia al suo interno. Non sostituirlo mai.
7. Conferma che wp-config.php e .htaccess siano ancora nella tua root. Se uno dei due manca, carica la copia che hai salvato in precedenza.

Il passaggio 3 di quell'elenco è dove le persone esitano, perché eliminare sembra più rischioso che sovrascrivere. È il contrario.

Sovrascrivere sostituisce solo i file che esistono in entrambe le copie. Qualsiasi cosa un aggressore abbia inserito in wp-admin o wp-includes non fa parte della build ufficiale, quindi nulla la sovrascrive e passa attraverso l'intera pulizia intatta. Eliminare prima le cartelle è ciò che rende questa una vera soluzione piuttosto che una cosmetica.

Stabilisci anche le tue aspettative sui tempi. wp-includes da solo contiene più di mille file e FTP li sposta uno alla volta. Venti minuti sono normali con una connessione lenta e possono verificarsi trasferimenti interrotti.

Se il caricamento continua a fallire, invia lo zip al tuo server come un unico file ed estrailo lì con il File Manager del tuo host. Un unico grande trasferimento è molto più affidabile di mille piccoli.

Hai completato questo passaggio quando la struttura delle tue cartelle corrisponde alla copia nuova, wp-config.php è intatto e il sito si carica, anche se ti saluta con una richiesta di aggiornamento del database.

Passaggio 5: Esegui l'aggiornamento del database e cancella i residui

I tuoi file ora sono puliti, ma WordPress potrebbe essere ancora nello stato in cui l'aggiornamento fallito lo ha lasciato. Tre piccole pulizie completano il lavoro.

Inizia visitando /wp-admin. Potrebbe esserti richiesto di accedere di nuovo, il che è normale.

Se WordPress rileva che il tuo database ha bisogno di mettersi al passo con il codice, mostra una schermata Database Update Required con un pulsante Update WordPress Database. Fai clic su di esso e lascialo eseguire.

Fai questo subito, perché finché non lo fai, il tuo sito sta eseguendo nuovo codice contro uno schema vecchio.

Successivamente, cerca nel tuo file system principale un file chiamato .maintenance e cancellalo se è presente. WordPress crea quel file all'inizio di un aggiornamento e lo rimuove al completamento dell'aggiornamento. Quando un aggiornamento fallisce a metà, il file rimane indietro e i visitatori vedono il messaggio di manutenzione.

È un file nascosto, quindi non apparirà nell'elenco dei file finché non attivi la visualizzazione dei file nascosti. In FileZilla, è Server » Forza visualizzazione file nascosti, e nella maggior parte dei file manager degli host, è una casella di controllo Mostra file nascosti nelle impostazioni.

Quindi cancella ogni cache che hai: il tuo plugin di caching, la cache del server del tuo host, la tua CDN e il tuo browser. Se salti questo passaggio, potresti passare 20 minuti a fare il debug di una pagina che è già stata corretta.

Riattiva i tuoi plugin se li hai disattivati durante il Metodo 3.

Hai finito qui quando il dashboard si carica, il prompt di aggiornamento è scomparso e il tuo front-end viene visualizzato correttamente.

Passaggio 6: Verifica che il ripristino sia andato a buon fine

Un sito che si carica non è la stessa cosa di un sito che è stato riparato. Prima di chiudere la scheda, esegui questo elenco.

Ecco cosa controllare:

• Esegui di nuovo wp core verify-checksums. Un passaggio pulito è l'unica prova definitiva che i tuoi file core corrispondono alla release ufficiale.
• Carica il tuo front-end disconnesso in una finestra di navigazione privata. Le visualizzazioni con accesso effettuato nascondono problemi di caching ed errori di autorizzazione.
• Fai clic sulle pagine che contano. La tua homepage, un singolo post, un archivio di categoria, la schermata di accesso e qualsiasi modulo o checkout da cui dipendi.
• Salva di nuovo i tuoi permalink. Vai su Impostazioni » Permalink e fai clic su Salva modifiche senza cambiare nulla. Questo rigenera le tue regole di riscrittura, che è il motivo usuale per cui i post iniziano a restituire 404 dopo uno scambio di file.
• Conferma i tuoi URL. Sotto Impostazioni » Generali, verifica che Indirizzo WordPress (URL) e Indirizzo sito (URL) corrispondano esattamente a ciò che erano prima.
• Leggi il tuo log degli errori. Qualsiasi cosa nuova lì dentro vale la pena di essere affrontata ora, mentre ricordi ancora cosa hai cambiato.

Quindi fai un altro backup. Il tuo sito si trova in uno stato noto e funzionante in questo preciso momento, che è lo stato che vale la pena catturare, ed è una copia molto più utile da conservare rispetto a quella di emergenza che hai fatto al Passo 2.

E se la sostituzione dei file core non risolve il problema?

A volte esegui tutti i passaggi, i checksum tornano puliti e il sito è ancora errato. Quando ciò accade, i file core danneggiati erano un sintomo piuttosto che la causa.

Tre scenari spiegano la maggior parte di questi casi:

• Il sito è stato violato. La sostituzione dei file principali rimuove il codice iniettato dai file principali e nient'altro. Un backdoor in wp-content/uploads, un file functions modificato del tema o qualcosa nascosto in mu-plugins sopravvivono tutti. L'indicatore più chiaro sono i file PHP che si trovano nella cartella di caricamenti, dove dovrebbero esserci solo file multimediali.
• Anche il database ha subito danni. I tuoi file vanno bene e il tuo contenuto no. Link di spam iniettati nella tabella dei post, un sito riscritto nella tabella delle opzioni e account di amministrazione non familiari sopravvivono tutti a un ripristino principale.
• I checksum passano e il sito continua a dare errori. Ciò indica un plugin, un tema o una mancata corrispondenza della versione PHP. Il passaggio 1 ti ha indirizzato nella giusta direzione; i file principali non sono mai stati il problema.

In tutti e tre i casi, ripristinare l'intero sito da un backup di cui ti fidi è meglio che analizzarlo file per file. Smetti di indovinare cosa è pulito.

In Duplicator Pro, trova un backup precedente all'inizio del problema e ripristinalo.

Se quel backup si trova in Google Drive, Dropbox o un'altra posizione di archiviazione connessa, puoi ripristinarlo direttamente da WordPress senza dover prima scaricare e ricaricare l'archivio.

Se WordPress non si carica affatto, ricarica il backup che hai utilizzato nella tua directory principale. Avvia l'installer di Duplicator con un URL come: https://tuo-dominio/installer.php

Un ripristino riporta il tuo sito al momento in cui è stato creato quel backup, quindi tutto ciò che è stato pubblicato o ordinato da allora viene perso. Su un sito compromesso, questa è solitamente la scelta giusta, perché una pulizia parziale che manca un backdoor ti riporta qui entro una settimana.

Duplicator non esegue la scansione o la rimozione di malware. Ti fornisce una copia pulita di un sito che funzionava. Abbinalo a uno scanner di sicurezza se hai a che fare con un'infezione attiva.

Per il percorso manuale, Come ripristinare manualmente il tuo sito WordPress copre il ripristino di file e database manualmente, e Come ripristinare un sito web con solo un backup del database copre cosa fare quando il database è tutto ciò che ti rimane.

Risoluzione dei problemi: Errori comuni dopo il ripristino dei file principali

Questi sono i fallimenti che si verificano più spesso dopo uno scambio di file principali. Lavora in base al sintomo che stai osservando.

Perché il mio sito mostra "Brevemente non disponibile per manutenzione programmata"?

Ottieni una pagina bianca semplice con una singola riga di testo, e non scompare.

WordPress scrive un file chiamato .maintenance nella tua directory principale quando inizia un aggiornamento e lo elimina quando l'aggiornamento finisce. Se l'aggiornamento è fallito nel mezzo, quel file è ancora lì, e WordPress non ha modo di sapere che il lavoro non è mai stato completato. WordPress smette di considerare il file dopo 10 minuti, ma un aggiornamento fallito può lasciare il tuo sito parzialmente aggiornato nel frattempo.

Elimina .maintenance dalla tua directory principale tramite FTP con i file nascosti attivati. Tramite SSH, wp maintenance-mode deactivate fa la stessa cosa. Il tuo sito ritorna nel momento in cui il file viene eliminato.

Perché mi vengono richieste le informazioni di connessione FTP?

Fai clic su Reinstalla versione X.X.X e WordPress aprirà una finestra di dialogo Informazioni sulla connessione che richiede hostname, nome utente e password. Questo è un problema di proprietà dei file.

WordPress scrive i file direttamente solo quando appartengono allo stesso utente con cui è in esecuzione il server web. Quando non è così, richiede le credenziali FTP in modo da poterli scrivere in un altro modo.

Inserisci le credenziali per l'account FTP proprietario dei tuoi file WordPress, e continuerà. Se non le hai, chiedi al tuo host di correggere la proprietà, che è la vera soluzione.

Troverai anche consigli online sull'aggiunta di define('FS_METHOD', 'direct'); a wp-config.php. A volte funziona, ma aggira il sintomo e può fallire in seguito in modi più difficili da diagnosticare rispetto alla finestra di dialogo.

Perché ottengo una schermata bianca dopo aver sostituito i file principali?

Non viene caricato nulla, né il front-end né l'admin, e non ci sono messaggi di errore da cui partire. Tre cause coprono quasi tutti questi casi: un trasferimento FTP terminato in modo incompleto, permessi dei file errati durante l'upload o un errore fatale PHP che viene soppresso.

Ricarica prima wp-includes, poiché è la cartella più grande e quella che più probabilmente ha perso file. Quindi controlla i tuoi permessi, che dovrebbero essere 644 per i file e 755 per le cartelle.

Se lo schermo è ancora bianco, aggiungi define('WP_DEBUG', true); e define('WP_DEBUG_LOG', true); a wp-config.php e leggi wp-content/debug.log. Questo trasforma una schermata bianca in un nome di file e un numero di riga.

Perché i checksum falliscono ancora dopo una reinstallazione pulita?

Hai sostituito tutto e wp core verify-checksums sta ancora generando avvisi. Di solito sono tre cose: readme.html viene segnalato perché il tuo host lo modifica o lo rimuove, il comando ha scelto la lingua sbagliata per la tua installazione, o qualcosa in quelle cartelle non appartiene veramente lì.

Se ogni file viene segnalato, riesegui con la tua locale (wp core verify-checksums --locale=fr_FR, ad esempio) e vedi cosa rimane. Un avviso "Il file non dovrebbe esistere" significa che qualcosa di extra si trova all'interno di una cartella core e la sovrascrittura non lo rimuoverà. Elimina outright wp-admin e wp-includes e carica nuove copie, che è la differenza che fa il Metodo 3.

Perché WordPress dice che un aggiornamento è già in corso?

Provi a reinstallare e ti viene detto "Un altro aggiornamento è attualmente in corso". WordPress imposta un blocco nella tua tabella delle opzioni quando inizia un aggiornamento del core, quindi due aggiornamenti non possono essere eseguiti contemporaneamente. Un aggiornamento interrotto lascia quel blocco senza nulla per rimuoverlo.

Il blocco scade da solo dopo 15 minuti, quindi aspettare non ti costa nulla se non tempo. Per rimuoverlo ora, esegui wp option delete core_updater.lock, oppure apri la tua tabella delle opzioni in phpMyAdmin, trova la riga core_updater.lock ed eliminala.

Non funziona niente: cosa fare ora?

Hai seguito la lista e il sito è ancora offline. A questo punto, smetti di riparare e inizia a ripristinare.

Torna al backup che hai effettuato nel Passaggio 2. Se riesci ancora ad accedere alla dashboard, esegui un ripristino con un clic da Duplicator Pro » Backups. Se non ci riesci, ricarica l'archivio e l'installer nella tua directory principale e avvia l'installer nel browser, che funziona senza un'installazione di WordPress funzionante dietro di esso.

Se non hai un backup, contatta il tuo host e chiedi uno snapshot lato server. La maggior parte degli host conserva backup giornalieri su una finestra mobile anche sui piani condivisi, e il supporto può ripristinarne uno per te.

Domande frequenti (FAQ)

I file principali puliti sono la base: ecco cosa fare dopo

Hai sostituito i file del programma di WordPress con copie verificate e li hai confermati con un controllo del checksum. Quel controllo è più importante del semplice caricamento del sito. Un sito può caricarsi perfettamente anche con un file principale modificato che esegue silenziosamente il codice di qualcun altro ad ogni richiesta, motivo per cui il passaggio diagnostico è venuto prima di tutto il resto.

Tre abitudini ti evitano questo da ora in poi.

• Pianifica i tuoi backup invece di farli quando ti ricordi.
• Esegui un nuovo backup dopo ogni aggiornamento riuscito, in modo che il tuo stato più recente e funzionante sia sempre a portata di ripristino.
• Esegui wp core verify-checksums come controllo mensile di routine piuttosto che come misura di emergenza, perché un file principale modificato che scopri durante un controllo di integrità è un problema molto più piccolo di uno che scopri quando il sito va in crash.

Un'altra cosa che vale la pena fare mentre sei già in wp-config.php. Aggiungi define('DISALLOW_FILE_EDIT', true); per disattivare gli editor di temi e plugin integrati, il che chiude il percorso più facile per chiunque abbia accesso amministrativo per modificare un file dall'interno della dashboard. Quindi aggiungi un piccolo file .htaccess in wp-content/uploads che impedisca l'esecuzione di PHP lì:

<Files *.php>

Require all denied

</Files>

Quest'ultima è la sintassi di Apache 2.4, quindi su nginx vorrai il blocco di posizione equivalente nella configurazione del tuo server. Insieme chiudono le due porte che mettono la maggior parte delle persone in questa situazione all'inizio, e nessuna delle due richiede più di un minuto.

Smetti di riparare i siti WordPress a mano

Sostituire manualmente i file principali funziona. Ti costa anche un pomeriggio e aiuta solo se cogli il problema prima che si diffonda. Un backup recente e un ripristino con un clic trasformano quella lunga sessione di debug in due minuti.

Duplicator Pro è ciò su cui fanno affidamento oltre 1,5 milioni di utenti attivi per backup pianificati, ripristini con un clic direttamente dallo spazio di archiviazione cloud e un URL di ripristino di emergenza che funziona ancora quando WordPress non si carica. Ogni piano a pagamento include un rimborso di 14 giorni senza domande.

Se questo tutorial ti è stato utile, anche queste guide meritano di essere aggiunte ai preferiti.

• Come ripristinare WordPress da un backup (In meno di 5 minuti)
• Come ripristinare manualmente il tuo sito WordPress
• Come ripristinare un sito Web con un backup del solo database
• Come eseguire il downgrade della tua versione di WordPress e ripristinare aggiornamenti errati
• Come ripristinare il tuo sito WordPress da un backup di Google Cloud
• Come ripristinare un sito WordPress a una data precedente senza backup