Website-Zustand

Website-Zustand: WordPress versendet keine Mail ?

Website-Zustand: Wie geht es deiner WordPress-Seite

Auch wenn es vielleicht ein wenig nervt, muss ich etwas weiter ausholen, denn eine Mail wird z. B. ja nur dann versendet, wenn die Webseite ein Problem hat. Daher hier erst mal ein paar Infos über die Option „Website-Zustand“.

Seit WordPress 5.2 findet man im Dashboard unter Werkzeuge die äußerst hilfreiche Funktion „Website-Zustand“, die in WordPress 5.3 noch weiter ausgebaut wurde. Diese Funktion ist in erster Linie dann interessant, wenn man prüfen will, ob es irgendwelche Probleme mit der Seite gibt. Sollte man bereits Probleme bemerkt haben, dann findet man hier weitere Hinweise.

Zu diesem Zweck gibt es standardmäßig zwei Reiter: „Status“ und „Bericht“.

Website-Zustand: Status und Info

Zunächst zu Status: Hier werden wichtige Informationen zur WordPress-Konfiguration gezeigt.
Unterteilt werden die Informationen in kritische Probleme und empfohlene Optimierungen. Bei den kritischen Problemen sollte man natürlich ziemlich schnell aktiv werden. Das kritische Problem, das in dem Screenshot genannt wird, hängt übrigens damit zusammen, dass der Wert
WP_DEBUG_LOG
 in die Konfigurationsdatei wp-config.php hinzugefügt wurde. Das bedeutet, dass alle Fehler auf der Website in eine Datei geschrieben werden, die möglicherweise für normale Benutzer verfügbar ist. Da es sich in diesem Fall um eine Entwicklungsseite (development environment) handelt und damit gewollt ist, ist das kein Problem, das korrigiert werden muss.
Bei den „empfohlenen Optimierungen“ findet man einige Dinge, die nicht unbedingt korrigiert werden müssen. Wenn man beispielsweise ein Plugin deaktiviert hat und nicht weiß, ob man das Plugin in der Zukunft weiterhin nutzen möchte, ist es in der Regel natürlich schon aus Sicherheitsgründen besser, dieses Plugin zu löschen. Die Einstellungen, die mit diesem Plugin verbunden sind, bleiben trotzdem in der Regel erhalten.

Hat man allerdings ein Plugin aus irgendwelchen Gründen nur kurzfristig mal deaktiviert, dann kann man die Meldung natürlich ignorieren.

Empfohlen wird aber auch z. B. „PHP zu aktualisieren“. Zum Zeitpunkt dieses Beitrags kam diese Empfehlung, obwohl PHP 7.2 aktiviert war. PHP 7.3 wäre der Zustand gewesen, den sich WordPress „gewünscht“ hätte.
Unter dem zweiten Reiter Info findet man den Bericht zur Webseite mit allen möglichen Details zur Konfiguration der Website. Dieser Bericht kann über „Bericht in die Zwischenablage kopieren“ abgelegt und beispielsweise im Forum veröffentlicht werden, wenn es Probleme mit der Website gibt.

Das Plugin „Health Check & Troubleshooting“

Weitere Informationen und Problemlösungsmöglichkeiten zum Website-Zustand erhält man, wenn man das Plugin „Health Check & Troubleshooting“ installiert.

Wenn man auf den Button „Problembehandlungsmodus aktivieren“ unter Problembehandlung klickt, wird als Standardtheme (wenn vorhanden) twenty nineteen aktiviert. Alle Plugins sind dann deaktiviert.
Ich hatte mal ein Problem im Dashboard und habe Plugin für Plugin im Problembenhandlungsmodus aktiviert. Dann habe ich jeweils geschaut, ob das Problem noch bestand. Auf diese Weise habe ich das Plugin gefunden, dass das Problem verursacht hat. Die Kehrseite der Medaille ist natürlich, dass durch die Deaktivierung des Plugins die Funktionalität der Webseite mehr oder weniger stark eingeschränkt ist. Wenn man beispielsweise Termine auf einer Webseite veröffentlicht und genau dieses Plugin das Problem verursacht, dann ist die Webseite ja praktisch unbrauchbar. In dem Fall bleibt nur, Kontakt zum Entwickler aufzunehmen.

Vorteil dabei ist, dass die Webseite weiter mit allen Infos und unter Verwendung aller Plugins gezeigt wird, während nur für dich alle plugins deaktiviert sind. Im Inkognito – Modus von Chrome kann man sehen, dass die Seite aber nach wie vor genauso aussieht wie vorher. Den Inkognito-Modus findet man, wenn man rechts oben auf die drei senkrechten Punkte klickt.

Der Problembehandlungsmodus

Website-Zustand: WordPress hat einen kritischen Fehler

