Wie kann man seltsame 404-Fehler in wp-admin beseitigen?

8

Ich betreibe eine WordPress-Site mit ungefähr 70 aktiven Plugins.

Von Zeit zu Zeit erhalte ich eine zufällige Fehlerseite ("Nicht gefunden", obwohl ich die Überschriften nicht überprüft habe, um festzustellen, ob es sich um eine 404 handelt) auf einer /wp-admin/Seite, die aus dem Nichts auftaucht.

Ein einfacher erneuter Versuch behebt den Fehler. Es ist jedoch recht unpraktisch, wenn der Fehler während eines Plugin-Upgrades auftritt (da die automatische Reaktivierung fehlschlägt). Ich denke, dasselbe Problem ist dafür verantwortlich, dass bestimmte Module in meinem Dashboard manchmal nicht geladen werden können.

Kennt jemand angesichts der Liste der von mir installierten Plugins Probleme mit oder zwischen diesen, die dieses Problem verursachen könnten?

Bearbeiten:

Hosting-Informationen: DreamHost; Ich denke, der Server führt einen benutzerdefinierten Debian-Build mit Apache httpd aus

dgw
quelle
1
Keine PITA zu sein, aber dies ist wirklich ein Support-Problem und nicht etwas, das wir hier behandeln würden. Ich werde abstimmen, um zu schließen. Fragen Sie stattdessen unter http://wordpress.org/support nach . Wenn Sie einige Tests durchführen und Ihre Frage so einschränken, dass sie nicht nur auf Ihre Situation anwendbar ist, kann dies hier eine akzeptable Frage darstellen. Auch hier tut es mir leid, dass dies so ist, aber wir WordPress-Antworten sollten für alle Benutzer gelten, und unzählige Supportanfragen werden dies zunichte machen.
MikeSchinkel
Ich stimme zu, also werde ich abstimmen, um auch zu schließen.
Ben Everard
1
Einverstanden. Abstimmung zum Schließen als zu lokalisiert.
John P Bloch
2
Ich stimme nicht zu schließen. Viele WP-Neulinge können in WP-Admin auf 404-Fehler stoßen, und letztendlich kommt es zu einem Fehler in einem Plugin oder Theme oder zu deren Auswirkung auf eine Umschreiberegel (entweder in der Datenbank in wp-options oder in der gespeichert). htaccess-Datei). Stattdessen sollten wir allgemeine Schritte zur Fehlerbehebung bereitstellen, mit denen der Problembereich viel schneller identifiziert werden kann.
Volomike
Nun, auch wenn dies eher eine Support-Frage ist, enthält es genügend Informationen, um zumindest einige Möglichkeiten zur schnellen Lösung des Problems vorzuschlagen.
hakre

Antworten:

6

Ich hatte den ganzen Tag Probleme mit 404 Fehlzündungen.

Jedenfalls habe ich gerade den Chat mit einer Person des technischen Supports von dreamhost beendet, die mir erzählte, dass ein Benutzerkonto, das ich bei ihnen habe, die Grenzen der Prozessspeicherressourcen (alle Prozesse) erreicht hat und dass dies seltsame, scheinbar mit dem Zugriff verbundene Probleme verursacht hat. Ich habe zeitweise 404-Fehler von einer htaccess-Datei erhalten, die überhaupt nicht hätte aufgerufen werden dürfen! Es war ein Traumhost mit einem Spukhausserver.

Anscheinend wird der Prozess-Tötungsroboter, den Dreamhost verwendet, einen Web-Prozess in der Mitte beenden, und dann versucht der (jetzt Zombie-) Apache aus irgendeinem Grund tatsächlich, seine Arbeit zu beenden (indem er sein Bestes tut, um sauber aus dem unscheinbaren Ende einer Unteranforderung herauszukommen) ist meine beste Vermutung). Es wirft einen 500-Fehler in das http-Hauptprotokoll, löst jedoch tatsächlich die Umschreibbedingung und -regel aus, die niemals hätte ausgelöst werden dürfen (unter Verwendung der Standarddatei -f und des Verzeichnisses -d htaccess-Datei oben) - und dies nicht Schreibe keinen neuen Protokolleintrag! Eine neue (unsichtbare) Anforderung löst dann die Indexdatei in der letzten Zeile der htaccess-Datei aus

