Come eliminare strani errori 404 in wp-admin?

Question

Come eliminare strani errori 404 in wp-admin?

18 ago 2010, 06:46:16

Visualizzazioni: 20.4K

Voti: 8

Gestisco un sito WordPress con circa 70 plugin attivi.

Ogni tanto, mi appare una pagina di errore casuale ("Non trovato", anche se non ho controllato gli header per vedere se è un 404) su una pagina /wp-admin/ che spunta dal nulla.

Il semplice riprovare risolve l'errore, tuttavia è piuttosto scomodo se l'errore si verifica durante un aggiornamento di un plugin (perché la riattivazione automatica fallisce). Penso che questo stesso problema sia responsabile del mancato caricamento occasionale di alcuni moduli nella Dashboard.

Data la lista dei plugin che ho installato, qualcuno conosce problemi con o tra questi plugin che potrebbero causare questo problema?

Modifica:

Informazioni sull'hosting: DreamHost; penso che il server stia eseguendo una build personalizzata di Debian con Apache httpd

dgw

359

plugin wp admin errori errore 404 debug

Commenti

Non per essere scortese, ma questo è davvero un problema di supporto e non qualcosa che vorremmo trattare qui; voterò per chiudere. Chiedi piuttosto su http://wordpress.org/support. Se fai qualche test e restringi la tua domanda in modo che sia applicabile a più situazioni oltre alla tua, potrebbe diventare una domanda accettabile qui. Ancora una volta, mi dispiace dover agire così, ma WordPress Answers dovrebbe essere utile a tutti gli utenti e un sacco di richieste di supporto lo rovinerebbero.

MikeSchinkel

18 ago 2010 08:15:39

Concordo, quindi voterò anch'io per chiudere.

Ben Everard

18 ago 2010 12:57:16

D'accordo. Voto per chiudere come troppo specifico.

John P Bloch

18 ago 2010 17:16:02

Voto per non chiudere. Molte persone nuove a WP potrebbero incontrare errori 404 in WP-Admin, e alla fine si riduce a un bug in un plugin o tema, o al loro effetto magari su una regola di riscrittura (salvata nel database in wp-options o nel file .htaccess). Quello che dovremmo fare, invece, è fornire passaggi generali di risoluzione dei problemi che si possono seguire per identificare l'area del problema molto più velocemente.

Volomike

18 ago 2010 23:21:36

Beh, anche se questa tende a essere una domanda di supporto, contiene abbastanza informazioni per almeno suggerire alcuni modi per risolvere il problema rapidamente.

hakre

20 ago 2010 13:11:14

Tutte le risposte alla domanda

Commenti

Ho sicuramente un sacco di roba mod_rewrite nei miei file .htaccess. Sembra che sia proprio quello che mi sta succedendo. Sapevo di aver raggiunto i limiti di memoria con i miei job di backup, ma non per le richieste "reali". Grazie per aver condiviso la tua esperienza; spero che la tua risposta faccia risparmiare tempo a molte persone.

dgw

23 ott 2010 23:56:03

Non è solo Dreamhost. Sono passato da Dreamhost a un server privato altrove, e ho ancora questo problema continuamente.

supertrue

24 set 2012 01:09:23

L'unico modo per eseguire il debug di questo problema è disattivare un plugin alla volta, provando ogni volta a riprodurre il problema prima di disattivare il plugin successivo. Inizia con i plugin che hanno a che fare con l'amministrazione di WP, poi passa ai plugin regolari del tema, widget e simili.

Analizza meglio la pagina "Non trovato" che ti viene servita (naviga con Opera e apri il pannello Info che ti mostrerà gli header, in alternativa naviga con Firefox e attiva Firebug con il pannello "Net" abilitato) ed esegui una ricerca tra tutti i tuoi plugin per vedere se potrebbero servirlo direttamente. In caso contrario, dai un'occhiata al log del server web per scoprire quale risorsa esatta non riesce a servire; un plugin potrebbe eseguire qualche reindirizzamento o riscrittura avanzata, quindi non è necessariamente l'URL che vedi nel browser a causare l'errore 404.

Asbjørn Ulsberg

281

18 ago 2010 23:17:29

Commenti

