FOL9000

Magento-Update von 1.7.0.2 nach 1.8.0.0

von | 4 Kommentare

Ein paar Tage ist es jetzt schon her, dass die 1.8er-Version von Magento veröffentlicht wurde. Ich schätze, dass trotzdem viele die Umstellung von der Version 1.7.0.2 auf die 1.8.0.0 noch nicht gemacht haben. Zwar gibt es ein paar ganz gute Seiten zum Thema Update von Magento selbst, aber weil die nicht gerade besonders übersichtlich sind und ich bei meinem ersten Update-Versuch gleich ein Problem hatte, will ich hier mein jetzt schon mehrfach erfolgreiches Vorgehen beschreiben.

Update: Bei mir hat dieses Vorgehen auch bei einem Update von 1.9.0.1 auf 1.9.1.0 gut funktioniert! Näheres, auch zu anderen Versionen findet sich in einem neueren Beitrag.

Wichtig: Auf jeden Fall sollte man sich die PHP-Fehler anzeigen lassen, sonst ist die Fehlersuche ein Blindflug. Dazu in der Datei index.php direkt am Anfang bei „Error reporting“ ini_set('display_errors', 1); setzen.

Bei mir gab es in einem Falle einen Fehler mit einer von mir geänderten core-Klasse (I18N). Gottseidank war das sowieso Unsinn und konnte raus. Im Fehlerfalle sollte man deshalb die eigenen Änderungen und Extensions sukzessive durchgehen — eine wirds schon sein, die die Probleme verursacht. Vielleicht sind ja welche dabei, die vermeintlich Probleme älterer Versionen beheben sollen, die können als erste raus. Bei Problemen würde ich zudem Extensions zunächst alle deaktivieren und dann eine nach der anderen wieder anstellen.

Die folgende Update-Anleitung geht davon aus, dass ein neuer Shop parallel zu einer alten Version installiert wird. Sie beschreibt also nicht, das Update einer bestehende Live-Installation, sondern vielmehr, wie ein Testsystem installiert werden kann, mit dem man erst einmal die Funktion seines Shops testen und sicherstellen kann.

Grundsätzlich muss zunächst die Datenbank kopiert und leicht angepasst werden und weiter die individuellen Shop-Dateien (Media, Skins etc.) in eine neue Installation kopiert werden. Den Rest erledigt Magento beim ersten Start der upgedateten Version dann selbst.

Datenbank kopieren

Im ersten Schritt wird also die Datenbank einer bestehenden Installation kopiert und angepasst. Man kann dies je nach benutztem Tool wahrscheinlich auf verschiedenen Wegen erreichen. In phpmyadmin gibt es eine Funktion zum Kopieren einer Datenbank, ich hab mich für den simplen Weg des Ex- und Imports entschieden.

Vor dem Export der alten Datenbank sollte man den Cache deaktivieren, damit er als Fehlerquelle beim Update keine Rolle mehr spielen kann. Dann mit dem Tool der Wahl einen Export der alten Datenbank machen, eine neue Datenbank anlegen und die exportierten Daten in die neue Datenbank importieren. Bei einem normalen SQL-Export steht am Anfang der Export-Datei zwei mal der Name der zu verwendenden Datenbank (CREATE und USE). Hier muss vor dem Import der Name der neu angelegten Datenbank eingetragen werden.

Nicht vergessen, dass der Magento-Datenbank-User auch die passenden Rechte für die neue Datenbank bekommt.

Da ich wie gesagt davon ausgehe, dass zunächst ein Test-Shop parallel zum alten Shop installiert wird, müssen in den importierten Daten die Werte für die Shop-URLs angepasst werden.
Diese Einstellungen finden sch in der Tabelle core_config_data als key/value-Paare. Die Werte unter folgenden Keys (hier path genannt) müssen auf jeden Fall angepasst werden:

  • web/secure/base_url
  • web/unsecure/base_url

Wenn Skin-, Media und JavaScript-URLs geändert hat, müssen auch diese angepasst werden. Sie finden sich unter folgenden Keys:

  • web/secure/base_js_url
  • web/secure/base_skin_url
  • web/secure/base_media_url
  • web/unsecure/base_js_url
  • web/unsecure/base_skin_url
  • web/unsecure/base_media_url

Damit ist die Datenbank auf dem Stand, dass es mit Magento weitergehen kann.

Magento einrichten

Archiv auspacken

Nachdem die Datenbank fertig ist, ist nun Magento selbst dran. Im ersten Schritt wird schlicht das Magento-Archiv auf dem Server ausgepackt. Danach nicht den Shop im Browser aufrufen! Es müssen erst noch ein paar Dateien kopiert werden.

Individuelle Shop-Dateien kopieren

