WordPress. Probleme & Lösungen

FAQ zu bekannten Problemen in WP. von Design4u.


In unserer täglichen Arbeit als WordPress-Agentur haben wir es immer wieder mit typischen Problemen bei WordPress zu tun. Hier bieten wir Ihnen eine Sammlung von Problemen aus unserer Praxis und deren Lösung.

Ein Backup vor jeder Änderung

Die von uns angebotenen Lösungen verstehen sich als grobe Anhaltspunkte und haben keinen Anspruch auf Ausschließlichkeit. Wir übernehmen ausdrücklich keine Haftung für etwaige Schäden. Wir empfehlen grundsätzlich vor den Änderungen immer ein Backup von den Dateien und der Datenbank durchzuführen!

1. Ein Upgrade-Problem. Weiße Seite in wp-admin/upgrade.php?_wp_http_referer=%2Fwp-admin%2F

WordPress zeigt nach einem automatischen Upgrade nur noch eine leere Seite beim Versuch das Backend zu erreichen (unter /wp-admin/ oder wp-login.php) Das Frontend lässt sich problemlos öffnen. Man bleibt bei folgender (oder ähnlicher) URL hängen: „wp-admin/upgrade.php?_wp_http_referer=%2Fwp-admin%2F“. Das Problem trat in unserer Praxis mehrmals nach dem automatischen Update auf WordPress Version 3.5.2, aber besonders auf die Version 4.7 auf.

Upgrade wp-http-referer

WordPress Upgrade wp-http-referer Problem

 
Das Problem tritt möglicherweise auf, weil das Feld db_version in der Datenbank-Tabelle wp_options und die Variable wp_db_version in der Datei /wp-includes/version.php nicht übereinstimmen. In einem Fall (ein Upgrade auf 3.5.2) zeigte die Datenbank „37965“, während die PHP-Datei „38590“ zeigte. Das Ändern der Variable in der Datenbank in „38590“ hat das Problem gelöst.

Mit der Webanwendung zur Datenbankverwaltung Ihrer Wahl, beispielsweise phpMyAdmin oder Adminer, die von WordPress verwendete Datenbank öffnen und in der Tabelle wp_options erst alle Felder anzeigen lassen. Das Feld db_version finden.
Upgrade wp-http-referer Problem

Upgrade wp-http-referer Problem. Richtige Datenbank-Tabelle finden

 

Mit dem FTP-Client Ihrer Wahl, beispielsweise FileZilla oder FlashFXP, die Datei version.php im Verzeichnis /wp-includes/ finden und öffnen. Dort den Wert $wp_db_version finden und sich merken oder notieren.

Upgrade wp-http-referer Problem

Upgrade wp-http-referer Problem. Den Wert in der version.php finden.

 

In der Datenbank -> wp_options -> db_version den Wert bearbeiten und mit dem Wert aus der PHP-Datei überschreiben.

Upgrade wp-http-referer Problem.

Upgrade wp-http-referer Problem. Den Wert anpassen.

 

2. Kein Upload möglich. Die hochgeladene Datei konnte nicht nach wp-content/uploads verschoben werden

Versucht man eine Bilddatei über den Button „Dateien hinzufügen“ im WordPress-Editor oder auch über den Navigationspunkt „Medien“ im WordPress-Backend hochzuladen, kommt eine Fehlermeldung „Die hochgeladene Datei konnte nicht nach wp-content/uploads/… verschoben werden“

Medien hochladen Problem

Medien hochladen Problem

 
  • Das Verzeichnis „/wp-content/uploads“ und/oder seine Unterverzeichnisse besitzen keine richtigen Schreibrechte
  • Der zur Verfügung stehende Speicherplatz auf dem Hosting ist voll (relativ selten)
  • Umlaute oder Sonderzeichen im Dateinamen vorhanden (unwahrscheinlich)
  • „Safe Mode“ ist auf dem Server aktiv (unwahrscheinlich)
  • Die Verzeichnisse müssen „755“ Rechte haben
  • Die Verzeichnisse müssen dem FTP Benutzer gehören
  • Wenn das nicht hilft ggf. nicht kontrolliert werden kann, sollten die Verzeichnisrechte von „/wp-content/uploads“ und. ggf. Unterverzeichnissen auf „777“ gesetzt werden. Dazu klickt man meistens im FTP-Programm Ihrer Wahl mit der rechten Maustaste auf den Ordner „/wp-content/uploads“ und wählt etwas wie „Attribute“, „CHMOD“ oder „Berechtigungen“ und ändert man die Zahl auf „777“. Dieser Schritt hilft auch gegen „Safe Mode“ auf dem Server.
  • Wenn das nicht hilft, sollte man ggf. zusammen mit dem Hoster kontrollieren, ob die Disk Quota erreicht ist (Speicherplatz voll ist)
  • PS. Eine Datei sollte sowieso keine Umlaute und/oder Sonderzeichen beinhalten – das ist nicht praktikabel. Also meiden Sie sie bzw. ersetzen durch „ae“, „oe“, „ue“ und „ss“

