Zieht man mit seinen WordPress-Blog um, wie ich es in den ersten beiden Teilen meiner Artikelserie beschrieben habe, kann das ein oder andere auch schief gehen. Die Erfahrugnen, die ich dabei gemacht habe, beschreibe ich in diesem dritten und letzten Teil zu dem Thema. Frei nach Murphy’s Law: was schiefgehen kann, geht auch schief.
Fehlermeldung Cannot modify header information
Betrifft oft den Umzug von der lokalen Entwicklungsumgebung auf einen Webserver. Erhält man nach dem Umzug folgende oder ähnliche Fehlermeldung Cannot modify header information – headers already sent by (output started at /home/www/***/html/wp-config.php:1) in /home/www/***/html/wp-login.php on line 202 hat man garantiert in einer seiner php-Dateien überflüssige Zeichen vor dem öffnenden oder nach dem schließenden php-Tag.
Diese Zeichen fügt man meist nicht selbst ein, sondern ein Editor setzt die Zeichen beim Abspeichern der php-Datei. Das Ganze passsiert mit UTF-8-kodierten Textdateien und nennt sich »Byte Order Mark«-Bug oder abgekürzt BOM-Bug. Ein guter Hinweis, wo man nach den störenden Zeichen suchen sollte findet sich in der ersten Klammer: /home/www/***/html/wp-config.php:1. In diesem Fall befinden sich Zeichen vor dem öffnenden php-Tag in der Zeile 1 der config.php.
Mir ist der Fehler in der selbst erstellten functions.php passiert, wo ich einige Zeilen HTML-Code nicht über die php-Funktion ‚echo‘ ausgegeben habe, sondern dachte, ich kann mir Schreibarbeit sparen und habe den php-Code geschlossen und später wieder geöffnet. Lokal in meiner Entwicklungsumgebung hat das auch einwandfrei funtkioniert. Auf dem Webserver dann nicht mehr.
Abweichendes Tabellen-Präfix in der Datenbank
Aus Sicherheitsgründen ändere ich grundsätzlich das vorgegebene WordPress-Präfix für die Datenbank von >wp_< auf einen eigenen Wert. Das erschwert Angreifern, die bekannten Tabellennamen zu nutzen und damit direkt auf die Datenbank zuzugreifen (ist mir 2007 schon einmal passiert). Letztens bin ich mit einer WordPress-Installation umgezogen und habe die Daten direkt per MySQL-Export und -Import auf die neue Umgebung übertragen.
Nur leider wurden mir die Beiträge in der neuen Umgebung nicht anzeigt. Klar, die neue WordPress Installation griff auf die Standard-Tabellen in der Datenbank zu. Und die waren natürlich leer. Das Tabellenpräfix lässt sich aber einfach über die wp_config.php anpassen:
/**
* WordPress Datenbanktabellen-Präfix
*
* Wenn du verschiedene Präfixe benutzt, kannst du innerhalb einer Datenbank
* verschiedene WordPress-Installationen betreiben. Nur Zahlen, Buchstaben und Unterstriche bitte!
*/
$table_prefix = ‚wp_‘;
Verwendet man den richtigen Tabellen-Präfix, klappt’s auch mit der Datenbank!
Fehlende JavaScript Bibliotheken
Eine weitere selbstgestellte Falle, in die ich bereits reingetappt bin, sind zusätzliche JavaScript-Bibliotheken (meist JQuery-Erweiterungen), die ich für das Frontend benötigt habe. Diese hatte ich in dem Verzeichnis >wp-includes/js/jquery< abgelegt. Auf dem Server habe ich dann aber eine neue Installation verwendet, in der diese Bibliotheken natürlich fehlten. Ein nachträglicher Upload der Dateien behebt diesen Fehler allerdigns schnell.
Ein ausführliche Beschreibung zum Thema Umzug mit WordPress findet sich außerdem auf dem lesenswerten WordPress-Blog von elmastudio:
- Einen WordPress-Blog umziehen (Teil 1): So funktioniert’s
- Eine WordPress-Webseite umziehen (Teil 2): Gleiche Domain aber neuer Hosting-Anbieter
