Notice: wpdb::escape is deprecated since version 3.6! Use wpdb::prepare() or esc_sql() instead.

Nach dem Update auf WordPress 3.6 prangt nun auf allen Seiten die Fehlermeldung:

Notice: wpdb::escape is deprecated since version 3.6! Use wpdb::prepare() or esc_sql() instead.

Weiterlesen: Notice: wpdb::escape is deprecated since version 3.6! Use wpdb::prepare() or esc_sql() instead.

Nach Login im Admin wird nur eine weisse Seite angezeigt, wie kann ich die Ursache finden?

WordPress leere Seite nach Aufruf des adminsWenn an dieser Stelle nur eine weiße Seite angezeigt wird, bedeutet dies, dass die Anzeige der Fehlermeldungen ausgeschaltet ist. Das ist auch gut so, denn im Falle eines Fehlers könnte so ein Hacker Informationen erhalten, die es ihm ermöglichen die Seite anzugreifen.

Aktuell wäre diese Fehlermeldung allerdings sehr hilfreich!

Nun gibt es 2 Möglichkeiten

ErrorLog auf dem Server lesen

Je nach Webspace und Einrichtung von WordPress benötigt man für das Lesen der ErrorLog entsprechende Rechte. Bei meinem virtuellen Server liegen die ErrorLogs im Verzeichnis statistics/logs, also außerhalb des Webspaces, was aus Sicherheitsgründen sinnvoll ist. Auf dieses Verzeichnis hat der normale FTP keinen Zugriff. Da ich selbst der Webmaster meines Webservers bin, habe ich natürlich Zugriff und kann die Log-Datei lesen.

 

 

Alternativ dazu kann man auch:

die Fehlermeldungen zurzfristig - nur für die Fehlersuche - einschalten

Dazu einfach den nachfolgenden Code in die Datei wp-config.php im Hauptverzeichnis einfügen.

// Gibt an welche PHP-Fehler angezeigt werden
// error_reporting(E_ALL | E_STRICT); // einschl. Warnungen und Strict-Fehler 
error_reporting(E_ALL ^ E_NOTICE);
// Um die Fehler auf dem Bildschirm auszugeben
ini_set('display_errors', 1);

Die Fehlermeldung

Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 30720 bytes) in /xxx/xxx/xxx/blog/wp-admin/includes/update.php on line 107

Der Server meldet, dass er mehr Speicher benötigt, als zugeteilt ist. Oft sind dafür neu installierte "speicherfressende" Plugins verantwortlich. Aber in diesem Fall ist es das update! von WordPress. Das Update selbst muss dabei nicht unbedingt übermäßig viel Speicher benötigen, sondern mit dem Update ist die Summe des benötigten Speichers zu groß.

In meinem Beispiel hat das "deaktivieren" aller Plugins durch das Umbennen des Plugin-Verzeichnisses, wie an anderer Stelle empfohlen, keinen Effekt gezeigt.

Massnahmen

Wert für erlaubten Speicher erhöhen, dazu den folgenden Code in die Datei wp-config.php im Hauptverzeichnis einfügen.

// Gibt an welche PHP-Fehler angezeigt werden
define('WP_MEMORY_LIMIT', '64M');

 

Im aktuellen Fall hat diese Maßnahme geholfen. Trotzdem bleibt da ein ungutes Gefühl, wenn ich auf meinem virtuellen Server ca. 20-30 Doamins laufen lasse, dann kann ich nicht bei jeder Domain jedesmal das Limit anheben. Igendwann ist dann der Server dicht und es geht gar nichts mehr.

"Den Speicherfresser" habe ich nicht gefunden, also bleibt die Einstellung so.

Weiterführende Informationen

http://faq.wordpress-deutschland.org/exhausted-php-memory/

Unterkategorien

^