In bzw. über die gerade ausgepackten Magento-Dateien werden nun die individuellen Dateien des alten Shops kopiert. Die folgende Liste führt nur die Dateien auf, die auf jeden Fall kopiert werden müssen. Je nachdem, was man am alten Shop individualisiert oder umgebaut hat, können weitere Dateien dazu kommen.

Kopiert werden müssen:

  • Skins,
  • /media,
  • /app/code/local,
  • /app/code/community,
  • /app/etc/config.xml falls geändert (bei mir nicht), auf jeden Fall aber die Datei local.xml (hier muss mindestens die Datenbank-Verbindung angepasst werden!),
  • die Konfigurationsdateien der installierten Module unter /app/etc/modules,
  • die eigenen Templates unter /app/design/frontend,
  • falls geändert bzw. vorhanden: .htaccess und robots.txt sowie
  • ggf. Dateien aus dem shell-Verzeichnis.

Außerdem: Alle weiteren geänderten Dateien. Hier muss man selber wissen, wo man Änderungen vorgenommen hat. Bei einigen meiner Installationen sind dies z.B. ein paar Dateien im js-Verzeichnis — das ist aber sehr individuell. Ich schreibe das hier v.a., weil man diese Dateien eben nicht vergessen darf.

Folgendes war bei mir jedoch ganz wichtig!

  • Die Dateien des deutschen Sprachmoduls nicht mitkopieren! Die deutsche Übersetzung hat bei mir große Probleme verursacht. Schlimm ist das nicht, denn wenn der Shop erstmal läuft, kann das Sprachpaket einfach neu installiert werden.
  • Eigenen Code unter /app/code/local/Mage zunächst nicht mitkopieren. Ich weiß, da sollte sowieso nichts hin, aber trotzdem, in einer Installation hatte ich diesen Fall. Der Aufruf von Magento brach deswegen mit ‚Undefined class constant ‚DEFAULT STRING“ ab. Bei mir reichte es, dass Mage-Verzeichnis zunächst umzubenennen, den Shop aufzurufen (s. nächsten Absatz) und das Verzeichnis dann wieder in ‚Mage‘ umzubenennen.

Shop aufrufen

Damit sind die Vorarbeiten erledigt, um den neuen Shop aufzurufen. Magento wird bei diesem ersten Aufruf weitere Installationsarbeiten erledigen, v.a. die Datenbank auf den neuesten Stand bringen. Deshalb kann dieser erste Aufruf auch recht lange dauern. Und wegen der Dinge, die Magento beim ersten Shop-Aufruf anpasst, darf auch wirklich erst jetzt, nachdem alles andere erledigt ist, der Shop das erste mal wieder aufgerufen werden.

Und der Rest

Zwei Dinge gibt es nun noch zu erledigen: Den Cache wieder aktivieren und das deutsche Sprachpaket installieren (es wurde ja nicht mit aus der alten Installation kopiert).

Wie eingangs geschrieben, hat dieses Vorgehen bei mir mehrfach ohne Probleme funktioniert. Wenns nicht klappt könnten typische Fehlerquellen v.a. nicht-kompatible Extensions, falsche Schreib-Rechte auf dem Server oder fehlende Datenbank-Rechte sein.

