Schlagwort: migration

Veröffentlicht am

Umzug von Blogger auf WordPress 4.2.2

Schrift mit Begriffen

Ich habe lange damit gerungen, ob es eine gute Idee ist, auf ein anderes Blogsystem umzusteigen. Heute habe ich es nun getan.

Ich war mit Blogspot, später Blogger.com eigentlich recht zufrieden – zumindest eine Zeit lang. Das war als Google sich stärker in der Blogosphäre engagiert hatte und das eine oder andere Suchergebnis sogar mal aus einem Blog stammte. Es gab sogar mal eine Blogsuche (einen Filter oder sogar einen eigenen Index). Blogspot schien mir gut geeignet.

Doch mit Google Plus hat sich das Interesse an sozialen Medien im Konzern wohl stark gewandelt. Dennoch konnte man mit Blogger.com viel machen. Man hatte einige Templates zur Auswahl und konnte auch HTML- und CSS-Codes ergänzen oder Verändern. Zudem ist die Community ein nicht zu unterschätzender Faktor, dachte ich anfangs. In der Praxis hat sich das wenig ausgewirkt.

Heute scheint es mir, legt Google kaum noch Wert auf Blogger.com oder auch Feedburner. WordPress hingegen – auch zugegebenermaßen etwas konservativ inzwischen – wächst und gedeiht. Heute scheint es mir die bessere Plattform zu sein. Also: Good-bye, Blogger.com. Nun ja, nicht so ganz. Ich habe noch zwei Blogs da liegen, mal sehen, was ich mit denen so noch mache.

Solche Umzüge oder auch Migrationen sind sehr, sehr lästig. Zum Glück gibt es Plugins, die den Hauptaufwand übernehmen. Ich habe mich nach kurzer Suche für das Plugin „Blogger Importer Extended“ entschieden. Die bereits integrierte Funktion soll nicht so gut sein.

Der Import lief reibungslos, auch Bilder wurden mitmigriert. Die Fortschrittsanzeige blieb besonders bei den Bildern manchmal stecken, so dass ich schon schlimmste Befürchtungen hatte. Das Plugin nutzt Google APIs, die Restriktionen unterworfen sind. Daher kann der Transfer etwas dauern. Beim Durchchecken habe ich gesehen, dass einige Bilder in den Artikel nicht verkleinert angezeigt werden. Beim Klick darauf öffnen sie sich aber. Da ist also noch etwas Nacharbeit nötig. Auch, weil es bei Blogger.com keine Beitragsbilder gab.

Ich bin sehr gespannt, wie sich die Migration nun auf die Performance auswirkt. Google Webmastertools und Analytics habe ich mit Plugins realisiert. Jetpack ist auch integriert (ich finde dieses Paket richtig nett).

Mit WordPress kann man sicher schönere Seiten machen, allerdings ist das System schon aufwendiger. Das merkt man auch an der Ladezeit. Diese Installation läuft auf einem virtuellen Server mit 2 virtuellen Kernen und 2 bis 4 GB RAM.  Die PHP Version ist derzeit 5.4, eingebunden als CGI. Möglicherweise bringt das Umschalten auf die Integration als Apache Modul noch etwas mehr an Leistung und Geschwindigkeit. Mit den Werten wie Speicher und Skriptlaufzeit muss ich noch etwas spielen.

Veröffentlicht am

Drupal und Joomla Migrationen von Server zu Server

Joomla und auch Drupal sind eigentlich recht einfach zu migrieren, habe ich heute Nachmittag festgestellt. Es dauert lange wegen der Transferprozesse, aber im Grundsatz ist es nicht so schwer. Sowohl für Drupal als auch Joomla gibt es Module, die Backup und Mig unterstützen. Wenn man wirklich nur umziehen will ohne von einer Version auf die andere zu springen, geht es auch ohne.

Für Joomla als auch Drupal ist folgendes Migrationsvorgehen möglich:

1. Datenbank Dump erstellen. Dabei hilft das kostenlose Tool mysqldumper sehr gut. Das kann man auch für regelmäßige Backups einsetzen. Ist leicht und gut.

