Come risolvere i crash di accesso a WordPress (2026): Otto fallimenti e l'ordine di escluderli - IT

WordPress ne stampa due diversi “i cookie sono bloccati” errori nella schermata di accesso. Uno significa che il tuo browser ha rifiutato un cookie. L'altro significa che il tuo server ha stampato qualcosa prima che WordPress potesse impostarne uno. Si trovano a undici righe di distanza nello stesso file principale. Hanno bisogno di riparazioni opposte, e quasi ogni guida li tratta come un errore. Quindi la prima mossa non è svuotare la cache. Sta leggendo la frase sul tuo schermo, parola per parola.

Risposta rapida: Abbina il testo esatto dell'errore alla correzione. “I cookie sono bloccati o non supportati dal tuo browser” è il tuo browser, quindi riprova in una finestra privata. “I cookie sono bloccati a causa di un output imprevisto” è il tuo server, quindi rinomina il plugins cartella su FTP. Una pagina bianca, o “Si è verificato un errore critico su questo sito web”, non è nessuno dei due. Controlla se nella casella di posta dell'amministratore è presente un'e-mail in modalità ripristino di WordPress prima di toccare un file. Tornare al modulo di accesso senza alcun errore di solito significa che l'URL del tuo sito è cambiato.

Ultima revisione: settembre 2026. Stringhe di errore, le costanti dei cookie e il comportamento di hashing delle password sono stati letti dal sorgente principale di WordPress in poi 8 settembre 2026. Versioni dei plugin, i conteggi delle installazioni e le date di rilascio provengono dall'API del plugin WordPress.org e dai tag SVN lo stesso giorno.

cancellare l'immagine dei dati di navigazione

I file da cui provengono queste risposte

Le guide di accesso si copiano a vicenda, e le copie vanno alla deriva. Questo è stato costruito leggendo il codice che produce gli errori. Quattro file principali sono stati estratti dal ramo master di WordPress in poi 8 settembre 2026:

  • wp-login.php per le stringhe di errore esatte e le condizioni che le attivano
  • pluggable.php per sapere come vengono controllate le password e come vengono impostati i cookie di accesso
  • costanti-default.php per i nomi dei cookie e le impostazioni predefinite della memoria
  • utente.php per la scadenza della chiave di ripristino e il rehash eseguito dopo un accesso riuscito

Ogni comportamento descritto di seguito riconduce a uno di questi quattro. I dati sui plugin provengono dall'API delle informazioni sui plugin di WordPress.org. Le date di rilascio provenivano dalle intestazioni dei tag SVN anziché dai post del blog del fornitore. Un post sul blog annuncia una versione; un'intestazione del tag registra il momento della spedizione.

Due regole decidevano cosa entrare. Qualsiasi correzione esistente solo all'interno del pannello di controllo di un host è stata tralasciata, poiché non aiuta un lettore su un host diverso. Anche qualsiasi trucco che non potesse essere ricondotto a una linea di origine core o plugin è stato escluso, tuttavia spesso appare altrove.

Cosa non ha fatto questa guida: eseguire questi errori su un sito live in crash. Niente qui è un registro di riparazione pratico. Il divario più grande è la configurazione del server. Gli host eseguono le proprie regole firewall davanti a WordPress. Dall'esterno, non puoi verificare quali richieste vengono bloccate da un host prima ancora che PHP venga caricato. Quella sezione nomina il sintomo e ti dice cosa chiedere al tuo host, questo è quanto arrivano alle prove.

Inizia con ciò che dice lo schermo

Otto cose comunemente interrompono gli accessi a WordPress. Lo schermo di solito ti dice quale, se lo leggi prima di cercare una soluzione.

  • Un errore che menziona i cookie, e sei ancora nel modulo di accesso: la formulazione divide questo problema in due diversi problemi. Errori dei cookie.
  • Nessun errore, la pagina si ricarica o ti rimbalza tra wp-login.php e wp-admin: il ciclo di accesso.
  • Una pagina bianca vuota, o “Si è verificato un errore critico su questo sito web”: errore fatale.
  • A lockout or 2FA prompt you can’t get past: blocco del plug-in.
  • UN 404 su /wp-admin o su /wp-login.php: the login page moved.
  • No reset email, o “il nome utente non è registrato”: resettalo tu stesso.
  • UN 403, 503 or timeout prima ancora che il modulo venga caricato: il server, non WordPress.
  • Manca il tuo account amministratore, oppure c'è un utente che non hai creato: non un bug.