Ich hatte jetzt den Fall, dass ich nach der Bearbeitung eines Beitrags einen „Fatal Error“ aus WordPress erhalten habe, aber die angesprochene Mail kommt nicht an. Die Mail ist insofern sehr hilfreich, weil man in der Regel eine Information dazu erhält, welches Plugin oder Theme das Problem verursacht hat. In diesem Fall kann man das betreffende Plugin deaktivieren und beobachten, ob der Fehler danach noch weiter auftaucht.

Zusätzlich erhält man möglicherweise auch einen Link zur Wiederherstellung.

Nicht schön und sorgt für Nervenkitzel
Wäre ja schön, wenn dann auch eine Mail ankommt

Problem mit dem Website-Zustand und die Mail kommt nicht an

Tja, alles sehr schön, aber wenn die Mail nicht ankommt, dann fehlen wichtige Infos, die zumindest dafür sorgen können, die Ursache des Problems schneller zu finden.

Auf eine mögliche Lösung hat mich unser Hoster gebracht. Ich bin kein Freund von 1Click-Installationen, weil da Einstellungen vorgenommen und Plugins installiert werden, die ich in der Regel nicht brauche. Außerdem ist die manuelle Installation von WordPress jetzt nicht so kompliziert. In diesem Fall wird bei der 1Click-Installation aber durch unseren Hoster das Plugin Easy WP SMTP installiert. Also habe ich nach dem Hinweis des Supports unseres Hosters dieses Plugin installiert und aktiviert.

Easy WP SMTP

Plugin „Easy WP SMTP“ löst das Problem in der Regel

Das leichtgewichtige Plugin bietet nur wenige, vollkommen ausreichende Einstellungen, von denen ich einige nachfolgend erläutern möchte:

  • „From Email Address“: Eine Mailadresse, die zur Domain gehört, also z. B. in unserem Fall könnte das „webmaster@haurand.com“ sein.
  • „From Name“: an sich beliebig, hier z. B. „Webmaster“. Könnte aber auch ein Name sein.
  • „SMTP Host“: Hier muss der Postausgangsserver (SMTP) angegeben werden (dürfte in der Regel über das Kundenmenü des Hosters ersichtlich sein)
  • „SMPT Port“: Der Port 25 ist hierbei der unverschlüsselte Port, der mittlerweile viele Probleme erzeugt, da dieser nach RFC-Norm sehr problematisch ist. In unserem Fall haben wir den Port auf den verschlüsselten Port 587 bei TLS Verschlüsselung gesetzt. Das sollte man dann mal testen.
  • „SMTP Username“: Nicht zu verwechseln mit der Mailadresse. Im Kundenmenü werden die Postfächer angelegt und Mailadressen zugeordnet. Bei den Postfächern werden die Benutzernamen festgelegt bzw. zugeordnet.
  • „SMTP Password“: Hier wird das Passwort für den Zugriff auf die Mails der Mailadresse angegeben, die dem Postfach zugeordnet ist.

Unter dem Reiter „Test Email“ kann man zum Abschluss testen, ob das funktioniert und die Mail tatsächlich ankommt. Bei uns hat das wunderbar geklappt und wir hoffen jetzt, dass wir (hoffentlich nur) wenige Mails mit einer WordPress-Fehlermeldung erhalten.

Sinnvoll ist zusätzlich ein Test, ob eine Mail unter Website-Zustand > Werkzeuge und E-Mail-Prüfung versendet und im E-Mail-Eingang der dort angegebenen Mailadresse ankommt.

Alternative: Ausgabe von Fehlern über die debug.log

Sollte die o. g. Option trotzdem nicht funktionieren, können Fehler auch in der debug.log protokolliert werden, auf die man dann per FTP (oder auch SSH) zugreifen kann.
Um das zu ermöglichen, müssen folgende Zeilen (Definiten von Konstanten) in die wp-config.php geschrieben werden:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_DISPLAY', false );
define( 'WP_DEBUG_LOG', true );

Dabei ist darauf zu achten dass die Zeile

define('WP_DEBUG', false);

überschrieben wird, denn wenn versucht wird, diese Konstante ein zweites mal zu definieren, dann führt das zu einem Fehler, so dass die Seite nicht mehr funktioniert.
Mit diesen drei Codezeilen sagen wir WordPress, dass der Debug-Modus aktiviert werden soll, die Fehlermeldungen aber nicht direkt angezeigt, sondern in die Datei /wp-content/debug.log geschrieben werden soll.

Danach sollte man die Schritte, die zu dem Fehler geführt haben, wiederholen. Wenn der Fehler dann wieder auftaucht, kann man die Datei debug.log per FTP lokal laden und es besteht die Chance, dass man darin einen Hinweis auf die Problemursache findet.

Allerdings sollte man die o. g. PHP-Konstanten wieder deaktivieren, wenn der Fehler gefunden worden ist. In dem Fall reicht es, wenn statt true an der entsprechenden Stelle false geschrieben wird. Zusätzlich ist es ratsam, die Datei debug.log per FTP wieder zu löschen.


Mehr erfahren auf dieser Webseite

Grafik: haurand.com


Infos im Blog

Mehr erfahren auf unserer Webseite

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.