Archiv der Kategorie: Fehler

Fehlersuche

Beispiel

Unsere WordPress-Seite hätte den Url http://meinwp.domain.at

Administrationsseite erreichbar

Wenn es Fehler beim Aufruf einzelner Seiten gibt aber man noch die Administrationsseite /wp-admin aufrufen kann, kann man durch temporäres Ausschalten der PlugIns feststellen, ob es sich um einen Fehler von WordPress oder um einen Fehler in einem der installierten PlugIns handelt.

Ebenso kann man mit dem Thema verfahren. Man aktiviert ein anderes (einfaches) Thema, um eine eventuelle Fehlerursache dadurch zu eliminieren.

Administrationsseite nicht erreichbar

Gehen wir davon aus, dass beim Aufruf von http://meinwp.domain.at sich gar nichts meldet.

Zuerst testen wir, ob eine statische Seite aufrufbar ist. Dazu rufen wir auf:

http://meinwp.domain.at/liesmich.html

Wenn die Seite angezeigt wird, ist der Webserver in Ordnung. Wenn die Seite nicht angezeigt wird, dann sollte man andere bekannte Referenzseiten wie zum Beispiel http://fiala.cc aufrufen, die am selben Server laufen oder die Statusseite http://status.ccc.at. Diese Statusseite gibt Aufschluss über die Erreichbarkeit des Webservers.

Wenn der Webserver nicht erreichbar ist, müssen wir uns darum kümmern; bitte um eine Mail an support{at}clubcomputer.at.

Wenn aber andere Seiten funktionieren und nur die eigene „spinnt“, geht man weiter so vor:

Man geht in das Website-Panel und dort mit dem Dateimanager in den Ordner wwwroot. In diesem Ordner legt man eine neue Datei mit dem Namen phpinfo.php an und als Inhalt schreibt man:

<?php
phpinfo():
?>

Jetzt ruft man diese Datei auf:
http://meinwp.domain.at/phpinfo.php

Meldet sich die Statusseite von PHP, dann ist PHP korrekt am Server installiert und der Fehler liegt woanders.

Meldet sich aber PHP nicht, dann ist im Allgemeinen der so genannte Application-Pool angestürzt. In diesem Fall empfehlen wir folgende Vorgangsweise:

https://panel.ccc.at -> Website meinwp.domain.at -> Erweiterungen

PHP von der aktuell eingestellten Version auf eine andere Version ändern (meist sind die zwei letzten Versionen installiert) und den Versuch, die Seite

http://meinwp.domain.at/phpinfo.php

aufzurufen, wiederholen. Der Fehler könnte behoben sein. Wenn nicht bitte an support{at}clubcomputer.at schreiben.

Sollte aber das auch funktionieren, dann sollte man sich bei der deutschen WordPress-Seite eine aktuelle WordPress-Version downloaden und mit Ftp auf den Server übertragen, entpacken und alle Dateien in wwwroot verschieben. Die Konfigurationsdatei wird dabei nicht überschrieben, weil sie in den Installationsdateien nicht enthalten ist. Ebenso werden upgeloadete Bilder dadurch nicht angetastet. Sollte es sich daher um einen Defekt bei der WordPress-Installation gehandelt haben, sollte er nach diesem „Auffrischen“ aller Dateien entfernt worden sein.

