Archiv für den Tag: 15. November 2013

Datensicherung im Test

Wie ich hier beschrichtet habe, läuft jede Nacht die Datensicherung des Blogs. Würde sie jedoch im Ernstfall funktionieren? Das bestätigt nur ein Praxistest. Mir schwebt vor diese Datensicherung (ZIP-File bestehend Datenbank und Blogverzeichnis) auf einem lokalen Webserver zu testen. Es steht mir eine Netzwerk-Festplatte zur Verfügung die grundsätzlich geeignet ist. Auf dem QNAP-NAS kann ein MySQL-Server und ein Webserver gestartet werden.

Anregungen zum Thema habe ich hier gefunden. Eine ordentliche Datensicherung ist unerlässlich.

Momentan kämpfe ich noch mit der Konfiguration des NAS und dem MySQL-Frontend phpMyAdmin. Die letzten 8 Stunden habe ich mir mit Webseiten zum Thema um die Ohren geschlagen.

Es funktioniert! Es ist 04:31, und es funktioniert. Ein ganzes Stück Arbeit ist getan.
Die Datensicherung funktioniert. Das Backup läuft auf einem lokalen Webserver einwandfrei.

Folgendes war zu tun:

  • Konfiguration des QNAP-NAS: Webserver und MySQL-Server aktivieren. Das phpMyAdmin-Frontend für den MySQL-Server musste installiert werden (und den musste ich erst mal in Grundzügen begreifen).
  • die Datenbank aus dem Backup wird in auf den MySQL-Server überspielt
  • das Blogverzeichnis auf den Webserver kopieren
  • die wp-config.php an den neuen Datenbankpfad, -user und -passwort anpassen
  • in der Datenbank müssen für den Testlauf die Pfade an den lokalen Webserver angepasst werden

Es funktioniert!

Hilfreich waren diese beiden Blogs: www.blogprojekt.de und www.3D-Mediadesign.de

Permalinks aus dem Beitragsnamen

Um die Lesbarkeit der Permalinks zu verbessern wolle ich statt einer kryptischen Artikel-ID den Beitragsnamen (z.B. http://www.sichtverbindung.de/blog/beispielbeitrag/) verwenden (siehe hier).

Das führte allerdings zu Problemen:

  • Die Artikel erschienen richtig auf der Startseite, konnten aber nicht mehr über den Permalink aufgerufen werden. Auch ein Filtern nach Kategorieren endete in einem „File not Found“-Error.
  • Das Problem war eine nicht ausreichend konfigurierte  .htacces-Datei im Blog-Rootverzeichnis. WordPress beschreibt diese bei ausreichenden Rechten selbstständig.
    Alternativ fordert WordPress den Benutzer auf folgende Anweisungen in die .htaccess hineinzukopieren:
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

In meinem Fall mussten auch noch die Pfade angepasst werden, weil bei mir die Daten für den Blog in einem Unterverzeichnis auf dem Server liegen. Word
Darum sieht die Datei für meinen Blog folgendermaßen aus:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /blog/
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /blog/index.php [L]
</IfModule>
# END WordPress