So… dann wollen wir mal mit dem ersten Beitrag starten. Vorweg gesagt, ich bin weder ein Linux-Experte noch WordPress Fachmann. Ich wollte nur ein Blogger Tool nutzen, um meine Notizen schnell nachlesen zu können, auch von unterwegs. Die Absicht, diese Informationen auch der Öffentlichkeit zur Verfügung zu stellen, kam mir zuerst einmal nicht in den Sinn. Aber dann dachte ich mir, warum sollten diese Tipps nicht jemanden helfen, der sich gerade mit dem gleichen Problem herumschlagen muss. Viele Hinweise, die ich hier niederschreibe, wurden durch Recherche im Internet ermittelt oder durch „try and error“ selbst herausgefunden.
Nach der doch relativ unkomplizierten Installation von WordPress und nach einem automatischen Update aus WordPress von 4.8.2 auf 4.8.3, das durchging wie ein Barium-Laser durch irische Butter, gab’s dann doch eins auf das unverhältnismäßig groß angewachsenes Ego. Da ich aber mit dem Sinn von Backups vertraut bin, war das Update-Malheur auf die neue Version 4.9 dann doch nur vergleichbar mit einem „Verdammt-kein ToiPap im Bad…“.
Es gab einen Installationsfehler. Irgendeine vermaledeite Datei konnte nicht kopiert werden, wahrscheinlich aufgrund von Dateiberechtigungen, denen ich aufgrund meiner Sicherheitsneurose zu feste Daumenschrauben angelegt hatte. Dass ich diesen Umstand nicht genauer analysiert habe, war darauf zurückzuführen, dass ich beim Start im Browser mit Anzeige eines HTTP Codes 500 doch in leichte Panik geraten bin. Ungefähr so ein Gefühl wie bei besagter Erkenntnis, dass das Klopapier aus dem normalen Griffbereich entmaterialisiert war.
Nun gut, es war eben passiert. Aber aufgrund der Sicherung und des manuellen Downloads der Version 4.9 konnte ich alles so wiederherstellen, dass ich im Browser wieder das gewohnte Bild zu sehen bekam. Ich bin allerdings dabei so vorgegangen, dass ich mein Backup zuerst wieder aufgespielt habe und dann die Dateien und Verzeichnisse aus dem ZIP-File darüber kopiert habe. Lediglich beim Ordner wp-content aus dem neuen Release habe ich Vorsicht walten lassen, da ich mir meinen Plugin Ordner nicht überschreiben wollte.
Um das ganze wieder von den Berechtigungen her sauber aufzusetzen, habe ich im Hauptverzeichnis von WordPress die folgenden Befehle abgesetzt.
chown www-data:www-data -R *
find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;
Als ich dann den Befehl für den Upgrade ausführen wollte, ist mir aufgefallen, dass ich das ja nur über einen externen Browser erledigen kann, da ich keinen X-Server für eine grafische Oberfläche aufgesetzt habe.
Eigentlich hatte ich angenommen, dass der wp-admin Bereich geschützt ist, so wie das Login, das ich bereits via Plugin versteckt habe. Keine Ahnung, was man da alles für Schweinereien machen kann. Ich habe mich dann im Internet auf die Suche nach Informationen gemacht und mir nach Anleitung eine .htaccess Datei im Verzeichnis wp-admin angelegt. Dabei habe ich dann eine geschlagene Stunde damit verbracht, zu ergründen, warum ich mit der angelegten .htpasswd Datei, die den Usernamen und das verschlüsselte Passwort enthält (mit htpasswd erzeugt), den Fehler „password mismatch error“ im error.log von Apache2 bekommen habe. Das Passwort hatte ich mit dem Tool pwgen erzeugt. Ich dachte zuerst, dass es an dem Pipe-Zeichen liegen würde, was sich durch ein einfacheres Passwort zunächst als mögliche Fehlerursache bestätigen ließ. Allerdings verwendete ich dazu einen anderen Befehls-Syntax als bei meinem ersten Versuch, als ich das Passwort auf der Befehlszeile mitangeben hatte. Beim 2. Versuch hatte ich es durch einen Prompt anfordern und verifizieren lassen.
htpasswd -Bc </pfad/datei>
Falls ihr also auch mal so einen Fehler haben solltet, probiert bitte die Variante ohne Angabe des Passworts beim Aufruf von htpasswd.
Und nicht genug des Schabernacks… man gönnt sich ja sonst nichts… einfach mal das WordPress-Verzeichnis in den generellen Parametern abändern. Da ich eigentlich ein Unterverzeichnis habe, und dies so nicht im Parameter für die Site-URL eingetragen war (so meine Annahme), habe ich dies schnell nachgeholt. Mit dem Erfolg, dass ich nach dem abspeichern nur noch blanken, unaufbereiteten Text ohne Bilder gesehen habe. Da kam mir mal wieder folgender Satz in Erinnerung „Never change a running system“. Meister Google belästigt, wo den die Parameter bei WordPress abgespeichert werden… obwohl ich es mir schon fast gedacht hatte. Die Datei wp-config.php wäre einfach zu einfach gewesen. Ok, dann auf die harte Tour und die mysql Konsole aufgerufen und folgendes SQL Statement eingegeben:
update wp_options set option_value = ‚<ursprüngliches Verzeichnis>‘ where option_name = ’siteurl‘;
Puuuhhh, gerade mal wieder gut gegangen. Ich sollte jetzt wirklich aufhören, an WordPress herumzubasteln, um diesen Beitrag nicht unnötig in die Länge zu ziehen. Es gibt ja noch jede Menge anderer Sachen, über die man schreiben kann.