Magento von 1.9.0.1 auf 1.9.3.0 upgraden

Geschrieben von kingalca am 17. November 2016
Dieser Post ist über ein Jahr alt. Eventuell haben sich die Details mittlerweile geändert, oder Links sind nicht mehr verfügbar.

Magento von 1.9.0.1 auf 1.9.3.0 upgraden

Jüngst hatten wir einige Kunden in der Arbeit, die gerne auf die aktuelle Magento-Version upgraden wollten. Normalerweise veranschlagen wir so um die 6-10 Stunden für ein Upgrade, weil wir vorher nie ganz genau wissen können, ob die Updates einfach so durchgehen, oder ob es eben Bugs beim Upgrade gibt.

Meistens reicht die Zeit, die wir anbieten. Manchmal gibt es aber auch Probleme und wir können den Kunden ja nur eher schlecht sagen: Sorry, der Entwickler hat sich verschätzt. Dauert jetzt dreimal so lang, weil Bugs.

Beim Upgrade von Magento 1.9.0.1 auf Magento 1.9.3.0 wird empfohlen, dass man einen neuen Ordner im Webverzeichnis anlegt, dort eine cleane Magento 1.9.3.0 Installation (ohne Installation via Web) platziert und dann alle Custom Files aus dem alten Ordner in den neuen kopiert, OHNE dabei bestehende Files zu überschreiben.

An sich gar nicht so dramatisch, denn mit SSH-Zugriff lässt sich meist rsync hierfür nutzen. Nun gibt es aber einen größeren Haufen an Hostern, die weder SSH noch rsync zulassen. Hier muss man ein wenig ums Eck denken, schwer ist es aber dennoch nicht.

Gehen wir davon aus, dass dir rsync nicht zur Verfügung steht, so bleibt nur der cp-Befehl.

Unsere Ordnerstruktur sieht nun wie folgt aus:

  • Root (/var/www/web/)
    • magento-v1 (bisher genutzt 1.9.0.1 Files)
      • app
      • lib
      • skin
      • var
    • magento-v2 (1.9.3.0 Filebasis)

Wir möchten alle Ordner, in denen wir Custom Files haben, in den Ordner magento-v2 kopieren. Welche Ordner sind das?

Zumeist ist eine Kopie des app/-Ordners recht sinnvoll, ich spezifiziere dies aber zur Beschleunigung immer gerne, da der app/code/core-Ordner ja grundsätzlich nicht angefasst werden möchte.

Als Beispiel:
$ cp -R -u /var/www/web/magento-v1/app/code/community/* /var/www/web/magento-v2/app/code/community

Mit diesem Befehl kopiere ich via SSH (oder SH-Script, welches per Cron ausgeführt wird) die ganzen Module, die in unserer alten Installation drin waren. Nach dem Ausführen dieses Befehle ist die Ordnerstruktur im neuen Verzeichnis angepasst, alle Module befinden sich nun auch dort. Jetzt könnte man so weitermachen und Zeile für Zeile alle Ordner kopieren, ich mache es mir da ein wenig leichter und erstelle mir ein .sh-Script, in dem bereits alle notwendigen Zeilen stehen.

Zeile 2 pwd=$(pwd) gibt mir den momentanen Arbeitspfad in SSH zurück. Daher ist es notwendig, dass man das Script im Root-Ordner (/var/www/web/) ausführt, um Fehler zu vermeiden. In der dritten und vierten Zeile erweitere ich den Pfad auf die jeweiligen Ordner und schreibe den Inhalt in die respektiven Variablen.

Diesen Inhalt schreibe ich via $ nano copy.sh in eine neue Datei und speichere sie. Danach kann ich die File mit ./copy.sh ausführen. Gegebenfalls muss man der File ausführbare Rechte geben, dies gelingt mit chmod +x copy.sh. Nach Abschluss des Prozesses sollten in der neuen Ordnerstruktur alle alten Files vorhanden sein, ohne dabei bestehende Files überschrieben zu haben.

Nun benötigen wir noch eine local.xml im Ordner app/etc/. Wir können die Datei aus dem alten Verzeichnis zumeist 1:1 kopieren. Ich kopiere also die local.xml aus $OLDDIR nach $NEWDIR und passe die Datenbankdetails an, da ich zuvor die Datenbank gespiegelt habe, um einen Rollback bei gravierenden Fehlern jederzeit durchführen zu können. Wichtig: Magento bietet eine eigene Rollbackfunktion NICHT an.

So, Lirumlarum Löffelstiel, was bleibt jetzt noch zu tun? Eigentlich nichts. Ich muss nur noch die Domain umstellen, diese routet ja noch auf /var/www/web/magento-v1. Ich ändere das Routing also auf den neuen Ordner, speichere und begutachte mein Werk. Zu sehen ist nun eine Magento 1.9.3.0-Installation. Verifizieren kann ich dies im Backend, dort steht in der Footerleiste immer die aktuelle Version.

Man muss die Datenbank natürlich nicht spiegeln. Ich mache dies jedoch immer aus Sicherheitsgründen, um eben bei unvorhersehbaren Bugs im Zweifelsfall schnell zum alten Stand zurückkehren zu können.