3. Fatal error: Allowed memory size of 33554432 bytes exhausted

Ein sehr häufig aufgetretenes Problem. Seit 2009 und auch im Jahre 2017 wird diese Frage gefühlt einmal wöchentlich in unterschiedlichen Foren immer wieder gestellt. Man bekommt eine weiße Seite in WordPress zu sehen und eine einzige Fehlermeldung: „Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 19456 bytes) in…„, dabei kann die Datei, die dabei angesprochen wird, jede Beliebige sein.

Der Fehler kann dann, nach dem Versuch eine Datei hochzuladen, auftreten, aber meistens nach einem WordPress Update. Dabei kann es auch vorkommen, dass sich das Frontend problemlos öffnen lässt, das Backend jedoch nicht.

Allowed memory size

Allowed memory size

 
Eine gute Nachricht: es gibt einen einzigen Grund, aus welchem dieser Fehler in WordPress auftritt. Und zwar liegt es am niedrigen PHP-Speicherlimit. Um den Fehler zu lösen, muss das PHP-Speicherlimit erhöht werden.
Man fragt sich vielleicht als erstes, wie kann man PHP memory limit auslesen? Das geht relativ einfach: man erstellt mit dem Text-Editor Ihrer Wahl, beispielsweise einfachem Windows Notepad oder Notepad++ eine Datei und man speichert sie beispielsweise unter „info.php“. Den Dateinamen kann man beliebig wählen, die Dateiendung muss jedoch „.php“ sein.

In diese Datei fügen Sie folgenden Code ein:

<?php phpinfo(); ?>

Diese Datei lädt man im Root-Verzeichnis der Webpräsenz hoch und ruft man einfach im Browser auf, beispielsweise https://www.example.com/info.php
Dann suchen Sie mit der Tastenkombination „STRG+F“ auf dieser Website nach „memory_limit“. Das ist Ihr PHP memory limit.

PHP Memory Limit auslesen

PHP Memory Limit auslesen

 

Folgendermaßen lässt sich das das PHP-Speicherlimit erhöhen:

  • 1. Eine gängige Lösung, die Ihnen wahrscheinlich nicht hilft, besteht darin, dass vor der Zeile, die den Fehler verursacht, folgender Code eingesetzt wird: ini_set('memory_limit', '-1');. Der Code bringt den Server dazu, den ganzen Speicher in dem Moment freizugeben. Das wird jedoch dazu führen, das der „Allowed memory size of“ – Fehler in einer anderen Datei erneut auftauchen wird.
  • 2. Im Root-Ordner Ihrer WordPress-Webpräsenz befindet sich eine Datei namens „.htaccess“. Diese öffnet man und fügt am Anfang folgenden Code ein: php_value memory_limit 128M
  • 3. Sollte das nicht helfen, findet man in der Datei wp-config.php im Root-Verzeichnis Ihres WordPress folgende Zeile: /* That's all, stop editing! Happy blogging. */.
    Vor dieser Zeile fügen Sie folgendes ein:define('WP_MEMORY_LIMIT', '128M');
  • 4. Im Ordner wp-admin erstellen Sie eine Datei namens php.ini. Fügen Sie in die Datei folgenden Code ein: memory_limit = 64M
  • 5. Wenn keine der Lösungen hilft, müssen Sie sich in Verbindung mit Ihrem Hoster setzen, um das PHP-Speicherlimit zu erhöhen.

4. Warning: Cannot modify header information – headers already sent by (output started at)

Der Fehler „Warning: Cannot modify header information“ tritt in mehreren Situationen ans Tageslicht. Direkt nach einer Neuinstallation von WordPress. Nach der Installation von einem neuen Theme. Nach manuellen Änderungen in WordPress-Dateien im Editor (besonders anfällig für den „Cannot modify header information“-Fehler sind erfahrungsgemäß wp-config.php und functions.php) und so weiter.

Warning: Cannot modify header information – headers already sent

Warning: Cannot modify header information – headers already sent Fehler

 
Die wahrscheinlichsten Ursachen sind:

  • Leerzeichen und/oder überflüssige Zeilen in der Datei wp-config.php oder functions.php
  • Falsche Kodierung von wp-config.php: UTF-8 mit BOM (Byte Order Mark)
  • Leerzeichen vor dem öffnenden <?php oder nach dem schließenden ?> in allen möglichen php-Dateien
  • weitere html vor php Ausgabe Fehler