2. Den neuen Server vorbereiten:

  • Speicherplatz einrichten
  • Neue MySQL Datenbank anlegen, DB Name, DB User und Passwort merken
  • FTP Zugriff einrichten, Nutzername und Passwort merken

3. Alles, was auf dem alten Server im Joomla oder Drupal Verzeichnis liegt, muss per FTP herunter- und auf dem neuen Serverspeicherplatz wieder hochgeladen werden. Einfach so wie es ist.

3. Jetzt Mysqldumper auf dem neuen Server neu installieren bzw. konfigurieren, so dass die neue Datenbank angebunden ist. Das Backup, das normalerweise unter /work/backup im mysqldumper-Verzeichnis liegt wiederherstellen.

3. Nun müssen die Config-Dateien behandelt werden, um dort die neuen DB-Einstellungen einzutragen.

  • Bei Joomla heißt die Datei configuration.php und liegt auf der obersten Ebene des Joomla Verzeichnisses. In dieser Datei, die man mit dem Notepad bearbeiten kann, gibt es ein paar Variablen, die man anpassen muss:
var $dbtype = ‚mysql‘;
var $host = ‚localhost‘; (meistens ist das localhost)
var $user = ‚ ‚; (hier kommt der Datenbankbenutzername hinein)
var $db = ‚ ‚; (hier den Datenbanknamen hineinschreiben)
var $password = ‚ ‚ (hier das Passwort benennen)
  • Bei Drupal befindet sich die Datei setting.php unter  /sites/defaultAuch hier müssen die Datenbankparameter angepasst werden. Die Zeile sieht für gewöhnlich so aus:$db_url = ‚mysqli://username:password@localhost/databasename‘;An die entsprechenden Stellen muss man die gültigen Werte für die Datenbank auf dem neuen Server angeben.

Wichtig ist dann noch die Domain richtig zu routen oder umzuziehen.

Zumindest einfache Sites lassen sich so umziehen. Je mehr Module, Add ons etc mit umziehen müssen, desto mehr Fallen gibt es. Grundsätzlich: Servermigrationen sind etwas ekeliges. Am besten bei der Entwicklung schon immer mit dran denken, dass man auch einmal umziehen möchte, egal warum.

Was kann schiefgehen? 

Jede Menge. Das ist je genau das, was die Migs ekelig werden lässt.

Mysqldumper ist ein PHP Script. Viele Hoster begrenzen die maximale Laufzeit für PHP Scripts. Folge: Bei großen Datenbanken wird die Ausführung abgebrochen. Möglicherweise hilft es, nacheinander nur Teile der Datenbank zu backuppen. Ist zeitaufwendig und nervig, aber immerhin gibt es ja auch einen Grund, den Server zu wechseln.

Drupal macht intensiven Gebrauch von der .htaccess Datei und Rewrite-Vorschriften für die Url. Diese muss eventuell angepasst werden. Problematisch ist eventuell die Drupal Einstellung „lesefrendliche URLs“. Vor der Mig abschalten! Das kann nämlich dazu führen, dass man sich nicht mehr einloggen kann, auch wenn Datenbank und Website eigentlich erfolgreich kopiert wurden.

Möglicherweise sind im Content absolute Links innerhalb der eigenen Seite verwendet worden (habe ich auf Kundenwebseiten schon oft gesehen). Das wirkt sich dumm aus, wenn mit der Migration auch die Domain eine andere wird. Hier ist es wohl das beste, im Content die Änderungen vorzunehmen. Man könnte sich auch etwas .htaccess-mössiges vorstellen, aber das ist wohl komplizierter als die Änderung.

Wo läuft Joomla gut?

Das ist oft auch Geschmackssache, aber ich habe bei 1&1 und dem Paket „Homepage perfect“ gute Erfahrungen gemacht. Für nicht so kritische Websites ganz ok, auch von der Geschwindigkeit her. Wichtig ist bei der Installation von Joomla nur zu beachten, ein anderes Verzeichnis als Joomla Log-Verzeichnis anzulegen, da 1&1 selber auf einem Verzeichnis „log“ besteht.