Vorsicht vor den Ressourcenbeschränkungen in Dreamhost-Basiskonten! Wenn Sie über ihre Grenzen hinausgehen und Probleme mit mod_rewrite-Zeilen haben, werden Sie seltsame Dinge sehen, die nur für Halloween-Nächte geeignet sind - unsichtbare Männer, heimgesuchte 404er! untote Prozesse! Zombie Apache! htaccess bewegt sich von selbst! Huch!

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


quelle
Ich habe definitiv eine Menge mod_rewriteSachen in meinen .htaccessAkten. Klingt so, als würde mir das passieren. Ich wusste, dass ich mit meinen Sicherungsjobs an Speichergrenzen gestoßen bin, aber nicht für "echte" Anfragen. Vielen Dank für Ihre Erfahrungen. Hoffentlich spart Ihre Antwort vielen Menschen Zeit.
dgw
Es ist nicht nur Dreamhost. Ich bin von Dreamhost auf einen anderen privaten Server umgezogen und habe immer noch dieses Problem.
Supertrue
4

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 etwas mit der Verwaltung von WP zu tun haben, und wechseln Sie dann zu regulären Themen-Plugins, Widgets und dergleichen.

Überprüfen Sie die Seite "Nicht gefunden", auf der Sie besser bedient werden (navigieren Sie mit Opera und öffnen Sie das Infofenster, in dem die Überschriften angezeigt werden, oder navigieren Sie mit Firefox und lassen Sie Firebug mit aktiviertem "Netz" -Panel aktivieren) und durchsuchen Sie alle Ihre Plugins, um zu sehen, ob sie es möglicherweise direkt bereitstellen. Wenn nicht, sehen Sie sich das Protokoll des Webservers an, um herauszufinden, welche Ressource genau nicht bedient werden kann. Ein Plugin führt möglicherweise eine ausgefallene Umleitung oder Umschreibung durch, sodass nicht unbedingt die URL, die Sie in Ihrem Browser sehen, den 404 verursacht.

Asbjørn Ulsberg
quelle
Bei 70 Plugins wäre es wirklich ordentlich, wenn man einen Weg finden könnte, dies superschnell zu tun, ohne jedes manuell deaktivieren und testen zu müssen, beispielsweise mit einer Plugin-Tester-Datei.
Volomike
Ich sehe, Sie haben Ihre ursprüngliche Antwort mit einem tollen Tipp bearbeitet, um die Antwort schneller zu finden.
Volomike
Danke, asbjornu. Ich werde mich darum kümmern, nachdem ich mit meiner Familie aus dem Urlaub zurückgekommen bin.
dgw
Ich habe die Serverprotokolle durchgesehen und konnte nichts Spezifischeres als "Vorzeitiges Ende des Skript-Headers" finden.
Ich
3

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

Das Hauptproblem bei der Einrichtung von DreamHost besteht darin, dass im ewigen Kampf um die Minimierung des Speicherverbrauchs so viele Funktionen wie möglich entfernt werden müssen - nämlich alles, was die Bandbreite (gut für die Besucher!) Oder die CPU (gut) reduziert für den Server, aber DreamHost steuert den CPU-Verbrauch nicht so aggressiv wie den Arbeitsspeicher. Dies bedeutet zum Beispiel, dass gzip'ed HTML + CSS (das CPU + RAM verbraucht) oder eines der verschiedenen Minify-Plugins (das auch RAM verbraucht) entfernt wird. Je ausgefeilter der Cache ist (ich verwende gerne W3 Total Cache oder zumindest WP Super Cache), desto mehr RAM wird ebenfalls verbraucht.

In ähnlicher Weise verbrauchen viele Plugins, die die Anzahl der MySQL-Abfragen zur Verbesserung der Leistung begrenzen, stattdessen RAM. Es ist daher eine schwierige Aufgabe, einen Kompromiss zu finden, bei dem Sie Ihre Website weiterhin mit guter Leistung beantworten und gleichzeitig vermeiden können, wertvollen Arbeitsspeicher zu verbrauchen!

