web-dev-qa-db-de.com

Wie seltsame 404-Fehler in wp-admin zu beseitigen?

Ich betreibe eine WordPress-Seite mit ca. 70 aktiven Plugins.

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

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

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

Bearbeiten:

Hosting-Informationen: DreamHost; Ich denke, auf dem Server läuft ein angepasster Debian-Build mit Apache httpd

8
dgw

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

trotzdem habe ich gerade den Chat mit einer Dreamhost-Support-Person beendet, die mir mitteilte, dass ein Benutzerkonto, über das ich verfüge, die Grenzen der Prozessspeicherressourcen (alle Prozesse) überschreitet und dies zu seltsamen, anscheinend htaccess-bezogenen Problemen führte. Ich bekam zeitweise 404-Fehler aus einer HTAccess-Datei, die eigentlich gar nicht hätte aufgerufen werden dürfen! Es war ein Traumhost mit einem Spukhaus-Server.

anscheinend wird der Prozesskiller-Roboter, den dreamhost verwendet, einen Web-Prozess in der Mitte abbrechen, und dann versucht der (jetzt Zombie-) Apache aus irgendeinem Grund tatsächlich, seinen Job zu beenden (indem er sein Bestes tut, um sauber aus dem unklaren Ende einer Unteranfrage auszusteigen ist meine beste Vermutung). es wirft einen 500-Fehler in das http-Hauptprotokoll, löst dann aber tatsächlich die Umschreibebedingung und -regel aus, die niemals hätte ausgelöst werden dürfen (unter Verwendung der obigen Standarddatei -f und der Verzeichnisdatei -d htaccess) - und tut dies nicht schreibe keinen neuen Logeintrag! Eine neue (unsichtbare) Anfrage löst dann die Indexdatei in der letzten Zeile der htaccess-Datei aus

achte auf die ressourcengrenzen in dreamhost basic accounts! Wenn Sie ihre Grenzen überschreiten und mit Mod_rewrite-Linien arbeiten, werden Sie seltsame Dinge sehen, die nur für die Halloween-Nacht geeignet sind - unsichtbare Männer, heimgesuchte 404er! Untote Prozesse! Zombie Apache! htaccess bewegt sich von alleine! Huch!

ich hoffe, dies hilft Ihnen dabei, einige Stunden Schmerzen zu vermeiden.

6
sophistry

Die einzige Möglichkeit, dies zu debuggen, besteht darin, jedes Mal ein Plugin zu deaktivieren, wenn Sie 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 Theme-Plugins, Widgets und dergleichen.

Überprüfen Sie die Seite "Nicht gefunden", auf der Sie besser bedient werden (durchsuchen Sie mit Opera und öffnen Sie das Infofenster, in dem die Kopfzeilen angezeigt werden. Alternativ können Sie auch mit Firefox und Firebug mit aktiviertem "Net" -Fenster navigieren), und führen Sie eine Suche durch Ihre Plugins, um zu sehen, ob sie es direkt bedienen. Ist dies nicht der Fall, überprüfen Sie das Protokoll des Webservers, um herauszufinden, welche Ressource nicht bereitgestellt werden kann. Ein Plugin führt möglicherweise ein ausgefallenes Umleiten oder Umschreiben durch, sodass es nicht unbedingt die in Ihrem Browser angezeigte URL ist, die den 404 verursacht.

4

Ich kann nur meine eigene Erfahrung erzählen, und bis jetzt 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) verringert für den Server, aber DreamHost steuert den CPU-Verbrauch nicht so aggressiv wie den Arbeitsspeicher. Dies bedeutet zum Beispiel, dass Sie gzip'ed HTML + CSS (das CPU + RAM verbraucht) oder eines der verschiedenen Minify-Plugins (das auch RAM verbraucht) loswerden. Je komplexer der Cache ist (ich verwende gerne W3 Total Cache oder zumindest WP Super Cache), desto mehr RAM werden ebenfalls verbraucht.

In ähnlicher Weise verbrauchen viele Plugins, die die Anzahl der MySQL-Abfragen begrenzen, um die Leistung zu verbessern, stattdessen RAM. Es ist also eine schwierige Aufgabe, einen Kompromiss zu finden, bei dem Ihre Website immer noch mit guter Leistung antwortet, ohne wertvolle RAM zu verbrauchen.

