Guten Morgen,
im Forum habe bisher leider zu o.g. Thema keinen Eintrag gefunden. Ich will kurz den Ist-Zustand erläutern und dann den Soll-Zustand:
zur Zeit benutze ich Oxid 4.10.4 CE
habe Flow (lieder nicht im Child-Modus) als Themes
arbeite per CAO-Schnittstelle der 1.4.x Version
nun möchte ich gerne auf die 6.2.x Version updaten.
Die Updates, die ich gefunden habe, verlangen aber 4.10.6 CE. Ein anderes Umpdate kann ich leider nicht finden.
Sollte ich, wenn überhaupt möglich updaten oder besser neu installieren?
Für Hilfen und Hinweise wäre ich Euch sehr dankbar.
Gruß aus dem Sauerland.
Update auf Oxid 6 ist immer eine Neuinstallation. Vom alten Shop wird die DB übernommen und mit zwei Skripts auf den Stand von 6.0 gebracht, dafür kannst du auch die 4.10.4 als Basis nehmen, da es von 4.10.4 auf 4.10.6 keine Datenbankänderungen gab. Deine Module und dein Theme musst du 6.x kompatibel machen oder neue 6.x-kompatible Versionen verwenden.
Das Update und die Migration der Datenbank haben bei mir einwandfrei funktioniert.
Es dauert aber einige Tage bis alle Anpassungen und Module, die in 4.10 liefen, auch auf 6.2 aktualisiert sind.
Es dürfte selten vorkommen, dass ein aktiver 4.10-Shop mit Anpassungen und Modulen auf 6.2 umgestellt wird und sofort online geht.
Wie kriege ich denn nun die in der Zwischenzeit veränderten Daten (Artikel, Kunden, Bestellungen) von der 4.10 Installation nach 6.2?
Wenn ich die Migration erneut mache, werden ja auch Datenbank-Einträge von neuen Modulen überschrieben.
Ganz einfach mit Beginn der Migration machst Du auf einem Testsystem das 1. Mal die Datenmigration und führst auf dem Testsystem alle weiteren Anpassungen bezüglich Theme, Module und Schnittstellen durch.
Wenn in Deinem Testsystem dann einen Stand erreichst hast, musst am Tag der Umstellung auf 6.2 die Datenmigration wiederholen um einen aktuellen Datenbestand zu haben. In dieser Zeit ist der Shop dann im optimalsten Falle ca. 4 Stunden offline. Deswegen macht man die Umstellung auch meistens Nachts wenn wenig Besucher auf dem Shop.
Deswegen sollte man wissen was man tut. Dies aber normales vorgehen. Deswegen die Planungsphase so wichtig.
Dies wäre auch eine Möglichkeit um Grundeinstellungen und Co. zu übertragen. Aber dies könnte man notfalls auch händisch machen indem man die Grundeinstellungen von seiner Testumgebung mit der Produktivumgebung dann vergleicht.
Aber wenn man die Datenmigration später bei LIVE Schaltung erneut durchführt sollten die Grundeinstellungen sich nicht unbedingt von der Testumgebung unterscheiden außer man hat während der Migration auf der Testumgebung bewusst Einstellungen geändert. Dann muss man dies natürlich auf der späteren LIVE Umgebung auch tun.
Für die Module gilt ab OXID eShop Community Edition 6.2 das die Modul Konfiguration aus der 1.yaml Datei kommt und über den Konsolen Befehl
Wozu? Wenn der migrierte Shop in 6.2 so läuft, wie der Inhaber es will und nur die aktuellen Artikel, User und Bestelldaten fehlen, ist dies die zeitlich kürzeste Methode, die Einstellungen zu übernehmen.
Dafür einfach nach Kopie der oxconfig die Module einmal deaktivieren und wieder aktiveren. Das ist kürzer, als alle Einstellungen neu eingeben zu müssen.
Weil je nach Aufwand durchaus 3 Monate zwischen erster Migration für Testumgebung und zweiter Migration für LIVE Schaltungstermin vergehen können.
Dies heißt es kann sich unbewusst einiges getan haben in den Einstellungen.
Langfristig sollen für das Deployment alle Einstellungen in Konfigurationsdateien abwandern. Dies die Vision von OXID eSales. Daher ist aus meiner Sicht immer die Datei 1.yaml ausschlaggebend und nicht die Datenbank.
Die Datenbank lässt sich immer wieder generisch neu befüllen. Daher gehört die 1.yaml Datei mit ins Repository für das Deployment. Dies nachhaltiger um z.B. eine Kopie vom Shop zu erstellen mit identischen Einstellungen.
Genau darum geht’s. Bei der Migration von 4.xx ist nichts vorhanden, sodass man es hier abkürzen kann und schon erstellte Werte übernimmt, statt sich damit erneut aufzuhalten. So muss auch kein Shop stundenlang offline sein.
Interessanter Ansatz. Dies natürlich auch eine Option.
Selber durchlaufe ich die Migration bei LIVE Schaltung nochmal, weil ich Angst habe was zu vergessen was während der Entwicklungszeit alles geändert wurde und mir später auf die Füße fällt.
Die Kunden- und Bestelldaten müssen ja zwingend durch die Migration hindurch.