Grundsätzlich sollte man in erster Linie in der Datei wp-config.php im Root-Verzeichnis Ihrer WordPress-Website, aber auch functions.php im Theme-Ordner des aktiven Theme nachsehen, ob:

  • 1. Sich am Anfang (vor <?php) und Ende sich nicht zufällig Leerzeichen befinden. Wenn ja, dann sie löschen
  • 2. In der Datei wp-config.php sich ein schließendes php-Zeichen ?> befindet. Das sollte nicht sein. Ist dort eins vorhanden, sollte es und die Leerzeichen gelöscht werden.
  • 3. Man sollte den Kodierungsfehler ausschließen, indem man wp-config.php und functions.php im Notepad++ öffnet und als UTF-8 ohne BOM kodiert
  • Zu UTF8 ohne BOM konvertieren

    Zu UTF8 ohne BOM konvertieren

     
  • 4. Hilft es nicht – sollte man möglicherweise versuchen, mehr Fehler anzuzeigen. Abhängig davon, wo genau der Fehler auftaucht, sollte man in wp-config.php oder evtl. header.php im Theme-Ordner sich alle Fehler anzeigen lassen und danach weiter suchen. Zum Anzeigen der PHP-Fehler wird folgender Code eingefügt:
    error_reporting(E_ALL);
    ini_set("display_errors", 1);

    Eine andere Möglichkeit besteht in der Änderung der Option WP_DEBUG in der Datei wp-config.php im Root-Verzeichnis Ihres WordPress wie oben beschrieben.

    define( 'WP_DEBUG', false );
    in
    define( 'WP_DEBUG', true );

5. Neuen WordPress Nutzer über MySQL Datenbank anlegen / WordPress Passwort in der Datenbank ändern

Man hat das WordPress Passwort vergessen und kann sich nicht im eigenen System einloggen. Normalerweise kann man in diesem Fall per „Passwort-vergessen“-Funktion von WordPress sich das Passwort per E-Mail zuschicken lassen. Wenn man jedoch im lokalen System arbeitet (kein Mailversand möglich) oder keinen Zugriff auf die angegebene Email-Adresse mehr hat, hilft nur eins: sich direkt das neue Passwort für den bereits existierenden Benutzer in der Datenbank erstellen und das alte damit überschreiben. Das ist technisch realisierbar, dagegen ist es nicht möglich, das WordPress Passwort zu entschlüsseln. Man kann auch eine komplett neuen WordPress-User direkt in der Datenbank anlegen.

WordPress Passwort vergessen

WordPress Passwort vergessen

 
  • Man hat das WordPress-Passwort vergessen
  • Man arbeitet in der lokalen Test-Umgebung
  • Man hat keinen Zugriff mehr auf die im System hinterlegte Email-Adresse
Vorausgesetzt ist natürlich, dass Sie den Zugriff auf die Datenbank haben. Die Zugangsdaten finden Sie nicht in WordPress, sondern bei Ihrem Hoster. Mit der Webanwendung zur Datenbankverwaltung Ihrer Wahl, beispielsweise phpMyAdmin oder Adminer, die von WordPress verwendete Datenbank öffnen und die Tabelle wp_users finden.

WordPress Tabelle wp_users

WordPress Tabelle wp_users

 

1. Wenn das der User ist, dann klicken Sie auf „bearbeiten“. Dann öffnen sich die dem User zugewiesenen Werte, darunter auch das „Passwort“ – user_pass. Was man wissen und verstehen muss – die Passwörter werden von WordPress verschlüsselt gespeichert. D.h., es reicht nicht, das Passwort aus dem Feld herauszukopieren und sich damit in WordPress einzuloggen. Entschlüsselt kann das Passwort auch nicht werden. Es muss in der verschlüsselten Form überschrieben werden. Das funktioniert jedoch ganz einfach.

WordPress Passwort in der Datenbank überschreiben

WordPress Passwort in der Datenbank überschreiben

 

Sie müssen in der Auswahl MD5 wählen, da WordPress MD5 crypt hash verwendet. Als Wert tragen Sie das Passwort unverschlüsselt ein. Danach tragen Sie das Passwort als Wert unverschlüsselt ein und bestätigen mit „OK“. Das ist alles – Sie können sich nun mit dem eingetragenen Passwort in Ihrem WordPress-Backend einloggen.

2. Sie können an der Stelle aber auch einen komplett neuen User in der Datenbank anlegen, wenn Sie den (die) bereits existierenden User unverändert lassen möchten. Folgendermaßen geht das:

