Da mir diese Frage immer wieder begegnet, möchte ich einmal meinen Weg beschreiben, wie man einen Magento Shop-Umzug von einem Server zum anderen umziehen kann und was es dabei zu beachten gibt.

Ich gehe in diesem Fall sehr wohlwollend davon aus, dass die Server über einen sogenannten SSH-Zugang verfügen.

(1) Die Datenbank

Vor dem Erstellen eines Datenbank-Backups sollte man die Caches im Shop deaktivieren. Außerdem sollte man die Cookie-Einstellungen überprüfen und ggf. zurücksetzen.

System->Cacheverwaltung

System->Konfiguration->Allgemein->Web->Sitzungscookie Verwaltung

Dann kann ein Backup der Datenbank erstellt werden. Für diesen „Dump“ muss die sogenannte Fremdschlüsselüberprüfung deaktiviert werden, weil sich der Dump ansonsten nicht wieder importieren lässt.

Es gibt drei Wege für so ein Datenbank-Backup-File.

(a) Über den Shop
(hier reichen aber oft die Serverkapazitäten nicht aus, das ist also der suboptimalste Weg):
System->Werkzeuge->Sicherungen->Nur Datenbank sichern

(b) Über PHPMyAdmin

Exportieren, dann „angepasst“ wählen.
Alle Tabellen anwählen.
Ausgabe: Speichere Ausgabe in Datei
Format: SQL
Wichtig bei „Formatspezifische Optionen“: Häkchen bei „Fremdschlüsselüberprüfung deaktivieren“ machen!
Alles andere kann so bleiben, wie es ist…
Und dann „OK“ für den Export klicken.

(c) Über SSH und „mysqldump“

Im Normalfall erstellt man erst ein Verzeichnis für das Backup und wechselt in dieses, um dann dort den Dump auszuführen:

mysqldump -h[SERVER] -u[USERNAME] -p[PASSWORT] –disable-keys [DATABASENAME] > [FILENAME].sql

Ich überprüfe den Dump dann immer, bevor ich ihn auf dem neuen Server einspiele. Also erstmal probieren, ob er sich auf meinem lokalen Server importieren lässt. Wenn das problemlos klappt: gut.

Wenn das File sehr groß ist (ich meine hier Gigabytegroß), dann lohnt es sich, die Datenbank aufzuräumen, bevor man sie wieder auf dem neuen Server importiert. Das ist aber Geschmackssache und manchmal sind die Daten ja auch relevant. Große Datenbanken sind meist wegen der Besucher-Logs so groß, die im schlimmsten Fall noch nie bereinigt wurden. Viele Shopbetreiber haben aber noch nie in die „Reports“ oder „Berichte“ gesehen – dann kann man bedenkenlos in der lokalen Kopie der Datenbank die folgenden Tabellen leeren (nicht löschen):

TRUNCATE dataflow_batch_export;
TRUNCATE dataflow_batch_import;
TRUNCATE log_customer;
TRUNCATE log_quote;
TRUNCATE log_summary;
TRUNCATE log_summary_type;
TRUNCATE log_url;
TRUNCATE log_url_info;
TRUNCATE log_visitor;
TRUNCATE log_visitor_info;
TRUNCATE log_visitor_online;
TRUNCATE report_viewed_product_index;
TRUNCATE report_compared_product_index;
TRUNCATE report_event;

Wenn ich dies tue, mache ich einen erneuten Dump von dieser Datenbank, prüfe wieder, ob sie sich importieren lässt und wenn ja, darf er auf den neuen Server. Dort am besten das File auf den Server spielen und im besten Fall auch per SSH einloggen und die Datenbank importieren.

mysql -u[USERNAME] -p[PASSWORT] [NEWDATABASENAME] < [FILENAME].sql

Die < oder > Angabe bitte genau beachten...

(2) Die Dateien kopieren

Auf dem alten Server am besten ebenfalls per SSH eine Zip-Datei von der kompletten Installation erstellen (mittels zip/unzip oder je auch tar). Diese auf den neuen Server transferieren und dort entpacken.

Wenn das Zip zu groß ist, müsste man vor dem Packen und Entpacken wahrscheinlich das „media“-Verzeichnis aufräumen. Magento speichert, wenn Produktbilder hochgeladen werden, alle Bilder brav auf dem Server ab, ohne die alten zu löschen. Dadurch sammelt sich im Laufe der Zeit so allerlei an. Das kann man entweder über ein eigenes Script oder eine Extension suchen, die das passend zur Magento-Version für einen macht. Einfach mal nach „magento remove unused images“ googeln.