Con 70 plugin, sarebbe davvero utile trovare un modo per farlo in modo super veloce senza doverli disattivare e testare manualmente uno per uno, ad esempio con un file di test per i plugin.

Volomike

18 ago 2010 23:23:45

Vedo che hai modificato la tua risposta originale con un ottimo suggerimento per trovare la soluzione più rapidamente.

Volomike

18 ago 2010 23:45:07

Grazie, asbjornu. Ci darò un'occhiata dopo essere tornato dalle vacanze con la mia famiglia.

dgw

19 ago 2010 18:45:28

Ho esaminato i log del server e non ho trovato nulla di più specifico di "Fine prematura dell'intestazione dello script". Immagino che non potesse essere così semplice...

dgw

1 set 2010 23:34:59

Questa è solo un'idea approssimativa: se ricevi un errore 404 "reale" (con gli header impostati), potresti cercare tra i tuoi plugin e cercare la funzione PHP header() e il numero 404. Questo potrebbe ridurre il numero di plugin da 70 a solo alcuni. Dopodiché devi solo controllare quelli.

Questo può essere facilmente fatto con un IDE come Eclipse PDT che offre la ricerca per una specifica chiamata di funzione PHP.

Oltre a questo, ma senza garanzia che funzioni con successo, è scrivere un plugin che si agganci all'impostazione degli header e poi ti fornisca una traccia di quale codice sta effettivamente impostando un potenziale 404 (backtrace). Questo funzionerebbe solo se il plugin utilizza la funzione API di WordPress. Il primo metodo per cercare la funzione PHP funzionerà indipendentemente dall'API di WP.

hakre

12.9K

20 ago 2010 13:08:34

Commenti

Sembra promettente. Qualcos'altro da approfondire dopo la mia vacanza. :)

dgw

21 ago 2010 07:16:16

Ho cercato di fare qualche verifica mentre ero ancora fuori città, e ho scoperto solo che il mio plugin di backup sembra richiedere l'output di un 404. Firebug mostra che si tratta effettivamente di un 404, però. Qualche progresso... Però ora sto avendo problemi a replicare il problema, quindi credo che farò una pausa. Odio i bug intermittenti!

dgw

1 set 2010 23:33:59

Posso solo raccontare la mia esperienza personale, e finora non ho trovato una regola "definitiva" per risolvere tutti i problemi in un colpo solo.

Il problema principale con la configurazione di DreamHost è che, nella lotta eterna per mantenere il consumo di memoria al minimo, significa eliminare quante più funzionalità possibili - ovvero tutto ciò che ridurrebbe la larghezza di banda (ottimo per i visitatori!) o la CPU (ottimo per il server, ma DreamHost non controlla il consumo della CPU in modo così aggressivo come fa con la RAM). Ad esempio, questo significa rinunciare all'HTML + CSS compresso con gzip (che consumerebbe CPU + RAM) o a uno dei vari plugin Minify (che consumerebbero anche RAM). Più sofisticata è la cache (io preferisco usare W3 Total Cache, o almeno WP Super Cache), più RAM verrà consumata.

Allo stesso modo, molti plugin che limitano il numero di query MySQL per migliorare le prestazioni consumeranno invece RAM. Quindi trovare un compromesso in cui puoi mantenere il tuo sito reattivo con buone prestazioni evitando di consumare preziosa RAM è un compito arduo!

Finora, i miei migliori risultati su siti molto trafficati sono stati disattivare l'ottimizzazione della velocità delle pagine (Page Speed Optimization) e la sicurezza web extra (Extra Web Security), che apparentemente consumano molta RAM, e affidarsi invece a una combinazione con W3 Total Cache e Cloudflare (servizio di reverse proxy gratuito). Cloudflare farà effettivamente la stessa cosa del modulo "Extra Web Security", ma poiché funziona al di fuori di DreamHost, va bene. W3 Total Cache consuma molta memoria, ma una volta che le pagine sono memorizzate staticamente localmente, Cloudflare le memorizzerà in cache in modo molto efficiente - quindi potresti ottenere errori 404/500 durante la modifica degli articoli, almeno i tuoi visitatori non li sperimenteranno (Cloudflare può anche servire pagine statiche anche se DreamHost restituisce un 404 o un 500).