In der selben Datenbank wp_users in der oberen Navigationsleiste auf „Einfügen“ (Insert) klicken

WP User in der Datenbank erstellen Schritt 1

WP User in der Datenbank erstellen Schritt 1

 

Hier müssen Sie Felder user_login, user_pass und user_email ausfüllen. Bei user_pass MD5 nicht vergessen.

WP User in der Datenbank erstellen Schritt 2

WP User in der Datenbank erstellen Schritt 2

 

Wie Sie sehen, ist der neue User angelegt worden, aber das ist noch nicht alles. An der Stelle merken wir uns die ID des gerade angelegten User (in unserem Fall 3)

WP User in der Datenbank erstellen Schritt 3

WP User in der Datenbank erstellen Schritt 3

 

Nun müssen wir den neu angelegten User mit den nötigen Zugriffsrechten ausstatten. Dazu öffnen wir die Tabelle wp_usermeta und klicken genau so wie eben auf „Einfügen“. umeta_id belassen wir an der Stelle leer. In user_id tragen wir die ID ein, die wir uns eben gemerkt haben (3). In meta_key wird wp_capabilities eingetragen. In das große Feld meta_value wird a:1:{s:13:“administrator“;s:1:“1″;} eingetragen.

Im nächsten Abschnitt wird bei user_id wieder die gemerkte ID eingetragen (3). In meta_key tragen wir wp_user_level ein und in meta_value fügen wir die 10 ein und bestätigen an der Stelle mit OK

WP User in der Datenbank erstellen Schritt 4

WP User in der Datenbank erstellen Schritt 4

 

Fertig! Der neue User ist angelegt worden, nun können Sie sich damit im WordPress-Backend einloggen und in Ihrem Userprofil fehlende Angaben eintragen.

6. WordPress Plugins ohne Dashboard (manuell) per FTP oder über Datenbank deaktivieren

WordPress ist unter Anderem so beliebt, weil es tausende von Plugins gibt, mit der man das System bis ins Unendliche erweitern kann. Die meisten Plugins für WordPress sind kostenlos und schnell über das Backend installiert. Sobald der Plugin-Entwickler eine neue Plugin-Version zur Verfügung stellt, wird das in jedem WordPress angezeigt. Schnell lässt man die Updates herunterladen und installieren und stellt anschließend fest, dass nichts mehr läuft.

Sowohl im Backend als auch im Frontend Ihres WordPress werden nur Fehlermeldungen ausgegeben oder komplett weiße Seiten angezeigt. Ganz häufig ist es der 503 Service Temporarily Unavailable Error. Eigentlich ist es kein Fehler im echten Sinne, sondern ein HTTP-Request – das macht aber die Situation nicht besser. Man möchte den Fehler schellstens beseitigen und das erste, was man in dieser Situation machen soll – die eben installierten WordPress Plugins deaktivieren. Das geht aber nicht immer über das Backend, zum Beispiel wenn man sich durch von Plugins verursachte Fehler gar nicht mehr im Backend einloggen kann.

WordPress 503 Fehler. The Service is unavailable

WordPress 503 Fehler. The Service is unavailable

 
  • Neuinstallation von WordPress Plugins
  • Aktualisierung von WordPress Plugins
  • Kein Zugang zum Backend
  • Kompatibilitätsprobleme
Normalerweise würde man im Backend über „Plugins“ die problematischen Plugins einfach eins nach dem anderen deaktivieren. Wenn jedoch von WordPress auch statt Backend nur noch eine weiße Seite ausgegeben wird, bleiben Ihnen zwei Möglichkeiten, die Plugins im WordPress zu deaktivieren:

1. WordPress Plugins per FTP deaktivieren
Ja, man kann Plugins im WordPress auch per FTP deaktivieren. Alle auf einmal oder auch eins nach dem anderen, bis man das Problem entdeckt habe und die Website wieder wie gewünscht funktioniert. Man muss beachten, dass der „richtige“ Weg, ein Plugin zu deaktivieren – wenn’s noch geht – in der Benutzung von Plugin-Verwaltung im WordPress-Backend liegt. Dann sind auch die einzelnen Einstellungen von Plugins richtig deaktiviert worden.

Folgendermaßen funktioniert die Deaktivierung per FTP:
Mit dem FTP-Client Ihrer Wahl zum Ordner „wp-content/plugins“ navigieren und es öffnen. Den Ordner mit dem gesuchten Plugin finden. Den Ordner einfach umbenennen, indem man beispielsweise „xxx“ hinten an den Namen anhängt. Das Plugin ist somit deaktiviert. Wenn man im Backend die Plugin-Verwaltung aufruft und die Seite aktualisiert, erscheint eine Fehlermeldung von WordPress, dass es den Ordner mit dem Plugin nicht mehr gibt und dass das Plugin somit nicht mehr aktiv ist.