Da beim Zippen auch der var-Ordner mitgenommen wird, kann man auch vorab den Cache leeren, wenn dieser zu groß geworden ist....

Wenn alles drüben und entpackt ist:
als erstes die Datei- und Verzeichnisrechte überprüfen und ggf. anpassen.

find . -type f -exec chmod 644 {} ;
find . -type d -exec chmod 755 {} ;

Oder:

http://devdocs.magento.com/guides/m1x/install/installer-privileges_after.html

Es werden meist die Rechte 644 für Dateien und 755 für Ordner vergeben. Manchmal geistern auch 777 Rechte für media und var durchs Netz. Meines Wissens reichen 755er im Normalfall völlig.

Wer sich das nicht zutraut, kann das Magento „Cleanup Tool“ ergooglen und einsetzen. Das setzt diese Rechte ebenfalls. Ich weiß allerdings gar nicht, ob es das noch gibt... Lange nicht gesehen...

(3) Shop anpassen

(a) Die URL des Shops

Wenn die Domain noch nicht mit umzieht und der Shop zunächst unter einer anderen URL läuft, muss man die URL-Einträge in der Datenbank direkt ändern.

In den meisten Anleitungen wird nur angegeben, die 'web/unsecure/base_url' und die 'web/secure/base_url' zu ändern. Wenn es ein Multi-Shop mit unterschiedlichen URLs ist, muss man die der anderen Stores ggf. auch abhändern und wenn in den skin/media/js-Angaben auch absolute URLs angegeben wurden, muss man diese auch ändern.

Also am besten suchen nach:

SELECT * FROM core_config_data WHERE path LIKE '%web/%' 

Dann kriegt man alle zu ändernden Einträge raus...

In PHPMyAdmin geht das ja recht kompfortabel. Ansonsten geht‘s auch per SSH über direkte MySQL-Befehle...

UPDATE `core_config_data` SET `value` = '[NEUE_URL_MIT_/_AM_ENDE]' WHERE `core_config_data`.`path` = 'web/unsecure/base_url';
UPDATE `core_config_data` SET `value` = '[NEUE_URL_MIT_/_AM_ENDE]' WHERE `core_config_data`.`path` = 'web/secure/base_url';

(b) Die Datenbank-Zugangsdaten

Als nächstes in der Datei app/etc/local.xml die Datenbank-Daten der neuen Datenbank angeben. Wichtig (weil schon erlebt): NICHT die local.xml umbenennen in local-old.xml oder sowas... Hier werden einfach alle .xml-Dateien gelesen und das kann zu Problemen führen. Also einfach neue Daten reinschreiben und fertig.

(c) Die .htaccess überprüfen

Es gibt immer wieder Angaben (vor allem zu den Rewrites), die in den .htaccess-Dateien stehen. Dann landet man im Normalfall im alten Shop. Auf die Schnelle ist es am einfachsten, sich Magento nochmal runterzuladen in der Version, die man verwendet und aus dieser Datei die .htaccess zunächst zu verwenden und die Anpassungen danach wieder vorzunehmen oder nach dem Domainumzug die vorherige .htaccess-Datei wieder einzusetzen.

Wenn es keine .htacess-Datei gibt, sind im Zip keine versteckten Dateien – und dann nochmal ab Punkt 2 anfangen und das Zippen mit versteckten Dateien vornehmen...

(4) Alles, was gerne vergessen wird...

(a) Cronjobs

Serverseitig müssen die Cronjobs wieder auf die cron.sh (oder cron.php, wenn‘s nicht anders geht) losgelassen werden. Wenn dies in derselben Taktung wie im alten Shop erfolt, muss man am Shop nichts ändern, wenn die Taktung sich ändert, muss die Cronjob-Konfiguration dementsprechend angepasst werden.

(b) Gzip-Komprimierung

Das wird, wenn der Server das kann, im Normalfall in der .htaccess-Datei aktiviert. Wenn der Server das nicht kann: Servermenschen ansprechen.

(c) SSL-Zertifikat

Gerne vergessen: für den neuen Server braucht man ebenfalls ein SSL-Zertifikat, das dort hinterlegt werden muss, um „https“ verwenden zu können.

(d) Connect Manager

In alten Magento-Versionen sollte man unter downloader/pearlib die pear.ini löschen.

(e) Den Cache im Ursprungsshop wieder zu aktivieren und die Cookie-Einstellungen wieder in den vorherigen Zustand zurückzuversetzen...