Wie kann man seltsame 404-Fehler in WP-Adminalist beseitigen?

Question

Ich führe eine WordPress -Site mit ungefähr 70 aktiven Plugins aus.

Ab und zu bekomme ich eine zufällige Fehlerseite ("nicht gefunden", obwohl ich die Header nicht überprüft habe, um zu sehen, ob es sich um 404 handelt) auf a /wp-admin/ Seite, die aus dem Nichts auftaucht.

Einfach erneut versuchen, den Fehler aufzulösen. Es ist jedoch ziemlich unpraktisch, wenn der Fehler während eines Plugin-Upgrades auftritt (da die automatische Reaktivierung fehlschlägt). Ich denke, dasselbe Problem ist für bestimmte Module in meinem Dashboard verantwortlich, das manchmal nicht geladen wird.

Angesichts der Liste der Plugins, die ich installiert habe, Kennt jemand Probleme mit oder zwischen ihnen, die dieses Problem verursachen könnten?

Bearbeiten:

Hosting Info: DreamHost; Ich denke

Answer 1

Ich hatte den ganzen Tag Probleme mit einer scheinbar 404 Fehlfeind.

Wie auch immer, ich habe gerade mit einer Dreamhost Tech-Support-Person geplaudert, die mir sagte, dass ein Benutzerkonto, das ich mit ihnen habe, die Ressourcenbeschränkungen für Prozessspeicher (alle Prozesse) erreicht habe, und das verursachte seltsame, scheinbar HTaccess-bezogene Probleme. Ich habe zeitweise 404 Fehler aus einer HTaccess -Datei erhalten, die überhaupt nicht hätte angerufen werden dürfen! Es war Dreamhost mit einem Spukhausserver.

Anscheinend wird der Prozess, der Roboter tötet, den DreamHost verwendet ist meine beste Vermutung). Es bringt einen 500 -Fehler in das Haupt -HTTP -Protokoll aus, aber danach wird tatsächlich die Umschreibung und Regel umschreiben, die niemals abgefeuert werden dürfen Ich schreibe keinen neuen Protokolleintrag! Eine neue (unsichtbare Mann) Anfrage löst dann die Indexdatei in der letzten Zeile der HTAccess -Datei aus

Achten Sie auf die Ressourcengrenzen in Dreamhost Basic Accounts! Wenn Sie ihre Grenzen durchgehen und Htacess mit Mod_rewrite -Linien haben, werden Sie seltsame Dinge sehen, die nur für Halloween -Nacht geeignet sind - unsichtbare Männer, Haunted 404s! untote Prozesse! Zombie Apache! Htaccess bewegt sich von selbst! Yikes!

Ich hoffe, dies hilft Ihnen, einige Stunden Schmerzen zu vermeiden.

Answer 2

Die einzige Möglichkeit, dies zu debuggen, besteht darin, jeweils ein Plugin zu deaktivieren und jedes Mal zu versuchen, das Problem zu reproduzieren, bevor Sie ein anderes Plugin deaktivieren. Beginnen Sie mit den Plugins, die mit der Verwaltung von WP etwas zu tun haben, und gehen Sie dann zu regulären Themen -Plugins, Widgets und so weiter.

Überprüfen Sie die Seite "Nicht gefunden", die Sie besser bedienen (stöbern Sie mit Opera und öffnen Sie das Info -Panel, das Ihnen die Header zeigt, alternativ mit Firefox stöbern und Firebug mit dem "Netz" -Panel aktiviert) Ihre Plugins, um zu sehen, ob sie es möglicherweise direkt bedienen. Wenn nicht, schauen Sie sich das Protokoll des Webservers an, um herauszufinden, welche genaue Ressource es nicht dienen kann. Ein Plugin könnte ein ausgefallenes Umleitungs- oder Umschreiben durchführen, daher ist es nicht unbedingt die URL, die Sie in Ihrem Browser sehen, das den 404 verursacht.

Answer 3

Ich kann nur meine eigenen Erfahrungen erzählen, und bisher habe ich keine "definitive" Regel gefunden, um sie zu beheben alle Probleme bei einem Schlag.