Bisher besteht mein bestes Ergebnis auf ausgelasteten Websites darin, die Option "Seitengeschwindigkeitsoptimierung" und "Zusätzliche Web-Sicherheit" zu deaktivieren, die anscheinend viel RAM verbrauchen, und stattdessen eine Kombination mit W3 Total Cache und Cloudflare (kostenloser Reverse-Proxy-Dienst) zu verwenden. Cloudflare macht effektiv dasselbe wie das Modul "Extra Web Security", aber da es außerhalb von DreamHost ausgeführt wird, ist es in Ordnung. W3 Total Cache verbraucht viel Speicher, aber sobald die Seiten lokal statisch gespeichert sind, werden sie von Cloudflare sehr effizient zwischengespeichert. Wenn Sie also Beiträge bearbeiten, erhalten Sie möglicherweise 404/500, zumindest Ihre Besucher werden sie nicht bemerken (Cloudflare kann auch statische Seiten bereitstellen auch wenn DreamHost eine 404 oder eine 500 gibt).

Dank dieses Artikels habe ich auch herausgefunden, dass FastCGI mehr RAM als "normales" CGI verwendet. Und da PHP 5.3 besser in der Lage ist, RAM zu verwalten (aggressivere Speicherbereinigung, weniger Speicherlecks), habe ich experimentell auf PHP 5.3 CGI (nicht FastCGI) ohne Seitengeschwindigkeitsoptimierung oder zusätzliche Websicherheit umgestellt und mich dabei auf W3 Total Cache + Cloudflare verlassen beschleunigen Sie die Website. Jetzt ist das Backoffice langsamer (mehr CPU-Verbrauch!), Aber zumindest sehe ich 404/500 (bisher!) Nicht.

Ich bin immer noch unzufrieden mit der Kombination, daher werde ich die Einstellungen von DreamHost sicherlich weiter optimieren, in der Hoffnung, den RAM-Verbrauch noch weiter zu reduzieren und dennoch eine angemessene Leistung zu erzielen. Wie @dgw sagte, verwende ich auch viele Plugins - weil ich deren Funktionalität benötige. Nicht jeder, der WP mit DreamHost hostet, hat einfache Blogging-Anforderungen. Je komplexer die Site ist, desto mehr Funktionen werden benötigt ... und das ist das Schöne an WordPress. Sie müssen nur die Plugins verwenden, die Sie wirklich benötigen, und die Installation des Kern-WP einfach 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 verbrauchen können ...

Gwyneth Llewelyn
quelle
3

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

Dies kann einfach mit einer IDE wie Eclipse PDT durchgeführt werden, die die Suche nach einem bestimmten PHP-Funktionsaufruf bietet.

Daneben, aber ohne Garantie dafür, dass es erfolgreich funktioniert, müssen Sie ein Plugin schreiben, das sich in die Header-Einstellung einhakt, und dann verfolgen, welcher Code tatsächlich ein potenzielles 404 (Backtrace) setzt. Dies würde nur funktionieren, wenn das Plugin die WordPress-API-Funktion verwendet. Die erste Methode, um nach der PHP-Funktion zu suchen, funktioniert unabhängig von der WP-API.

hakre
quelle
Das klingt vielversprechend. Nach meinem Urlaub noch etwas anderes zu beachten. :)
dgw
Ich habe es geschafft, noch außerhalb der Stadt nachzuschauen, und habe nur festgestellt, dass mein Backup-Plugin die Ausgabe eines 404 zu fordern scheint. Firebug zeigt jedoch, dass es sich wirklich um einen 404 handelt. Einige Fortschritte ... Allerdings habe ich jetzt Probleme, das Problem auszulösen, also mache ich wohl eine Pause. Ich hasse zeitweise Fehler!
dgw
2

Weitere Informationen erforderlich:

1) Warum so viele Plugins?

2) Auf welchem ​​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 in den Zeitrahmen, die diese Probleme betreffen?

(Um ehrlich zu sein, wenn wir verallgemeinern, dass "durchschnittliches J6P, auf dem WordPress ausgeführt wird, möglicherweise genau diese Frage hat, können wir das besagte J6P zunächst anweisen, mindestens die oben genannten 5 Fragen zu beantworten ...)

ZaMoose
quelle
Ich habe all diese Plugins, weil ich die Funktionen verwende, die sie erfüllen. warum sonst? Die Fehlerprotokolle sagen überhaupt nicht viel aus. Ich bin auf DreamHost, daher denke ich, dass auf dem Server ein benutzerdefiniertes Debian-Build mit Apache httpd ausgeführt wird.
dgw
Jetzt, wo Sie es erwähnen, sehe ich auch diese zufälligen Fehler auf meinen DH-Sites. Dies tritt insbesondere dann auf, wenn ich versuche, in meinen MS-Installationen ein Netzwerk-Upgrade durchzuführen und den Importer auszuführen. Seltsam.
ZaMoose