Wenn dieses „Auffrischen“ auch keinen Erfolg bringt, dann könnte es sein, dass ein PlugIn oder das Thema der Übeltäter ist. Man geht daher mit dem Dateimanager im WebsitePanel (https://panel.ccc.at) in den Ordner wp-content. Dort schaltet man im Ordner plugins alle PlugIns aus, indem man die einzelnen Ordnernamen umbenennt (statt akismet schreibt man akismet-disabled). Danach startet man WordPress neu. Jetzt sollte WordPress starten und man kann daran gehen, die PlugIns der Reihe nach auf Fehler zu untersuchen.

Backup händisch erstellen

Was muss man sichern?

  1. Datenbank
  2. Bilder und Dateien
  3. Konfiguration

Datenbank sichern

Alle Texte und Einstellungen sind in der WordPress-Datenbank enthalten.

Um ein Backup von der Datenbank zu erstellen, geht man in das WebSitePanel (https://panel.ccc.at)

  • MySql-Datenbank -> Browse Database.
  • Im phpMaAdmin die Datenbank (zum Beispiel wp_name) anklicken.
  • Menüpunkt „Exportieren“
  • Exportiere Tabellen der Datenbank „wp_name“ („Schnell“) -> OK
  • Datenbank wird als Text auf den eigenen Rechner downgeloadet.

Sollte alles kaputt gehen, legt man wieder eine gleichnamige Datenbank an und verwendet den Menüpunkt „Importieren“.

Damit werden alle Tabellen und ihre Inhalte wiederhergestellt.

Bilder und Dateien sichern

Alle upgeloadeten Bilder, PlugIns und Themen befinden sich im Ordner wwwroot\wp-content

Es genügt, alle Dateien in diesem Ordner mit Ftp auf den eigenen Rechner downzuloaden.

Im Wiederherstellungsfall wird WordPress neu installiert und dann dieser Ordner vom Backup überschrieben.

Alle anderen Verzeichnisse muss man nicht sichern, die kann man jederzeit durch eine Neu-Installation von Word-Press wiederherstellen.

Konfiguration sichern

Die wichtigste Datei zur Wiederherstellung einer WordPress-Installation ist die Datei wwwroot\wp-config.php

In dieser Datei ist die Datenbank-Konfiguration enthalten und auch die Schlüssel zur Validierung der Passwörter.

Diese Datei muss man nach einer eventuellen Neuinstallation von WordPress in den Ordern wwwroot zurück übertragen.

Andernfalls kann man keine Verbindung zur Datenbank herstellen.


Wenn man also WordPress händisch sichert, dann muss man diese drei Schritte ausführen.

Es geht auch automatisch und dazu gibt es im folgenden Artikel eine Auswahl von Programmen:

Hier werden ein paar Backup-Lösungen beschrieben:
http://wp.clubcomputer.at/2015/10/backup-am-client/

Bild kann nicht eingefügt werden

Nah langer problemloser Arbeit mit eingefügten Bildern, trat plötzlich folgender Fehler auf: ein Bild sollte in die Medienbibliothek aufgenommen werden, der Upload funktionierte, doch dann wurde das Bild nicht angezeigt und im Texteditor wurde statt des Bildes das Symbol für einen gebrochenen Link gezeigt.

Wenn allerdings das Bild über einen Internet-Link eingefügt wurde (zum Beispiel aus Picasa-Webalben) funktionierte die Einfügung.

Das Rätselraten hatte ein Ende, nachdem die Adresse des Bildes genauer untersucht wurde: es war ein Bild mit Umlauten im Namen.

Meine aktuelle Schlussfolgerung ist, dass Bilder mit Umlauten im Dateinamen in WordPress nicht eingefügt werden können.

Dass das Bild über einen Internet-Link eingefügt werden kann, liegt daran, dass in diesem Fall die Umlaute URL-kodiert werden und daher der Fehler nicht auffällt.

Funktion mail() deaktiviert

Wenn Du als Administrator Deiner WordPress-Seite die folgende Fehlermeldung siehst, dann hast Du bei der Installation etwas übersehen,

mail

Im Allgemeinen kommt diese Fehlermeldung, wenn man sein Passwort vergessen hat und man sich das Passwort zusenden lassen möchte.

Du bist jetzt in einer schwierigen Situation, weil Du Dich ausgesperrt hast und nicht mehr weißt wie das Passwort gelautet hat.

Was hättest Du tun sollen?

Die Installationsanleitung in den PCNEWS lesen oder diesen Beitrag.

Es gibt im Internet einige Hinweise für diesen Fall. Die meisten Hinweise enden aber damit, dass man sich das Passwort mit der Funktion „Passwort zusenden“ wieder bekommt. Aber das funktioniert nicht, weil mail() nicht funktioniert und installieren kann man es auch nicht, weil man ja nicht ins System kann.

Eine andere Gruppe von Hinweisen verweist auf Tools im Internet, mit denen man sich einen Password-Hash generieren lassen kann und diesen Hash trage man dann in die WordPress-Datenbank ein.
Beispiel. Das funktioniert aber bei WordPress nicht, weil in der Datei wp-config.php ein zufälliger Salt-Wert eingetragen ist, der dafür sorgt, dass dasselbe Passwort in verschiedenen WordPress-Installationen verschieden ist.  Man bräuchte daher ein solches Passwort-Tool, in das man vorher seinen Salt-Wert einträgt und danach den Hash-Wert generieren lässt.

Schließlich bleibt folgender Weg: man installiert ein temporäres Hilfs-WordPress in derselben Datenbank und verwendet als „Salt“ jene zufälligen Werte, die in die verschlossene Version eingetragen worden sind. Man muss darauf achten, als Tabellenpräfix etwas anderes als „wp_“ zu verwenden, damit die bestehenden Tabellen nicht überschrieben werden, also etwa „wptemp_“. Beim ersten Aufruf wird man um einen User und um ein Passwort gefragt. Das merkt man sich und schließt die Installation ab.

Man öffnet im WebSitePanel die MySql-Datenbank und findet dort einen Tabellensatz mit dem Präfix „wp_“ und einen weiteren mit „wptemp_“.  In der Tabelle wptemp_users gibt es einen einzigen Record mit dem user_login admin und einem Hash-Wert in user_pass. Diesen Hash-Wert kopiert man und trägt in die Tabelle wp_users beim User admin (oder eben beim sonstigen gewünschten User) ein.

Das wars, jetzt kann man die Tabellen wptemp_* löschen und man hat wieder Zutritt zu seinem WordPress-Web.

 

 

Altes PlugIn konnte nicht entfernt werden

Eine Installation, die bis zum ersten Update eines PlugIn problemlos gelaufen ist, brachte folgende Fehlermeldung:

PlugInUpdateFehler

Es ist bemerkenswert, dass alle andere Vorgänge, wie das Schreiben eines neuen Beitrags, problemlos funktioniert haben.

Des Rätsels Lösung war eine Kleinigkeit beim Einrichten der Rechte für diese Installation.

PlugInUpdateFehlerRechte

Die Schreibrechte waren zwar gesetzt aber nicht die Leserechte. Bei der Installation eines PlugIn wird offenbar nach dem Löschen der bestehenden Dateien durch Lesen des Inhalts geprüft, ob diese Dateien auch tatsächlich gelöscht worden sind und genau an dieser Stelle passiert der Fehler. Nach Ankreuzen der Spalte „Read“ war der Fehler behoben und die Updates funktionieren wieder.

Was tun im Fehlerfall? 

Hier ein Tipp aus dem WordPress-Forum:

Die folgenden Zeilen in die Datei wp-config.php einfügen:

// Turn debugging on 
define('WP_DEBUG', true);  

// Tell WordPress to log everything to /wp-content/debug.log 
define('WP_DEBUG_LOG', true);  

// Turn off the display of error messages on your site 
define('WP_DEBUG_DISPLAY', false);  

// For good measure, you can also add the follow code, which will hide errors from being displayed on-screen 
@ini_set('display_errors', 0);  

Jetzt den fehlerhaften Zustand herbeiführen und den Inhalt der Datei /wp-content/debug.log analysieren.

Internal Server Error

Auf einem meiner WordPress-Webs trat zwei Mal folgender Fehler auf:

Nach einer Änderung der Permalinks konnte ich die Seite nicht mehr als Besucher, weil folgender Fehler auftrat:

ServerError Permalinks
Fehlermeldung, die auf eine fehlerhafte Datei web.config hindeutet.

Der konkrete Fehlertext lautet: „Config section ’system.webServer/rewrite/rules‘ already defined.“

Und tatsächlich ist in dieser Abschnitt in der Datei web.config zwei Mal enthalten. Offenbar wurde er durch WordPress fälschlicherweise ein zweites Mal eingetragen obwohl er dort schon steht.

Abhilfe derzeit

Ins WebSitePanel gehen, den Dateimanager aufrufen und in das Verzeichnis navigieren, in dem WordPress installiert ist (entweder wwwroot oder ein Unterverzeichnis).  Dort die Datei web.config zum Editieren öffnen (Bleistiftsymbol) und den folgenden Abschnitt entfernen:

 <system.webServer>
   <rewrite>
     <rules>
       <rule name="wordpress" patternSyntax="Wildcard">
         <match url="*"/>
         <conditions>
           <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true"/>
           <add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true"/>
         </conditions>
         <action type="Rewrite" url="index.php"/>
       </rule>
     </rules>
   </rewrite>
 </system.webServer>

Achtung: Beachte, dass dieser Abschnitt zwei Mal vorkommt aber in dem ersten stehen noch zusätzliche Angaben zum Startdokument. Diesen Abschnitt nicht entfernen, den zweiten ohne diese Angaben.

Lektüre

Die Frage ist, warum dieser Fehler auftritt.

Dieser Fall tritt auf, wenn auf dem Server zwei WordPress-Installationen laufen; ein im Wurzelverzeichnis und eine in  einem darunter liegenden Verzeichnis. Die Installation im Unterverzeichnis versucht, die Datei web.config zu verändern und das erzeugt diesen doppelten Eintrag.

Man muss die Installation ändern und beide Installationen in parallelen Unterverzeichnissen vornehmen. Dann tritt dieser Fehler nicht auf.