WordPress Plugin deaktivieren

WordPress Plugin deaktivieren

 

Möchte man mit einem Mausklick alle WordPress-Plugins deaktivieren, benennt man auf die selbe Art und Weise den Ordner wp-content/plugins selbst um, in beispielsweise „pluginsxxx“.

2. WordPress Plugins über Datenbank deaktivieren
Mit einer Webanwendung zur Datenbankverwaltung wie phpMyAdmin oder Adminer, die von WordPress verwendete Datenbank öffnen und in der Tabelle wp_options Zeile active_plugins finden. Zur Einfachheit können hierzu alle Zeile alphabetisch sortiert werden. Auf „Bearbeiten“ klicken. So sieht es dann aus:

Aktivierte Plugins in der WordPress-Datenbank

Aktivierte Plugins in der WordPress-Datenbank

 

So sieht es entsprechend im WordPress-Backend aus. Man sieht, dass 7 Plugins aktiv sind:

Aktivierte WordPress Plugins im WordPress Backend

Aktivierte WordPress Plugins im WordPress Backend

 

Wenn man jetzt den kompletten Inhalt von option_value löscht, werden alle aktive Plugins auf einmal deaktiviert.
Möchte man jedoch einzelne WordPress-Plugins über die Datenbank deaktivieren, dann muss man sich mit dem Aufbau von „option_value“ vertraut machen.

  • a:7 steht für die Anzahl der aktiven Plugins
  • mit einer geschweiften Klammer geht es los und dann:
  • fängt ein Plugin-Eintrag immer mit i:Ziffer an und endet mit ;
  • die erste Ziffer ist immer Null! i:0
  • um ein Plugin zu löschen, müssen folglich sowohl die Gesamtanzahl von Plugins (a), als auch die durchgehende Nummerierung (i:Ziffer) angepasst werden

Möchten wir also in unserem Beispiel TinyMCE Advanced (i:3) deaktivieren, müssen wir den Inhalt folgendermaßen abändern:

  • Die Gesamtzahl auf 6 reduzieren (a:6)
  • Den Plugin-Eintrag, also alles von i:3 bis zum einschließlich nächsten Semikolon löschen
  • Die Nummerierung anpassen. Aus a:4 wird dann a:3 usw.
  • Anschließend auf OK klicken
Einzelnes WordPress Plugin in der Datenbank deaktivieren

Einzelnes WordPress Plugin in der Datenbank deaktivieren

 

7. WordPress wegen geplanter Wartungsarbeiten kurzzeitig nicht verfügbar

Während eines WordPress Updates oder während einer Neuinstallation oder eines Updates von WordPress-Plugins ist eine WordPress-Website temporär offline, was natürlich an sich völlig in Ordnung ist. Ruft ein zufälliger Seitenbesucher in dem Moment die Website auf, erscheint eine WordPress-Meldung „Wegen geplanter Wartungsarbeiten kurzzeitig nicht verfügbar. Schau gleich noch einmal vorbei“. Die Website befindet sich im WordPress Wartungsmodus und soll nach der erfolgten Installation automatisch verschwinden.

Manchmal bleibt geht er nicht weg und bleibt hängen. Dann sollte man ihn manuell abschalten.

Wegen geplanter Wartungsarbeiten kurzzeitig nicht verfügbar

Wegen geplanter Wartungsarbeiten kurzzeitig nicht verfügbar. Schau gleich noch einmal vorbei.

 
  • WordPress Update
  • Plugin-Neuinstallation oder Plugin-Update
  • WordPress Wartungsmodus
Die gute Nachricht lautet: das Problem ist schnell gelöst. Mit dem FTP-Client Ihrer Wahl, beispielsweise FileZilla oder FlashFXP, im Hauptverzeichnis Ihrer WordPress-Website eine Datei namens „.maintenance“ finden und löschen. Danach muss die Website wieder laufen. Die Updates müssen meistens nicht erneut installiert werden.

.maintenance Datei in WordPress

.maintenance Datei in WordPress

 

8. WordPress weiße Seite. White Screen of Death

Das bekannte und eins der meist gefürchteten WordPress-Probleme tritt meistens entweder nach einem WordPress System- oder Plugin-Update, nach einer Theme-Installation bzw. Theme-Wechsel oder auch nach Übertragung einer Website aus der lokalen Entwicklungsumgebung auf den Live-Server. Sowohl das Frontend aber auch das WordPress-Backend zeigen nur noch komplett weiße Seiten an. Man hat aber auch keine Möglichkeit, sich im Backend einzuloggen um das Problem zu beheben. Man sollte an der Stelle nicht in Panik geraten – es ist meistens alles noch da und lässt sich auch reparieren.