Inoltre, grazie a questo articolo, ho scoperto che FastCGI utilizza più RAM del CGI "normale". E poiché PHP 5.3 è migliore nella gestione della RAM (garbage collection più aggressiva, meno perdite di memoria), ho sperimentalmente passato a PHP 5.3 CGI (non FastCGI) senza ottimizzazione della velocità delle pagine né sicurezza web extra, affidandomi a W3 Total Cache + Cloudflare per accelerare il sito. Ora il backoffice è più lento (più consumo di CPU!) ma almeno non vedo errori 404/500 (finora!).

Sono ancora insoddisfatto della combinazione, quindi continuerò sicuramente a modificare le impostazioni di DreamHost sperando di ridurre ulteriormente il consumo di RAM e ottenere comunque prestazioni adeguate. Come ha detto @dgw, anche io uso molti plugin - perché ho bisogno delle loro funzionalità. Non tutti coloro che ospitano WP con DreamHost hanno semplici esigenze di blogging; più complesso è il sito, più funzionalità richiederà... e questa è la bellezza di WordPress, devi solo usare i plugin di cui hai veramente bisogno e mantenere l'installazione di base di WP semplice se sei soddisfatto con poche esigenze. I plugin, tuttavia, non sono necessariamente "cattivi" o pesanti per il sito; ma è vero che alcuni potrebbero consumare molta RAM...

Gwyneth Llewelyn

130

11 set 2011 17:02:26

Ulteriori informazioni necessarie:

1) Perché così tanti plugin?

2) Quale sistema operativo utilizza il tuo hosting provider?

3) Quale webserver?

4) Hai accesso ai log del server httpd, in particolare ai log degli errori?

5) Cosa dicono i log degli errori nei periodi temporali in cui si verificano questi problemi?

(A dire il vero, se stiamo generalizzando per "l'utente medio di WordPress potrebbe avere questa stessa domanda", potremmo iniziare indirizzando detto utente a rispondere almeno alle 5 domande sopra...)

ZaMoose

1.67K

18 ago 2010 23:47:37

Commenti

Ho tutti quei plugin perché utilizzo le funzioni che offrono; per quale altro motivo? I log degli errori non dicono molto. Sono su DreamHost, quindi penso che il server stia eseguendo una build personalizzata di Debian con Apache httpd.

dgw

1 set 2010 23:37:11

Ora che lo menzioni, vedo anch'io quegli errori casuali sui miei siti DH. Si verifica soprattutto quando cerco di fare un aggiornamento di rete nelle mie installazioni MS e avvio l'importatore.

Strano.

ZaMoose

3 set 2010 23:44:46

User 100 · Accepted Answer · 2010-10-23T05:38:07Z

Ho avuto problemi tutto il giorno con quelli che sembravano essere errori 404 fuori luogo.

Comunque, ho appena finito di chattare con un tecnico del supporto Dreamhost che mi ha detto che un account utente che ho con loro stava raggiungendo i limiti di memoria dei processi (tutti i processi) e questo era ciò che causava strani problemi, apparentemente legati all'htaccess. Ricevevo errori 404 intermittenti da un file htaccess che non avrebbe dovuto essere chiamato affatto! Era Dreamhost con un server infestato.

A quanto pare, il robot che Dreamhost utilizza per terminare i processi uccide un processo web a metà e poi, per qualche motivo, Apache (ormai uno zombie) cerca effettivamente di completare il suo lavoro (facendo del suo meglio per uscire pulito dalla brutta fine di una sotto-richiesta è la mia migliore ipotesi). Genera un errore 500 nel log HTTP principale, ma dopo averlo fatto, attiva effettivamente la condizione e la regola di riscrittura che non avrebbero mai dovuto essere attivate (usando i comandi standard -f per i file e -d per le directory nell'htaccess) - e non scrive una nuova voce nel log! Una nuova richiesta (dell'uomo invisibile) attiva quindi il file index nell'ultima riga dell'htaccess.

Attenzione ai limiti delle risorse negli account base di Dreamhost! Se superi i loro limiti e hai un htaccess con righe mod_rewrite, vedrai cose strane che sono adatte solo per la notte di Halloween - uomini invisibili, 404 infestati! Processi non morti! Apache zombie! Htaccess che si muove da solo! Brrr!

Spero che questo vi aiuti a evitare alcune ore di dolore.