Come eliminare strani errori 404 in wp-admin?

Gestisco un sito WordPress con circa 70 plugin attivi.

Ogni tanto ricevo una pagina di errore casuale ("Not Found", anche se non ho controllato le intestazioni per vedere se è un 404) su una /wp-admin/pagina che si apre dal nulla.

Riprovare semplicemente a risolvere l'errore, tuttavia è abbastanza scomodo se l'errore si verifica durante un aggiornamento del plug-in (poiché la riattivazione automatica non riesce). Penso che questo stesso problema sia responsabile per il mancato caricamento di alcuni moduli sul mio Dashboard a volte.

Dato l' elenco dei plugin che ho installato , qualcuno è a conoscenza di problemi con o tra i quali potrebbero causare questo problema?

Modificare:

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

ho avuto problemi tutto il giorno con quelli che sembravano essere i 404 errori.

comunque, ho appena finito di chattare con una persona dell'assistenza tecnica di dreamhost che mi ha detto che un account utente che ho con loro stava colpendo i limiti delle risorse di memoria del processo (tutti i processi) e questo era ciò che stava causando strani problemi apparentemente legati all'htaccess. Stavo ricevendo errori 404 intermittenti da un file htaccess che non avrebbe dovuto essere chiamato affatto! era un dreamhost con un server della casa stregata.

a quanto pare, il processo che uccide il robot che utilizza Dreamhost ucciderà un processo Web nel mezzo e poi per qualche ragione, l'apache (ora zombi) in realtà cerca di finire il suo lavoro (facendo del suo meglio per uscire in modo pulito dalla fine non familiare a una richiesta secondaria è la mia ipotesi migliore). genera un errore 500 nel registro http principale, ma dopo averlo fatto, in realtà genera la condizione e la regola di riscrittura che non avrebbero mai dovuto essere attivate (usando il file standard -f e la directory -d file htaccess sopra) - e non lo fa scrivi una nuova voce di registro! una nuova richiesta (uomo invisibile) quindi attiva il file indice nell'ultima riga del file htaccess

attenzione ai limiti di risorse negli account base di dreamhost! se oltrepassi i tuoi limiti e hai delle linee mod_rewrite accattivanti, vedrai cose strane che sono adatte solo per la notte di halloween: uomini invisibili, infestati 404! processi non morti! apache di zombi! htaccess si muove da solo! yikes!

spero che questo ti aiuti ad evitare alcune ore di dolore.

L'unico modo per eseguire il debug è disabilitare un plug-in alla volta, ogni volta cercando di riprodurre il problema prima di disabilitare un altro plug-in. Inizia con i plug-in che hanno a che fare con l'amministrazione di WP, quindi passa ai plug-in a tema regolari, ai widget e così via.

Ispeziona la pagina "Non trovato" che ti viene servito meglio (naviga con Opera e apri il pannello Informazioni che ti mostrerà le intestazioni, in alternativa naviga con Firefox e hai Firebug con il pannello "Rete" abilitato) ed esegui una ricerca in tutti i tuoi plugin per vedere se potrebbero essere pubblicati direttamente. In caso contrario, dai un'occhiata al registro del web server per scoprire quale risorsa esatta non è in grado di servire; un plug-in potrebbe eseguire un reindirizzamento o una riscrittura fantasiosi, quindi non è necessariamente l'URL che vedi nel tuo browser a causare il 404.

Posso solo mettere in relazione la mia esperienza e finora non ho trovato una regola "definita" per risolvere tutti i problemi in un colpo solo.

Il problema principale con l'installazione di DreamHost è che, nella lotta eterna per mantenere il consumo di memoria al minimo, significa eliminare quante più funzionalità possibili, vale a dire tutto ciò che ridurrà la larghezza di banda (buona per i visitatori!) O la CPU (buona per il server, ma DreamHost non controlla il consumo della CPU in modo aggressivo come controllano la RAM). Ad esempio, questo significa sbarazzarsi di HTML + CSS (che consumerà CPU + RAM) o di uno dei numerosi plugin Minify (che consumeranno anche RAM). Più sofisticata è la cache (mi piace usare W3 Total Cache, o almeno WP Super Cache), maggiore sarà anche il consumo di RAM.

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 è ancora possibile mantenere il tuo sito rispondendo con buone prestazioni evitando di consumare preziose RAM è un compito difficile!

Finora, i miei migliori risultati su siti occupati sono deselezionare Ottimizzazione della velocità della pagina e Sicurezza Web extra che apparentemente consumeranno molta RAM e si basano invece su una combinazione con W3 Total Cache e Cloudflare (servizio proxy inverso 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 state memorizzate staticamente localmente, Cloudflare le memorizzerà nella cache in modo molto efficiente - quindi potresti ottenere 404/500 durante la modifica dei post, almeno i tuoi visitatori non le sperimenteranno (Cloudflare può anche servire pagine statiche anche se DreamHost dà 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), sono passato sperimentalmente al CGI PHP 5.3 (non FastCGI) senza l'ottimizzazione della velocità della pagina o la sicurezza Web extra, basandomi su W3 Total Cache + Cloudflare per accelerare il sito. Ora il backoffice è più lento (maggiore consumo di CPU!) Ma almeno non vedo 404/500 (finora!).

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

Questa è solo un'idea approssimativa: se ricevi un errore "reale" 404 (con le intestazioni impostate), puoi cercare tra i tuoi plugin e cercare la funzione PHPheader() e il numero 404. Questo potrebbe ridurre il numero di plugin da 70 a solo alcuni. Quindi devi solo controllare quelli.

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

Accanto a questo, ma senza alcuna garanzia che funzioni correttamente, è scrivere un plug-in che si aggancia all'impostazione dell'intestazione e quindi ti dà traccia del codice che sta effettivamente impostando un potenziale 404 (backtrace). Funzionerebbe solo se il plugin utilizza la funzione API di WordPress. Il primo metodo per cercare la funzione PHP funzionerà indipendentemente dall'API WP.

Ulteriori informazioni necessarie:

1) Perché così tanti plugin?

2) Quale sistema operativo è in esecuzione il tuo provider di hosting?

3) Quale server web?

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

5) Cosa dicono i log degli errori nei tempi che circondano questi problemi?

(A dire il vero, se stiamo generalizzando per "J6P medio con WordPress potrebbe avere questa domanda esatta, potremmo iniziare indirizzando detto J6P a rispondere almeno alle 5 domande precedenti ...)