4 Kommentare

  1. Hallo, mit großem Interesse habe ich Ihren Beitrag zum Magento-Update von 1.7.0.2 auf 1.9 gelesen und natürlich auch sofort versucht dies umzusetzen. Dazu wurde wie beschrieben von der Live-Installation via MySQL ein Datenbank-Export gemacht, nachdem der Cache deaktiviert und bereinigt wurde. Anschließend Lokal unter xampp eine gleichlautende Datenbank angelegt und versucht den Export dort zu importieren. Leider ohne vollständigen Erfolg, 211 Tabellen wurden eingelesen und folgender Fehler wurde von MySQL ausgegeben:

    Es scheint einen Fehler in Ihrer MySQL-Abfrage zu geben. Die MySQL-Fehlerausgabe, falls vorhanden, kann Ihnen auch bei der Fehleranalyse helfen.
    ERROR: Unbekannte Interpunktion @ 20
    STR: ><
    SQL:
    FehlerSQL-Befehl:

    sql_query=SHOW+TABLE+STATUS+FROM+%60datenbank%60+WHERE+Name+%3D+%27log_url_info%27&show_query=1&db=datenbank&token=4e8982adf9f6f517774ff744aabc118f“ rel=“nofollow“> 

    SQL-Befehl:
    FehlerSQL-Befehl: sql_query=SHOW+TABLE+STATUS+FROM+%60datenbank%60+WHERE+Name+%3D+%27log_url_info%27&show_query=1&db=datenbank&token=4e8982adf9f6f517774ff744aabc118f“ rel=“nofollow“> 

    MySQL meldet:
    #1064 – You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ‚FehlerSQL-Befehl:
    at line 1

    Gibt es ggf. eine andere Möglichkeit, Accounts, Kunden, Rechnungen, Bestellungen, etc. von 1.7.0.2 zu exportieren und in eine lokal neu aufgesetzte 1.9 zu importerien oder auch kopieren, wenn dies die Tabellenstrukturen zulassen. Angedacht ist, den aktuellen Shop auf die Magento DE 1.9, die ja schon die länderspezifischen Erweiterungen beinhaltet.

    Wäre für jeden Tipp dankbar!

    • Eine einfache Möglichkeit, Accounts, Kunden, Rechnungen, Bestellungen etc. einfach rüberzuziehen kenne ich nicht. Es geht jedenfalls nicht, die alten Tabellen einfach zu kopieren.

      Der geschilderte Fehler kann aber eigentlich auch nichts mit Magento zu tun haben, sondern es gibt schon in MySQL ein Problem.

      Die Fehlermeldung ‚Unbekannte Interpunktion‘ deutet darauf hin, dass etwas mit dem Export, den Du wieder einliest nicht in Ordnung ist.

      Spontan würden mir zwei Dinge zu diesem Fehler einfallen:

      Vielleicht ist das Zeichenformat beim Export und bei der neuen DB nicht gleich? Ich denke aber, dann hätte es noch mehr Probleme gegeben.

      Oder wahrscheinlicher: Der Export ist unvollständig und hat irgendwo (vielleicht mit einem Fehler) abgebrochen. Schau die die Datei mal mit einem Editor an, der große Dateien verkraftet. Vor allem das Dateiende wird interessant sein.

      Wenn die Exportdatei tatsächlich nicht ok ist und sich das nicht anders hinkriegen lässt, kannst Du es mal mit einem anderen Programm (z.B. MySQLDumper) oder anderen Parametern versuchen. (Ich kenne mehrere Shops, wo der phpmyadmin-Export einfach abbricht).

      Bin mal gespannt, ob das weiterhilft…

  2. Vielen Dank für den Tipp und die Infos zu den evtl. Ursachen, denn tatsächlich scheint es so zu sein, dass der Export irgendwo abgebrochen wird ohne eine entsprechende Meldung abzusetzen, dies zeigt sich auch daran, dass mehrere Exports völlig unterschiedliche Dateigrößen zeigten. Also habe ich wie angegeben den MySQLDumper auf den Webspace als auch lokal installiert. Die Backup-Erstellung auf dem Webspace ging zügig. FTP-Transfer vom Webspace in den entsprechenden lokalen Ornder mit folgendem Wiederherstellen brachte dann dahingehend Probleme, dass hier wohl Tabellen dabei sind, die sehr groß sind und dann ewig zum Wiederherstellen brauchen (> 16 Std.!) und nicht selten abbrechen. Nun gut diese großen Tabellen habe ich mal versucht zu identifizieren und im Web nachzuschlagen was deren Sinn und Inhalt denn ist. Dabei gibt es Tipps die ein leeren dieser Tabs vorschlagen. Dies habe ich mir bis dato noch nicht getraut. Was derzeit läuft sind partielle Backups, d.h. eines ohne die folgenden Tabs, diese werde ich einzeln als Backup ziehen, testweise leeren und lokal importieren. Mal sehen was dies dann bewirkt!

    Hier die problematisch großen Tabs:
    log_url 61,13MB
    log_url_info 134,69MB
    log_visitor 30,56MB
    log_visitor_info 52,59MB
    report_event 27,09 MB
    report_viewed_product_index 27,09MB

    Die derzeit laufende lokale Wiederherstelltung ohne die o.g. Tabs läuft aktuell 63 Minuten bei 60,07% Fortschritt, d.h. in ca. 1 Std. sollte dieser erste Part durch sein …

  3. Noch ein paar Hinweise dazu:

    Ich würde mal schauen, wie man den MySQLDumper dazu bringt, die Backups in ein (nicht öffentlich zugängliches) Verzeichnis auf dem Server abzulegen. So spart man sich zumindest den nicht unerheblichen und ja auch oft langsameren Upload. Das sauber hinzukriegen lohnt sich allein schon wg. des Backups.

    Das Bereinigen der Logs scheint mir auch eine gute Idee, dass kann man aber auch mit Magento-Bordmitteln, vgl. z.B. die Anleitung hier:
    https://docs.nexcess.net/article/how-to-perform-magento-database-maintenance.html
    (Setzt natürlich die cron-Konfiguration voraus, das sparen sich ja viele…)

    Und schließlich: phpmyadmin hat eine Funktion zum Kopieren einer Datenbank. Ich glaube unter dem ‚Operations‘-Tab. Da gibts auch diverse Optionen. Einfach mal googeln.

    Kann man alles ja auch erstmal lokal ausprobieren.

Schreibe einen Kommentar

Pflichtfelder sind mit * markiert.