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

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

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.

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.

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 ...

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.

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 ...)