WordPress weiße Seite

WordPress zeigt nur noch eine weiße Seite – WordPress white Screen of Death

 
  • WordPress Upgrade
  • WordPress Plugin-Update oder Neuinstallation
  • WordPress Theme-Update oder Neuinstallation
  • WordPress Umzug (auf den Live-Server)
Als erstes muss man versuchen zu verstehen, was genau das Problem verursacht hat. Dafür ändert man den Wert der Option WP_DEBUG in der Datei wp-config.php im Root-Verzeichnis Ihres WordPress von false in true

define( 'WP_DEBUG', false );
in
define( 'WP_DEBUG', true );

und hofft, dass ein Fehler angezeigt wird, aus dem anhand der angezeigten Pfade verständlich wird, wer der Übeltäter ist. Ist das ein Plugin, oder hat man unmittelbar bevor der Fehler aufgetreten ist ein neues Plugin installiert, dann lohnt sich die manuelle Deaktivierung des Plugins.

Folgendermaßen funktioniert die Deaktivierung eines WordPress-Plugins per FTP:
Mit dem FTP-Client Ihrer Wahl zum Ordner „wp-content/plugins“ navigieren und es öffnen. Den Ordner mit dem gesuchten Plugin finden. Den Ordner einfach umbenennen, indem man beispielsweise „xxx“ hinten an den Namen anhängt. Das Plugin ist somit deaktiviert. Wenn man im Backend die Plugin-Verwaltung aufruft und die Seite aktualisiert, erscheint eine Fehlermeldung von WordPress, dass es den Ordner mit dem Plugin nicht mehr gibt und dass das Plugin somit nicht mehr aktiv ist.

WordPress Plugin deaktivieren

WordPress Plugin deaktivieren

 

Vermutet man einen Fehler im frisch installierten oder gerade aktualisierten WordPress-Theme, kann man ähnlich vorgehen um das aktuelle Theme zu deaktivieren.

Folgendermaßen funktioniert die Deaktivierung eines WordPress-Themes per FTP:
Mit dem FTP-Client Ihrer Wahl zum Ordner „wp-content/themes“ navigieren und es öffnen. Den Ordner mit dem gesuchten Theme finden. Den Ordner einfach umbenennen, indem man beispielsweise „xxx“ hinten an den Namen anhängt. Das Theme ist somit deaktiviert.

WordPress Theme per FTP deaktivieren

WordPress Theme per FTP deaktivieren

 

War ein Theme oder Plugin für das „weiße Seite“-Problem verantwortlich? Dann müsste man dort nach der Ursache suchen, ein anderes Plugin oder Theme verwenden. Allerdings gibt es andere Stellen, die das Problem ebenfalls verursacht haben konnten.

wp-config.php und functions.php
Unterziehen Sie folgende Bereiche einer Überprüfung. Bei den Dateien wp-config.php im Rootverzeichnis des WordPressbereiches der Website, sowie auch bei Theme Ordner beim aktiven Theme, dort die functions.php. Hier überprüfen Sie, ob sich folgende Fehler eingestellt haben:

  • 1. Insbesondere am Anfang (vor <?php) und Ende schleichen sich gerne Leerzeichen ein. Ist das der Fall, sollten diese umgehend gelöscht werden
  • 2. Probleme können auch dadurch entstehen, wenn in der Datei wp-config-php ein schließendes php-Zeichen ?> besteht. Wenn dem so sein sollte, muss es, sowie auch die Leerzeichen, gelöscht werden
  • 3. Etwaige Kodierungsfehler entstehen häufig, können aber einfach ausgeschlossen werden. Hierzu wp-config.php und functions.php im Notepad++ öffnen, als UTF-8 ohne BOM kodieren
Zu UTF8 ohne BOM konvertieren

Zu UTF8 ohne BOM konvertieren

 

PS. Nachdem das Problem gelöst wurde, vergessen Sie nicht die Option WP_DEBUG wieder zu deaktivieren indem man sie in wp-config.php wieder auf false setzt!

9. Fehler Cookies sind wegen einer unerwarteten Ausgabe gesperrt

Das Problem trat in unserer Praxis meistens nach einer Übertragung eines Projekts von der lokalen Umgebung auf einen Live-Server. In dem Fall editiert man in der Datei wp-config.php die Datenbank-Zugangsdaten direkt (und unsauber) im FTP-Programm, was zu Kodierungsproblemen beim Abspeichern führen kann.