Das Hauptproblem bei DreamHosts Setup ist, dass im ewigen Kampf um den Gedächtnisverbrauch mindestens so viele Merkmale wie möglich beseitigt werden müssen - nämlich alles, was die Bandbreite (gut für die Besucher!) Oder CPU (gut (gut Für den Server, aber DreamHost kontrolliert den CPU -Konsum nicht so aggressiv, wie sie den RAM steuern. Dies bedeutet beispielsweise, dass Sie GZIP'Ed HTML + CSS (die CPU + RAM verbrauchen) oder eines der verschiedenen Minify -Plugins (die auch RAM konsumieren) oder ein der verschiedenen Minify -Plugins loswerden. Je ausgefeilter der Cache (ich benutze den W3 -Gesamt -Cache oder zumindest zumindest WP Super Cache), desto mehr RAM wird auch verbraucht.

In ähnlicher Weise werden viele Plugins, die die Anzahl der MySQL -Abfragen zur Verbesserung der Leistung einschränken, stattdessen RAM verbrauchen. Wenn Sie also einen Kompromiss finden, in dem Sie Ihre Website noch mit guter Leistung beantworten können, um einen kostbaren Ram zu vermeiden, ist es eine schwierige Aufgabe!

Bisher sind meine besten Ergebnisse auf geschäftigen Websites die Optimierung der Seitengeschwindigkeit und die zusätzliche Websicherheit, die anscheinend viel RAM konsumieren und stattdessen auf eine Kombination mit W3 Total Cache und CloudFlare (kostenloser Reverse -Proxy -Dienst) angewiesen sind. CloudFlare wird effektiv dasselbe wie das Modul "Extra Web Security" tun, aber da es außerhalb von DreamHost läuft, ist es in Ordnung. W3 Total Cache konsumiert viel Speicher, aber sobald die Seiten lokal statisch gespeichert sind, wird Cloudflare sie sehr effizient ausspeichern. Sie erhalten also möglicherweise 404/500, während Sie Posts bearbeiten. Zumindest Ihre Besucher erleben sie nicht (Cloudflare kann auch statische Seiten servieren, die statische Seiten servieren können Auch wenn Dreamhost einen 404 oder 500 gibt).

Auch danke an Dieser Artikel, Ich habe herausgefunden, dass Fastcgi mehr RAM als "normale" CGI verwendet. Und da PHP 5.3 das RAM besser verwaltet (aggressivere Müllsammlung, weniger Speicherlecks), habe ich experimentell auf PHP 5.3 CGI (nicht FASTCGI) ohne Seitengeschwindigkeitoptimierung oder zusätzliche Websicherheit gewechselt, wobei ich mich auf W3 Total Cache + Cloudflare verlässt Beschleunigen Sie die Website. Jetzt ist der Backoffice langsamer (mehr CPU -Verbrauch!), Aber zumindest sehe ich 404/500 (bisher!).

Ich bin immer noch unzufrieden mit der Kombination, also werde ich die Einstellungen von DreamHost sicherlich weiterhin optimieren, in der Hoffnung, den RAM -Konsruption noch mehr zu reduzieren und trotzdem angemessene Leistung zu erzielen. Wie @DGW sagte, verwende ich auch viele Plugins - weil ich ihre Funktionalität benötige. Nicht jeder, der WP mit DreamHost veranstaltet, hat einfache, bloggende Bedürfnisse. Je komplexer die Website ist, desto mehr Funktionen benötigt es ... und das ist die Schönheit von WordPress, Sie müssen nur die Plugins verwenden, die Sie wirklich benötigen, und die Kern -WP -Installation einfach zu halten, wenn Sie mit wenigen Anforderungen zufrieden sind. Plugins sind jedoch nicht unbedingt "schlecht" oder so schwer auf der Website. Aber es ist wahr, dass einige viel Ram konsumieren können ...

Answer 4

Dies ist nur eine grobe Idee: Wenn Sie einen "echten" 404 -Fehler (mit festgelegten Headern) erhalten, können Sie Ihre Plugins durchsuchen und nach dem suchen Php header() Funktion und die 404 -Nummer. Dies könnte die Anzahl der Plugins von 70 auf nur einige bohren. Dann müssen Sie nur nach diesen überprüfen.

Dies kann einfach mit einer IDE wie Eclipse PDT erfolgen, die nach einem bestimmten PHP -Funktionsaufruf suchen kann.

Daneben ist es jedoch ohne Garantie, dass es erfolgreich funktioniert, ein Plugin, das sich in die Headereinstellung einbindet und Ihnen dann einen Trace gibt, welcher Code tatsächlich einen potenziellen 404 (Backtrace) einstellt. Dies würde nur dann funktionieren, wenn das Plugin die WordPress -API -Funktion verwendet. Die erste Methode, um die PHP -Funktion zu suchen, funktioniert unabhängig von der WP -API.

Answer 5

Weitere Informationen benötigt:

1) Warum so viele Plugins?

2) Welches Betriebssystem läuft Ihr Hosting -Anbieter?

3) Welcher Webserver?

4) Haben Sie Zugriff auf die HTTPD -Serverprotokolle, insbesondere auf die Fehlerprotokolle?

5) Was sagen die Fehlerprotokolle im Zeitrahmen, der diese Probleme umgibt?

(Nun, um ehrlich zu sein, wenn wir uns über "durchschnittliche J6P -Laufen -WordPress" verallgemeinern, könnten wir damit beginnen, dass J6P mindestens die oben genannten 5 Fragen beantwortet ...)