Come eliminare strani errori 404 in wp-admin?

Question

Ho eseguito un sito WordPress con circa 70 plugin attivi.

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

Semplicemente cercando di risolvere di nuovo l'errore, tuttavia è abbastanza scomodo se l'errore si verifica durante un aggiornamento del plugin (perché l'auto-riattivazione non riesce). Penso che questo stesso problema è responsabile di alcuni moduli sul mio cruscotto non riuscendo a caricare a volte.

dei plugin che ho installato , qualcuno sa di problemi con o tra uno di loro che potrebbe causare questo problema?

Modifica:

Informazioni hosting: DreamHost; Credo che il server di gestione di un personalizzato Debian costruire con Apache httpd

Answer 1

ho avuto problemi per tutto il giorno con quello che sembrava essere 404 misfirings.

In ogni caso, ho appena finito di chiacchierare con un DreamHost persona di supporto tecnico che mi ha detto che un account utente che ho con loro è stato colpito limiti delle risorse di memoria di processo (tutti i processi) e che è stato quello che stava causando strana, apparentemente problemi htaccess-correlati. Mi è stato sempre intermittenti 404 errori da un file .htaccess che non avrebbe dovuto essere chiamato a tutti! DreamHost è stato con un server di casa stregata.

A quanto pare, il processo uccidendo robot che usi Dreamhost uccideranno un processo web nel bel mezzo e poi per qualche ragione, la (ormai zombie) apache in realtà cerca di finire il suo lavoro (facendo del suo meglio per uscire in modo pulito fuori alla fine glamour ad una sotto richiesta è la mia ipotesi migliore). getta un errore 500 nel log http principale, ma dopo averlo fatto, in realtà spara la condizione riscrittura e la regola che non dovrebbe mai essere stato licenziato (utilizzando il -f file standard e la directory file .htaccess -d sopra) - e doesn 't scrivere la nuova voce di registro! un nuovo (uomo invisibile) richiesta poi innesca il file di indice nell'ultima riga del file .htaccess

guardatevi i limiti delle risorse a Dreamhost conti di base! se si va oltre i propri limiti, e si dispone di htacess con linee mod_rewrite vedrete cose strane che sono solo si adattano per la notte di halloween - uomini invisibili, 404s infestate! I processi non-morti! zombie apache! .htaccess in movimento da sola! yikes!

Spero che questo aiuti a evitare alcune ore di dolore.

Answer 2

L'unico modo per eseguire il debug di questo è quello di disabilitare un plug-in alla volta, ogni volta cercando di riprodurre il problema prima di disattivare un altro plugin. Inizia con i plugin che hanno qualcosa a che fare con l'amministrazione di WP, quindi spostare verso il basso per regolare i plugin tema, widget e così via.

Ispezionare la "Not Found" pagina che si sono serviti meglio (browse con Opera e aprire il pannello Info che vi mostrerà le intestazioni, in alternativa navigare con Firefox e hanno Firebug con il pannello "Net" abilitato) e fare una ricerca attraverso tutti i plugin per vedere se essi potrebbero essere servendo direttamente. Altrimenti, uno sguardo al registro del server web per scoprire che cosa esattamente risorsa che è in grado di servire; un plugin potrebbe fare un po 'di fantasia reindirizzamento o riscrittura quindi non è necessariamente l'URL che vedi nel tuo browser che sta causando il 404.

Answer 3

posso riguardare solo la mia esperienza, e finora, non ho trovato una regola "definitivo" per correzione tutti problemi in un colpo solo.

Il problema principale con l'installazione di DreamHost è che, in eterna lotta per mantenere il consumo di memoria al minimo, significa sbarazzarsi di molte caratteristiche come possibile - (! Buona per i visitatori) e cioè, tutto ciò che ridurrà la larghezza di banda o CPU (buona per il server, ma DreamHost non controlla il consumo di CPU come aggressivamente come essi controllano RAM). Per esempio, questo significa sbarazzarsi di compresso con gzip HTML + CSS (che consumerà CPU + RAM) o uno qualsiasi dei diversi plugin Minify (che consumerà RAM pure). Il più sofisticato della cache (io sono appassionato di utilizzare W3 Total Cache, o almeno WP Super Cache), il più RAM sarà consumato pure.

Allo stesso modo, molti plugin che limitano il numero di MySQL interroga per migliorare le prestazioni sarà invece consumare RAM. Quindi trovare un trade-off, dove è ancora possibile mantenere il vostro sito rispondendo con buone prestazioni, evitando di consumare RAM prezioso è un compito difficile!

Finora, i miei risultati migliori su siti occupati è quello di deselezionare Page Speed ??Ottimizzazione e Extra Web Security che apparentemente consumano un sacco di RAM, e si basano invece su una combinazione con W3 Total Cache e Cloudflare (servizio gratuito di proxy inverso). Cloudflare sarà effettivamente fare la stessa cosa come il modulo "Extra Web Security", ma dal momento che corre DreamHost di fuori, va bene. W3 Total Cache consuma un sacco di memoria, ma una volta che le pagine sono memorizzate in modo statico a livello locale, Cloudflare sarà molto efficiente nella cache di loro - così si potrebbe ottenere 404/500 durante la modifica di messaggi, almeno i visitatori potranno non li esperienza (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 rispetto CGI 'normale'. E dal momento che PHP 5.3 è meglio a gestire RAM (garbage collection più aggressivo, meno perdite di memoria), ho sperimentalmente passato a PHP 5.3 CGI (non FastCGI) senza Page Speed ??Ottimizzazione né Extra Web Security, basandosi su W3 Total Cache + Cloudflare a accelerare il sito. Ora il backoffice è più lento (più il consumo di CPU!), Ma almeno io non vedo 404/500 (finora!).

Sono ancora infelice con la combinazione, quindi dovrò certamente continuerò a ottimizzare le impostazioni di DreamHost nella speranza di ridurre Consumo RAM ancora di più e ancora ottenere prestazioni adeguate. Come @dgw Detto questo, io uso anche un sacco di plugin - perché ho bisogno di loro funzionalità. Non tutti WP hosting con DreamHost ha semplici, esigenze di blogging; il più complesso il sito, più funzionalità sarà necessario ... e questa è la bellezza di WordPress, è solo bisogno di utilizzare i plugin si ha realmente bisogno, e mantenere il nucleo WP installazione semplice se sei felice con poche esigenze. Plugin, tuttavia, non sono necessariamente "cattivo" o che pesante sul sito; ma è vero che alcuni possono consumare un sacco di RAM ...

Answer 4

Questa è solo una vaga idea: se si ottiene un "vero e proprio" errore 404 (con intestazioni set), allora si potrebbe cercare attraverso i plugin e look per la funzione PHP header() e il numero 404. Questo potrebbe drill-down il numero di plugin da 70 a solo alcuni. Allora avete solo bisogno di verificare la presenza di quelli.

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

Accanto a questo, ma senza alcuna garanzia che funzioni con successo, è quello di scrivere un plugin che ganci in impostazione di intestazione e dando poi si traccia quale codice è in realtà la fissazione di un potenziale 404 (backtrace). Questo funziona solo se il plugin sta usando la funzione di WordPress API. Il primo metodo per cercare la funzione PHP funziona indipendentemente dal WP API.

Answer 5

Più informazioni necessarie:

1) Perché così tanti plugins?

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

3) Quale server web?

4) Non si ha accesso ai log del server httpd, in particolare i log degli errori?

5) Cosa ne dicono i registri degli errori nell'arco di tempo [s] che circonda questi problemi?

(Ora, a dire la verità, se siamo generalizzare per "J6P media in esecuzione WordPress potrebbe avere questa domanda esatta, potremmo iniziare da dirigere detto J6P alla risposta, almeno quanto sopra 5 domande ...)