Fehler Cookies sind wegen einer unerwarteten Ausgabe gesperrt

Fehler Cookies sind wegen einer unerwarteten Ausgabe gesperrt

 
  • Kodierungsfehler in der Datei wp-config.php
  • Eine kürzlich bearbeitete wp-config.php
  • Sehr selten: Probleme mit dem Cache
  • Sehr selten: Probleme mit den WordPress-Plugins
Grundlegende Dinge sollten überprüft werden: Zum einen die wp-config.php Datei im Root-Verzeichnis der Site im WordPress, zum anderen aber auch die functions.php im Theme-Ordner im aktiven Theme. Hier sollte man kontrollieren, ob:

  • 1. Um so genannte Kodierungsfehler zu vermeiden, sollte man wp-config.php und functions.php im Notepad++ öffnen und als UTF-8 ohne BOM kodieren. Damit sei meistens das Problem aus der Welt geschaffen. Falls jedoch nicht, dann schauen Sie sich Punkte 2. und 3. an
    Zu UTF8 ohne BOM konvertieren

    Zu UTF8 ohne BOM konvertieren

     
  • 2. Sich nicht Leerzeichen eingeschlichen haben, die übersehen wurden und sich am Anfang (vor <?php), aber auch dem Ende befinden können. Wenn dem so ist, dann löschen Sie sie
  • 3. In der Datei wp-config.php ein schließendes php-Zeichen ?> vorhanden ist? Das darf nicht sein. Im Falle, dass dennoch eins vorhanden ist, sollte man es entfernen und auch die Leerzeichen löschen

10. Aus Sicherheitsgründen ist dieser Dateityp nicht erlaubt. Kein Upload von bestimmten Dateitypen möglich

Bei einem Versuch eine Video-Datei mit der Dateiendung .webm (Webvideo) hochzuladen kam in der Mediathek bzw. im WordPress-Upload Fenster eine Fehlermeldung: „Aus Sicherheitsgründen ist dieser Dateityp nicht erlaubt“. Somit war das Upload und anschließende Einbinden der .webm-Datei nicht möglich.

Aus Sicherheitsgründen ist dieser Dateityp nicht erlaubt

Aus Sicherheitsgründen ist dieser Dateityp nicht erlaubt

 
WordPress verbietet das Upload einiger Dateitypen aus Sicherheitsgründen.
Es existiert eine Möglichkeit, diesen Sicherheitsmechanismus bei WordPress komplett abzuschalten. Dafür fügt man in der Datei wp-config.php im Root-Verzeichnis Ihrer WordPress Präsenz vor der Zeile /* That's all, stop editing! Happy blogging. */ folgenden Code ein: define ('ALLOW_UNFILTERED_UPLOADS', true);
Somit ist das Upload beliebiger Dateien über die WordPress Mediathek möglich.

11. Nur kryptische Zeichen auf WordPress-Seiten

Das ist zum Glück ein ganz seltener Fehler, der jedoch jeden in Angst und Schrecken versetzen kann. Auf allen WordPress Seiten werden statt Text, Bild und Video nur komische, kryptische Zeichen angezeigt. Im Quellcode ist auch nichts außer dieser Zeichen zu sehen. In unserer Praxis kam der Fehler ein einziges Mal vor, nach einem Update von W3 Total Cache Plugin.

PS. Das Problem trat in unserer Praxis mehrmals auf, bei der gleichzeitigen Benutzung vom Caching-Plugin W3 Total Cache Plugin und WordPress Update auf Version 4.7.2 auf

WordPress Seiten nur mit kryptischen Zeichen

WordPress Seiten nur mit kryptischen Zeichen

 
Für den Fehler, so wie er auf dem Screenshot abgebildet ist, sind Einstellungen im W3 Total Cache Plugin verantwortlich. In Ihrem Fall kann das ein anderes Caching-Plugin gewesen sein. Das Problem trat auch bei dem Update auf WordPress 4.7.2 auf
Leider muss, falls dieser Fehler vorkommt, in den Einstellungen von W3 Total Cache Browser Cache deaktiviert werden (und Browser Caching anschließend manuell eingerichtet werden, was jedoch nicht das Thema dieses Artikels ist). Eine andere Lösung ist uns nicht bekannt.

Zu der entsprechenden Einstellung gelangt man im WordPress-Backend über die linke Sidebar Performance->General Settings und dann scrollt man zum Browser Cache und deaktiviert das Kästchen. Danach funktioniert die Website wieder.

W3 Total Cache Browser Cache deaktivieren