I due errori dei cookie che significano cose opposte

Ecco la parte che decide la tua prossima ora. Dopo aver inviato il modulo, core controlla se il cookie di accesso è tornato. If it didn’t, WordPress sceglie uno dei due messaggi in base a un singolo test: headers_sent().

PHP aveva già inviato l'output quando WordPress ha provato a impostare il cookie? Allora ottieni “I cookie sono bloccati a causa di un risultato inaspettato“. Si tratta di un errore lato server, e il tuo browser è innocente. Qualcosa nel tuo codice ha stampato i caratteri prima che le intestazioni HTTP finissero. In pratica è una delle tre cose. Una riga vuota dopo la chiusura ?> nel file Functions.php di un tema. Uno spazio vagante nella parte superiore di un file plugin. O un contrassegno dell'ordine dei byte UTF-8, salvato da un editore che non ha mai chiesto.

Cancellare i cookie non fa nulla qui. Devi trovare il file che parla troppo presto. Rinominare /contenuto wp/plugin per plugin disattivati su FTP e ricaricare la pagina di accesso. Se l'errore viene cancellato, rinominare nuovamente la cartella e disabilitare i plugin uno alla volta finché non ritorna.

Se le intestazioni non fossero state inviate e il cookie di prova semplicemente non fosse mai tornato, hai capito “I cookie sono bloccati o non supportato dal tuo browser“. Quello è davvero il tuo browser, o qualcosa che si trova tra te e il sito. Prova prima una finestra privata. Una finestra privata inizia senza alcun cookie e richiede dieci secondi. Se funziona, cancella i cookie per quel dominio nel tuo profilo normale e il gioco è fatto. In caso contrario, guarda le estensioni del browser, una VPN, o il filtraggio della rete nel tuo ufficio.

La distinzione conta più di quanto sembri. L'errore lato browser viene corretto in meno di un minuto senza alcun accesso ai file. L'errore lato server richiede FTP o SSH e una ricerca nei file del plugin, e la cancellazione della cache non lo sposterà mai. Leggere otto parole ti evita di fare il secondo lavoro quando avevi bisogno del primo.

Utilizzare questa sezione quando la parola “biscotti” appare ovunque sullo schermo. Se non è presente alcun testo di errore, you want the login loop anziché.

Il ciclo di accesso: Il nome del tuo cookie è un hash dell'URL del tuo sito

Digiti la password giusta, the page reloads, e torni al modulo di accesso senza nulla da leggere. Nessun errore, no lockout, no clue. Il meccanismo dietro questo è una linea centrale, e una volta visto, la soluzione è ovvia.

WordPress non assegna al tuo cookie di accesso un nome fisso. Costruisce il nome da una costante chiamata COOKIEHASH, and COOKIEHASH is md5 dell'opzione URL del tuo sito. The auth cookie becomes wordpress_ plus that hash. The logged-in cookie becomes wordpress_logged_in_ plus the same hash. So the moment your siteurl changes, WordPress starts looking for a cookie with a different name than the one already in your browser. It finds nothing, decides you aren’t logged in, and sends you back to the form. Per sempre.

Four changes trigger this, and all four look harmless at the time:

  • Switching from http to https
  • Adding or dropping the www
  • Moving the site to a new domain
  • Adding a trailing slash to one of the two URL fields