Bisher ist es mein bestes Ergebnis, auf stark frequentierten Websites die Option "Seitengeschwindigkeitsoptimierung und zusätzliche Websicherheit" zu deaktivieren, die anscheinend viel RAM verbraucht, und stattdessen auf eine Kombination mit W3 Total Cache und Cloudflare (kostenloser Reverse-Proxy-Service) zu setzen. Cloudflare macht praktisch dasselbe wie das Modul "Extra Web Security", aber da es außerhalb von DreamHost ausgeführt wird, ist es in Ordnung. W3 Total Cache beansprucht viel Speicher, aber sobald die Seiten statisch lokal gespeichert sind, werden sie von Cloudflare sehr effizient zwischengespeichert - so dass Sie möglicherweise 404/500 erhalten, während Sie Beiträge bearbeiten, zumindest werden Ihre Besucher sie nicht bemerken (Cloudflare kann auch statische Seiten bedienen auch wenn DreamHost eine 404 oder 500 gibt).

Auch dank diesem Artikel habe ich herausgefunden, dass FastCGI mehr RAM als 'normales' CGI verwendet. Und da PHP 5.3 das Verwalten von RAM (aggressivere Speicherbereinigung, weniger Speicherlecks) besser beherrscht, habe ich experimentell auf PHP 5.3 CGI (nicht FastCGI) umgestellt ) ohne Seitengeschwindigkeitsoptimierung und ohne zusätzliche Web-Sicherheit, die sich auf W3 Total Cache + Cloudflare stützt, um die Site zu beschleunigen. Jetzt ist das Backoffice langsamer (mehr CPU-Verbrauch!), Aber zumindest sehe ich 404/500 (bis jetzt!) Nicht.

Ich bin immer noch unzufrieden mit der Kombination, daher fahre ich mit der Einstellung von Tweak DreamHost fort, in der Hoffnung, die Belastung durch RAM noch weiter zu reduzieren und trotzdem eine angemessene Leistung zu erzielen. Wie @dgw schon sagte, benutze ich auch viele Plugins - weil ich deren Funktionalität benötige. Nicht jeder, der WP mit DreamHost hostet, hat einfache Anforderungen an das Bloggen. Je komplexer die Site, desto mehr Funktionalität wird benötigt ... und das ist das Schöne an WordPress. Sie müssen nur die Plugins verwenden, die Sie wirklich benötigen, und die WP Kerninstallation einfach halten, wenn Sie möchten zufrieden mit wenigen Bedürfnissen. Plugins sind jedoch nicht unbedingt "schlecht" oder so schwer auf der Website; aber es ist wahr, dass einige viel RAM verbrauchen können ...

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 Funktion PHP header() und der 404-Nummer suchen . Dies könnte die Anzahl der Plugins von 70 auf einige reduzieren. Dann müssen Sie nur noch nach diesen suchen.

Dies kann auf einfache Weise mit einem IDE wie Eclipse PDT geschehen, der die Suche nach einem bestimmten PHP Funktionsaufruf ermöglicht.

Darüber hinaus müssen Sie ein Plug-in schreiben, das sich in die Header-Einstellung einhakt, und dann nachverfolgen, welcher Code tatsächlich ein Potential von 404 (Backtrace) setzt. Dies ist jedoch keine Garantie dafür, dass das Plug-in erfolgreich funktioniert. Dies würde nur funktionieren, wenn das Plugin die WordPress-API-Funktion verwendet. Die erste Methode, die nach der Funktion PHP sucht, funktioniert unabhängig von der API WP.

3
hakre

Weitere Informationen benötigt:

1) Warum so viele Plugins?

2) Auf welchem ​​Betriebssystem läuft Ihr Hosting-Anbieter?

3) Welcher Webserver?

4) Haben Sie Zugriff auf die Protokolle des httpd-Servers, insbesondere auf die Fehlerprotokolle?

5) Was sagen die Fehlerprotokolle in dem Zeitrahmen, in dem diese Probleme auftreten?

(Nun, um ehrlich zu sein, wenn wir allgemein sagen, dass "durchschnittliches J6P, das WordPress ausführt, genau diese Frage haben könnte, könnten wir zuerst das J6P anweisen, mindestens die obigen 5 Fragen zu beantworten ...)

2
ZaMoose