W3 Total Cache Browser Cache deaktivieren

12. Warning: mysqli_num_fields() expects parameter 1 to be mysqli_result

Es erscheint ein „Warning: mysqli_num_fields() expects parameter 1 to be mysqli_result“ trotz deaktivierter Anzeige von PHP-Warnings und define( 'WP_DEBUG', false ); in wp_config.php

Warning: mysqli_num_fields() expects parameter 1 to be mysqli_result

Warning: mysqli_num_fields() expects parameter 1 to be mysqli_result

 
Für den Fehler, so wie er auf dem Screenshot abgebildet ist, sind Einstellungen im W3 Total Cache Plugin verantwortlich. In Ihrem Fall kann das ein anderes Caching-Plugin gewesen sein.
Leider muss, falls dieser Fehler vorkommt, in den Einstellungen von W3 Total Cache Database Cache deaktiviert werden. Eine andere Lösung ist uns zur Zeit nicht bekannt.

Zu der entsprechenden Einstellung gelangt man im WordPress-Backend über die linke Sidebar Performance->General Settings und dann scrollt man zum Database Cache und deaktiviert das Kästchen. Danach funktioniert die Website wieder.

W3 Total Cache Database Cache deaktivieren

W3 Total Cache Database Cache deaktivieren

13. WordPress Sitemap Fehler. XML-Verarbeitungsfehler: XML- oder Text-Deklaration nicht am Beginn der Entität

Aus Sicht der Suchmaschinen ist eine (XML)-Sitemap eine große Hilfe für den Crawler und sorgt somit für eine bessere Indexierbarkeit für jede moderne Website. Ohne zusätzliche Plugins kann WordPress jedoch von alleine keine Sitemap erstellen. Umso mehr wundert man sich, wenn beim Einsatz beliebiger WordPress Sitemap-Plugins immer wieder die selbe Fehlermeldung kommt: „XML-Verarbeitungsfehler: XML- oder Text-Deklaration nicht am Beginn der Entität“ Zeile Nr. 3, Spalte 1″

WordPress Sitemap Fehler. XML-Verarbeitungsfehler

WordPress Sitemap Fehler. XML-Verarbeitungsfehler

 
Die Übeltäter sind die selben:

  • Meistens ist es die falsche Kodierung von wp-config.php: UTF-8 und nicht UTF-8 mit BOM (Byte Order Mark)
  • Leerzeichen vor dem öffnenden in allen möglichen php-Dateien
Grundsätzlich sollte man in erster Linie in der Datei wp-config.php im Root-Verzeichnis Ihrer WordPress-Website, aber auch functions.php im Theme-Ordner des aktiven Theme nachsehen, ob:

  • 1. Sich am Anfang (vor <?php) und Ende sich nicht zufällig Leerzeichen befinden. Wenn ja, dann sie löschen
  • 2. In der Datei wp-config.php sich ein schließendes php-Zeichen ?> befindet. Das sollte nicht sein. Ist dort eins vorhanden, sollte es und die Leerzeichen gelöscht werden.
  • 3. Man sollte den Kodierungsfehler ausschließen, indem man wp-config.php und functions.php im Notepad++ öffnet und als UTF-8 ohne BOM kodiert
  • Zu UTF8 ohne BOM konvertieren

    Zu UTF8 ohne BOM konvertieren

     

14. The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.

Versucht man ein Bild über den Navigationspunkt „Medien“ im WordPress-Backend oder auch im WordPress-Editor in einem Beitrag oder einer Seite hochzuladen, kommt bereits nach dem erfolgten Upload-Vorgang eine Fehlermeldung: The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.

The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later

The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later. Bild 1

 
Wenn Sie ein Hosting bei Strato haben, dann liegt das Problem für diesen Fehler (Error 503) mit hoher Wahrscheinlichkeit am Strato ServerSide Security Modul. Es ist zwar gegen Spam in Formularen konzipiert, verursacht jedoch (nicht immer) den Fehler und die Unmöglichkeit die Bilder normal hoch zu laden.
Eine andere Lösung, als „ServerSide Security“ abzuschalten ist uns nicht bekannt. Diese Einstellung im Strato Kunden-Backend unter „Sicherheit->ServerSide Security“. Der Filter muss deaktiviert werden. Danach können Sie Bilder in gewohnter Manier wieder im WordPress-Backend hochladen.

The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later

The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later. Bild 2

 

Anschrift:

Design4u Köln - Webdesign, WordPress und SEO Agentur in Köln

Anschrift & Kontakt:

Amsterdamer Straße 230
50735 Köln
Telefon:
0221 97 53 416
E-mail:
webmaster@design4u.org

Kontaktformular