WordPress stores siteurl e casa in the wp_options table. They need to match each other exactly, character for character. You can’t fix that in the dashboard, because you can’t get into the dashboard. Force the values in wp-config.php instead, just above the “interrompere la modifica” comment:

  • definire( ‘WP_HOME’, 'Https://example.com’ );
  • definire( 'WP_SITEURL', 'Https://example.com’ );

Pick the exact scheme and host you actually serve. These constants override the database rows without changing them, so they’re safe to try and trivial to undo. They also reach further than most guides admit. Core filters them into the siteurl option before it builds COOKIEHASH, so the constant fixes the cookie name too, not just the redirects. A trailing slash on the constant is harmless, because core strips it. A trailing slash in the database row is not.

Expect one side effect. Changing that value changes the cookie name for everybody, so every logged-in user gets signed out. That’s the fix working, not a second problem. I nostri guide to editing wp-config.php safely covers where the file sits and what else belongs in it. Once you’re back in, set Settings > General to match, quindi elimina le due righe.

Vale la pena verificare altre due cause di loop se gli URL corrispondono già. Un .htaccess danneggiato può riscrivere le richieste wp-admin in una cerchia. Rinominarlo in .htaccess-vecchio e riprovare; se il login funziona, WordPress ne scrive uno pulito quando salvi nuovamente i tuoi permalink. I siti dietro un proxy inverso o CDN hanno una seconda trappola. FORCE_SSL_ADMIN ti fa rimbalzare tra http e https quando il proxy non passa l'intestazione del protocollo.

Un sintomo assomiglia al loop ma non lo è: accedendo correttamente, per poi essere espulso di nuovo un'ora dopo. WordPress imposta il cookie di autenticazione su 2 giorni, o 14 giorni in cui spunti “Ricordati di me”. Le sessioni più brevi puntano a un plug-in di sicurezza o a una cache degli oggetti, non in caso di mancata corrispondenza dell'URL. Vale la pena sapere in quale ti trovi, perché il divario di prezzo è reale. This fix is two lines in wp-config.php. The unexpected-output error costs you an FTP session and a plugin-by-plugin hunt.

This is your section if the loop began after a domain, SSL or URL change. Been on the same URL for a year, and the loop started after a plugin update? Un plugin is the likelier culprit.

Blank Page or “There Has Been a Critical Error”

Start with the good news, because a lot of people don’t know this exists. Da WordPress 5.2, a fatal error doesn’t just white-screen you. Core catches it, emails the site’s admin address, and that email carries a secret link into recovery mode. Click it and WordPress pauses the plugin or theme that crashed, for your browser only, and lets you into the dashboard to remove it. Visitors keep seeing the error page while you work. It’s the fastest fix on this list, and it needs no FTP at all.

So check that inbox before anything else, spam folder included. Two things break this for a lot of sites. The admin address is a mailbox nobody reads. Or the site can’t send mail in the first place. You can point future alerts somewhere better with definire( ‘RECOVERY_MODE_EMAIL’, ‘[email protected]’ ); in wp-config.php, though that only helps for the next crash. If no email ever arrives from your site, the real problem is deliverability. La nostra ripartizione di why WordPress stops sending email covers the nine causes behind it.

Nessuna e-mail, no recovery link? Then find out what actually crashed. Inserisci definire( ‘WP_DEBUG’, vero ); e definire( ‘WP_DEBUG_LOG’, vero ); to wp-config.php, reload the login page, and read /wp-content/debug.log. The last few lines will name a file, and that file’s folder is your culprit. Rinomina la cartella del plugin su FTP e WordPress la disattiverà al caricamento successivo.

Se il log punta alla memoria anziché a un plugin, i numeri sono inferiori a quanto si pensa. WordPress imposta WP_MEMORY_LIMIT su 40M per impostazione predefinita, o 64M su multisito, e aumenta il lato amministrativo a 256M. Uno stack di plugin pesante può esaurire 40 milioni solo sulla richiesta di accesso. Aggiunta definire( ‘WP_MEMORY_LIMIT’, ‘256M’ ); è un test legittimo. Tratta il risultato come una diagnosi piuttosto che come una cura, perché qualcosa sta utilizzando molto più di quanto dovrebbe.

Un consiglio popolare da ignorare. Le guide consigliano ancora il Plug-in per il controllo dello stato per isolare un conflitto senza interrompere il tuo sito live, e sulla carta è lo strumento giusto. La sua ultima versione è stata la versione 1.7.1 sopra 25 luglio 2024. Dichiara la compatibilità solo fino a WordPress 6.6.7, e porta ancora 200,000 installazioni attive. Sono tre le principali versioni di WordPress dietro, su un plugin il cui intero lavoro è manipolare quali plugin vengono caricati. Rinominare una cartella tramite FTP è più rozzo e sicuro.

Lavora qui quando vedi una pagina di errore di WordPress o niente. Un modulo di accesso che viene visualizzato correttamente lo esclude, perché PHP ha superato la richiesta.

Il tuo plugin di sicurezza ti ha bloccato fuori

Gli strumenti che proteggono wp-login.php sono anche quelli che hanno maggiori probabilità di bloccare la persona che li ha installati. Conoscere la scala prima di assumere un bug fondamentale. Wordfence si siede 5 milioni di siti. Limita tentativi di accesso Sicurezza e Loginizer vengono eseguiti 1 milioni ciascuno, e Kadence Security attiva 700,000. In un'installazione tipica, uno di questi è tra te e la tua dashboard.

Il che solleva un problema di denominazione che ha confuso le persone tutto l’anno. Cerco Solid Security nell'elenco dei plugin e non riesco a trovarlo? Solid Security è diventata Kadence Security nella versione 10.0.0, taggato 12 Maggio 2026, after Liquid Web retired the StellarWP brand. The plugin folder is still called better-wp-security, the name it carried as iThemes Security before that. Three brands, one folder.

The same version series carries a bug worth naming, because it causes exactly the failure this article is about. Kadence Security 10.0.1, taggato 12 Maggio 2026, fixed a race condition in the plugin’s file writer that could empty wp-config.php or .htaccess. An empty wp-config.php doesn’t just lock you out of the login page. It takes down the whole site, database credentials and all. And it looks nothing like a plugin problem while you’re staring at it.

Recovery is the same for all of them, and it doesn’t require guessing a lockout table name. Connect over FTP or SSH, Aperto /contenuto wp/plugins/, and rename the offending folder, così wordfence diventa wordfence-off. WordPress non riesce più a trovare il file del plugin, deactivates it silently, e con esso il blocco. Accesso, rinominare nuovamente la cartella, quindi riconfigurare prima di riattivare.

I blocchi a due fattori seguono lo stesso percorso con un passo avanti. Cerca i codici di ripristino che ti sono stati forniti durante la configurazione. Controlla prima il tuo gestore di password, perché è una correzione di trenta secondi contro una di cinque minuti. Nessun codice? Rinomina la cartella del plugin 2FA. La tua 2FA è inclusa in una suite di sicurezza anziché in un plug-in autonomo? Rinominare la cartella della suite elimina contemporaneamente il blocco e il secondo fattore.

Inizia da qui quando vedi un conto alla rovescia, un messaggio di blocco o una richiesta 2FA. Una password accettata prima che la pagina si ricarichi in modo pulito è il ciclo, non un blocco.

La pagina di accesso che si è spostata

UN 404 su /wp-admin è un animale diverso da un accesso che fallisce. Niente è andato in crash. La porta è stata spostata e nessuno ha scritto dove.

Viene eseguito WPS Hide Login 2 milioni di siti e fa un lavoro. Cambia il tuo URL di accesso, quindi i bot che colpiscono /wp-login.php non trovano nulla. Funziona bene fino al giorno in cui hai bisogno dell'URL e non riesci a ricordarlo. (Quel giorno sembra sempre arrivare di domenica.) Il ripristino richiede una ricerca, perché il plugin memorizza lo slug in testo semplice. Apri phpMyAdmin, vai al wp_opzioni tavolo, e cerca option_name per whl_page. Il valore in quella riga è il tuo slug di accesso. L'URL di accesso è l'URL del tuo sito, una barra, e quel valore.

Piuttosto non toccare il database? Rinominare /wp-content/plugins/wps-hide-login/ tramite FTP ripristina immediatamente /wp-login.php, come qualsiasi altro plugin. La ricerca nel database è l'opzione migliore quando si desidera ripristinare l'URL anziché eliminare il plug-in. Confrontalo con i blocchi di sicurezza sopra, dove rinominare la cartella è l'intera soluzione. Qui è la schiettezza di due scelte.

Controlla anche che nessuno abbia rinominato wp-login.php stesso, o aggiunta una regola .htaccess che limita wp-admin a un indirizzo IP fisso. Le liste consentite IP su wp-admin sono comuni sui siti creati dalle agenzie. Si interrompono il giorno in cui la connessione di casa del cliente ottiene un nuovo indirizzo.

Go here for a 404 o la pagina di errore del tuo host invece di una schermata WordPress. If the form loads at all, il file è esattamente dove WordPress se lo aspetta, so look elsewhere.

Reimpostare la password quando l'e-mail non arriva mai

Il collegamento di ripristino ha una durata che la maggior parte delle persone non si aspetta. WordPress fa scadere una chiave di reimpostazione della password dopo 24 ore per impostazione predefinita. Quindi un collegamento presente nella tua casella di posta della scorsa settimana è morto. Il “il tuo link per la reimpostazione della password è scaduto” il messaggio che segue manda le persone a cercare un difetto che non c’è. Richiedine prima uno nuovo.

Prima di toccare il database per quanto segue, fare un backup. Non esiste un backup del plugin che presumi esista, ma una copia effettiva della tabella wp_users che puoi ripristinare in un unico incolla. I nostri Guida al backup di WordPress copre farlo correttamente, e l'esportazione del database richiede circa due minuti in phpMyAdmin.

Con accesso SSH, WP-CLI è il percorso più veloce e quello da preferire. Passa attraverso l’hashing di WordPress anziché aggirarlo. Correre amministratore aggiornamento utente wp –pass_utente=”la tua nuova password” dalla radice del sito, sostituendo il tuo nome utente. Funziona indipendentemente da quanto sia rotto il cruscotto, e non può scrivere un hash non valido.

Senza SSH, il percorso phpMyAdmin funziona ancora, e c'è un 2026 le altre guide sbagliano in entrambe le direzioni. Su 15 aprile 2025, WordPress 6.8 ha cambiato la password da phpass a bcrypt. Le password scritte dopo tale data portano a $wp$2y$ prefisso invece del vecchio $P$. Alcune guide ora affermano che il classico trucco di phpMyAdmin è morto a causa di ciò. Non lo è. Il controllo della password di Core ha ancora un ramo per qualsiasi hash di 32 characters or fewer, che lo confronta come un semplice MD5. Quindi la vecchia routine funziona ancora su WordPress 7.1. Edit the user_pass row in wp_users, seleziona MD5 dal menu a discesa delle funzioni, e digita la tua nuova password.

Ciò che è cambiato è ciò che accadrà dopo. Al tuo primo accesso riuscito, core nota che l'hash non è aggiornato e lo riscrive silenziosamente come bcrypt. La tua riga MD5 esiste esattamente per un accesso, then upgrades itself. Questo è il dettaglio da togliere. L'hashish debole è una porta, non è uno stato in cui stai lasciando il tuo sito. Basta non fermarti sulla soglia: impostare una password reale da parte degli Utenti > Profilo una volta che sei dentro.

La tua sezione quando l'e-mail di ripristino non arriva mai, oppure l'account stesso sembra integro. Agli errori e ai blocchi dei cookie non interessa quale sia la tua password, quindi un ripristino non risolve nessuno dei due.

Quando il blocco è il tuo server, Non WordPress

Alcuni errori di accesso non raggiungono mai PHP. Se il modulo non viene caricato affatto, WordPress non è coinvolto. Lo stesso vale se l'invio restituisce un file bare 403 dal tuo host anziché da una schermata WordPress. Nessuna quantità di ridenominazione del plugin aiuterà nessuno dei due.

La causa più comune è una regola del firewall davanti all'applicazione. La maggior parte degli host condivisi esegue ModSecurity o un equivalente, e un POST su wp-login.php contenente un carattere insolito può far scattare una regola generica. Vedrai una pianura 403, a volte con un ID di riferimento. Quell'ID è l'intera conversazione con il supporto: give it to them and ask which rule fired.

Caching is the second suspect. Server-level page caches are meant to exclude wp-login.php automatically. When that exclusion breaks, the login page gets served from cache with a stale nonce. It submits, and it fails silently.

One error belongs to neither list. “errore nello stabilire una connessione col database” isn’t a login fault at all, because it shows on every page of the site. Check the credentials in wp-config.php, then ask your host whether the database server is up.

Then there’s the certificate, quietly becoming the more common one. Let’s Encrypt stopped sending expiry emails sopra 4 giugno 2025, so a renewal that fails now fails in silence. Chrome is closing the gap from the other side. Cromo 147 acceso “Utilizza sempre connessioni sicure” per gli utenti di Navigazione sicura avanzata nel mese di aprile 2026. Cromo 154 makes it the default for everyone in October 2026. Un sito con un certificato morto smette di essere un avviso su cui puoi fare clic e diventa un muro. La tua pagina di accesso genera una schermata di sicurezza del browser anziché quella di WordPress? La nostra procedura dettagliata di il “la tua connessione non è privata” errore separa un certificato errato da un orologio del dispositivo errato.

Un test ti dice su quale lato lavorare. Carica la pagina di accesso in una finestra privata su dati mobili, completamente fuori dalla rete domestica. Se si carica lì, il blocco è locale per te: un divieto IP, il tuo ISP, o il tuo software di sicurezza. Se fallisce anche lì, è il server, e questo è un ticket di supporto piuttosto che una modifica del file.

Vieni qui quando non vedi mai una schermata di WordPress. Un errore formulato da WordPress significa che la richiesta ha raggiunto PHP, quindi lavora invece sulle sezioni sopra.

Quando non è un bug

A volte non c'è nulla di rotto e il login funziona esattamente come previsto. Semplicemente non è più progettato per te.

Tre segnali puntano in questa direzione piuttosto che in una delle soluzioni descritte sopra:

  • Il tuo account amministratore non esiste più
  • C'è un amministratore nella tabella degli utenti che non hai creato
  • La tua password ha smesso di funzionare su tutti i dispositivi nello stesso momento

Un sito compromesso si comporta in questo modo perché l'aggressore ha modificato le credenziali. La pagina di accesso continuerà a rifiutarti educatamente per tutto il giorno.

La stessa schermata di accesso è stata un obiettivo quest'anno. WordPress 7.0.3 patchato CVE-2026-64638 sopra 6 agosto 2026, classificato un difetto di scripting cross-site pre-autenticazione in wp-login.php 8.9, con correzioni supportate dal backport tramite 4.7 ramo. Consente a un utente malintenzionato di creare un URL di accesso che esegue JavaScript nel browser di un amministratore. L'apertura del collegamento era l'unica interazione necessaria, e i ricercatori hanno dimostrato di concatenarlo all'esecuzione di PHP. Running an older build, with access that vanished for no reason? Check your patch level first, not last.

You can read the version without a dashboard. Aperto wp-include/versione.php over FTP and look at the $wp_version line on the same trip you’re already making. WordPress 7.1 is current as of September 2026. Note that the August fix was backported as far as 4.7.34, so an old major branch isn’t automatically unpatched. What matters is whether the site took its last minor update.

Regaining access is the easy half here, and it’s the half people stop at. Resetting the password gets you in; the attacker’s backdoor puts them back tomorrow. Una volta dentro, work through four steps in order:

  • Update core and every plugin and theme
  • Remove any administrator account you don’t recognize
  • Change the salts in wp-config.php, which force-logs-out every session
  • Quindi avvia l'effettiva pulizia del malware

Se il sito è stato visibilmente deturpato o pubblica spam, il ripristino di un backup noto è migliore della pulizia manuale.

Leggi questo quando l'accesso è svanito senza alcun aggiornamento, nessuna modifica di configurazione e nessun errore. Tutto ciò che puoi ricondurre alle tue azioni è uno dei sette problemi più economici sopra menzionati.

Quale soluzione provare per prima

L'ordine corretto dipende dall'accesso di cui disponi e da cosa stavi facendo quando si è rotto. Quattro situazioni ne coprono la maggior parte.

Aggiornare, white screen, niente SSH. Hai fatto clic su Aggiorna plugin, the site went white, e cPanel è tutto ciò che hai. Controlla prima la posta in arrivo dell'amministratore per l'e-mail della modalità di ripristino, perché un clic batte la ricerca di un file. Nothing there? In File Manager, rinominare /contenuto wp/plugin per plugin disattivati, login, rename it back, quindi riattivare un plugin alla volta finché non si rompe di nuovo. Non installare Health Check per farlo in modo più elegante. Its last update was July 2024, and it hasn’t been tested past WordPress 6.6.7.

Right password, silent bounce. No error message, straight back to the login form, and the site moved to HTTPS recently. Go directly to il ciclo di accesso and set WP_HOME and WP_SITEURL in wp-config.php. Skip the cookie-clearing advice entirely. Your browser holds a cookie whose name no longer matches the md5 of your site URL. Clearing it just removes a cookie WordPress had already stopped looking for.

2FA lockout, SSH available. You wiped your phone and the authenticator went with it. Two commands and you’re done: wp plugin deactivate with the 2FA plugin’s slug, poi wp user update for a fresh password if you need one. This is where WP-CLI earns its place. Through phpMyAdmin, the same job means finding the right user_meta rows. Through FTP, significa rinominare le cartelle e sperare che tu abbia scelto quella giusta.

La pagina non verrà caricata affatto. UN 403 dal tuo ospite, o un timeout, e nessuno schermo WordPress da nessuna parte. Niente in wp-content aiuterà. Prova prima sui dati mobili, per escludere un blocco IP sulla propria connessione. Quindi invia al tuo host il timestamp e qualsiasi ID di riferimento dal file 403. La modifica dei file mentre una regola del server blocca la richiesta fa perdere il pomeriggio.

Un'abitudine impedisce la maggior parte delle visite ripetute: conosci il tuo percorso prima che tu ne abbia bisogno. Se hai SSH, conferma che WP-CLI funziona effettivamente sul sito oggi. Se non lo fai, conferma che puoi raggiungere il file manager e phpMyAdmin, e che l'e-mail dell'amministratore è una casella di posta che hai letto. Scoprire che l'e-mail di recupero arriva all'indirizzo di un ex sviluppatore, mentre il sito è inattivo, è il momento peggiore possibile.

Domande frequenti

Perché la mia pagina di accesso a WordPress continua ad aggiornarsi senza errori?

A silent refresh with no error text almost always means a cookie mismatch, not a wrong password. WordPress names its login cookie using an md5 of the siteurl option. Change the site URL (http to https, adding www, a new domain) and it looks for a cookie name your browser doesn’t have. Set WP_HOME and WP_SITEURL in wp-config.php to the exact URL you serve, with no trailing slash. A corrupted .htaccess produces the same symptom, so rename it to .htaccess-old if the constants don’t fix it.

Come posso reimpostare la mia password amministratore di WordPress in phpMyAdmin?

Apri phpMyAdmin, select your site’s database, and edit your username’s row in the wp_users tavolo. Replace the value in user_pass, choose MD5 from the function dropdown beside the field, e salva. Export the table first so you can undo it. Con accesso SSH, correre amministratore aggiornamento utente wp –pass_utente=”new-password” anziché. WP-CLI writes a proper hash and can’t produce a malformed one.

Il trucco della password MD5 funziona ancora ora che WordPress utilizza bcrypt?

sì, on WordPress 7.1 as of September 2026. WordPress 6.8 attivato i nuovi hash delle password su bcrypt 15 aprile 2025. Il controllo della password nel core tratta ancora qualsiasi hash di 32 caratteri o meno come un semplice MD5. Il tuo valore MD5 ti fa entrare una volta, e core quindi lo riscrive come hash bcrypt al primo accesso riuscito. Imposta comunque una password corretta dal tuo profilo in seguito.

Come disabilito un plugin quando non riesco ad accedere a WordPress?

Connettiti tramite FTP, SFTP o il file manager del tuo host, quindi rinominare la cartella del plugin all'interno /contenuto wp/plugins/. Giro wordfence in wordfence-off, per esempio. WordPress non riesce a trovare il file del plugin, lo disattiva, e ti fa entrare. Per disabilitare tutto in una volta, rinominare il tutto plugins cartella invece. Con SSH, wp plugin deactivate –tutti fa lo stesso lavoro senza toccare il nome di un file.

Perché WordPress mi disconnette dopo un paio di giorni?

Questa è l'impostazione predefinita, non è una colpa. WordPress imposta la scadenza del cookie di autenticazione 2 giorni con un accesso normale, e 14 giorni in cui spunti “Ricordati di me”. Disconnesso molto prima? Controlla tre cose: un plugin di sicurezza che accorcia la sessione, una mancata corrispondenza www e non www, o una cache degli oggetti che rilascia token di sessione.

Cosa faccio se l'e-mail di reimpostazione della password di WordPress non arriva mai?

Supponiamo che il sito non possa inviare posta, piuttosto che il ripristino sia interrotto. I due errori sembrano identici dalla schermata di accesso. Reimposta la password direttamente con WP-CLI o phpMyAdmin per rientrare, quindi correggere la consegna instradando la posta tramite un servizio SMTP autenticato. Anche i collegamenti di reimpostazione scadono dopo 24 ore per impostazione predefinita, quindi un'e-mail più vecchia nella tua casella di posta fallirà anche se è arrivata.

Il plug-in Health Check è ancora sicuro per la risoluzione di un problema di accesso?

Non è lo strumento a cui attingere 2026. Controllo dello stato di salute & Risoluzione dei problemi dell'ultima versione spedita 1.7.1 sopra 25 luglio 2024 e dichiara la compatibilità solo fino a WordPress 6.6.7, tre versioni principali dietro l'attuale. Lo è ancora 200,000 installazioni attive ed è ancora ampiamente consigliato, ecco perché continua a presentarsi. Per isolare un conflitto di plugin mentre sei bloccato, renaming folders over FTP or running WP-CLI is simpler and current.

Rientrare: La versione breve

Read the error text before you touch anything, because the exact wording narrows eight possible failures to one. Cookie errors split into a browser fix and a server fix that share nothing but the word “biscotti”. A silent loop is a site URL problem, solved in wp-config.php in two lines. A blank page means checking the admin inbox for a recovery mode link before you open an FTP client. A lockout means renaming a plugin folder. Everything else is either your server or an intrusion. A server block is a support ticket. An intrusion makes regaining access the start of the job, not the end.

Do one thing while the site is still working. Verify today that you can reach phpMyAdmin or WP-CLI, e che l'e-mail dell'amministratore arrivi da qualche parte che hai effettivamente letto. Ogni correzione sopra presuppone che una di queste due porte sia aperta.

Se il tuo arresto anomalo risale a qualcosa di più ampio della schermata di accesso, abbiamo guide per i problemi vicini. Un aggiornamento in stallo si lascia alle spalle il “brevemente non disponibile per manutenzione programmata” Messaggio, che sembra allarmante e si cancella in pochi secondi. E se lo stesso sito continua a rompersi dopo gli aggiornamenti di routine, l'ospite è spesso il fattore comune. Trasferirsi a hosting WordPress gestito con staging e rollback automatici cambia i conti. In un client FTP, un aggiornamento interrotto richiede un ripristino di due minuti invece che di un pomeriggio.

Ricercato e scritto da:
Editor di HowToHosting
HowToHosting.guide fornisce competenze e approfondimenti sul processo di creazione di blog e siti Web, trovare il giusto provider di hosting, e tutto ciò che si frappone. Per saperne di più...

Lascio un commento

L'indirizzo email non verrà pubblicato. i campi richiesti sono contrassegnati *

Questo sito web utilizza i cookie per migliorare l'esperienza dell'utente. Utilizzando il nostro sito acconsenti a tutti i cookie in conformità con la ns politica sulla riservatezza.
Sono d'accordo
Su HowToHosting.Guide, offriamo recensioni trasparenti di web hosting, garantire l’indipendenza dalle influenze esterne. Le nostre valutazioni sono imparziali poiché applichiamo standard rigorosi e coerenti a tutte le recensioni.
Mentre potremmo guadagnare commissioni di affiliazione da alcune delle società presenti, queste commissioni non compromettono l'integrità delle nostre recensioni né influenzano le nostre classifiche.
I guadagni dell'affiliato contribuiscono a coprire l'acquisizione dell'account, spese di prova, Manutenzione, e lo sviluppo del nostro sito web e dei sistemi interni.
Affidati a howtohosting.guide per approfondimenti affidabili e sincerità sull'hosting.