Migration von CE 4.10.8 auf CE 6.4.1

Hast Dich auch an die Anleitung gehalten und nach der Migration auch die DB Views mit

vendor/bin/oe-eshop-db_views_generate

aktualisiert?

Quelle: Database — OXID eShop developer documentation 6.1.0 documentation

Aber 500er Fehler scheint andere Ursache zu sein, bei fehlenden DB Views würde die Maintenance Seite kommen.

500er Fehler deutet daraufhin, dass ggfs. die Shop Domain in der Datenbank nicht korrekt sein könnte oder noch ein Problem in den .htaccess Datei. Bei 500er Fehler musst in der Server Error Log nachschauen was schief läuft.

Ja, das mit der DB Views habe ich auch gemacht. Hatte ich jetzt nicht extra erwähnt, weil das sehr deutlich in der Doku beschrieben ist. Ansonsten habe ich die Migration so gemacht, wie oben erwähnt.

Die Shop-URL in der DB-Tabelle oxshops hatte ich angepasst.

In der htaccess sind keine statischen individuellen Werte. Sehe da aktuell kein Problem.

Die Server Error Logs sind für mich nichts aussagend.

Got error 'PHP message: PHP Fatal error: Allowed memory size of 1073741824 bytes exhausted (tried to allocate 262144 bytes) in /var/www/html/source/Core/Module/ModuleChainsGenerator.php on line 442\nPHP message: PHP Fatal error: Allowed memory size of 1073741824 bytes exhausted (tried to allocate 262144 bytes) in Unknown on line 0\n'

Ich meine, ein typisches Ergebnis, wenn etwas in einer Dauerschleife hängt.

Naja ist Speicherproblem. Daher wenn man lokale Entwicklungsumgebung hat Speicher erhöhen oder bei Hosterauswahl darauf achten. Mehr Infos zum Hosting Liste der Hoster für OXID6

das hat mit composer 1 zu 2 zutun update gleich auf die 6.4.2 mit composer 2

Nein. Da hängt etwas in der Migration. Der Shop läuft Lokal auf 4.10 mit dem vollen Livedatensatz. 6.0 läuft mit der Grundinstallation.

Die Seite lädt 5 Minuten lang ohne das etwas passiert, weil irgendwo etwas hakt. Ich arbeite mit dem neuesten MAC und ddev. Das ist Leistung genug.

Du meinst, ich solle die Dauerschleife einfach ignorieren und direkt weiter migrieren?

Ich habe die Dauerschleife weg bekommen, indem ich die aktivierten Module über die DB deaktiviert habe.

Am Ende lag es auch nur daran. Bis jetzt konnte ich weiter migrieren. 4.10 auf 6.0, dann auf 6.1 und bin aktuell 6.2, wo ich immerhin das Backend aufrufen kann. Im Frontend fehlen vermutlich nun die ganzen Plugins sowie Themes, da ich es auf eine Neuinstallation migriere.

1 Like

Ah okay stimmt. Das ein Punkt das wäre ein gute Hinweis Box in der Dokumentation.

Super! Freut mich :slight_smile:

Ja. :wink: Ich hatte den Hinweis in einem anderen Thread über die Forumsuche gefunden. Da sind einige andere gute Tipps dabei. Jedoch hoffe ich, dass ich von deren Fehler noch verschont bleibt. :smiley:

1 Like

Soweit hat die Migration und das Update auf CE 6.4.2 geklappt. Alle Daten sind da und das Theme ist auch soweit eingebunden, so dass es nach dem aussieht, wie unter 4.10.

Wenn ich aber nun versuche, einen Link anzuklicken, lädt die Seite neu und komme immer auf die Startseite. Die URL lautet dann immer index.php?force_sid=a64291fbfb1954cb98e7077f6b997d4f&cl=start&redirected=1 Muss ich noch irgendetwas an dem CMS-Seiten machen?

Bei den Updates bin ich von Version zu Version gesprungen. Ich habe keine Versionsnr. ausgelassen. Wenn ich aber z.B. hier Update from 6.2.x to 6.3.0 — OXID eShop 6.3 | User documentation den Punkt 2 so ausführen und dann weiter unten den composer update - Befehl durchführe, erhalte ich eine Reihe an Fehlermeldung, weil Abhängigkeiten fehlen oder falsche Version. Ich habe dann statt Punkt 2 und 3 zu machen, mir einfach die json-Datei aus github genommen. Dann über composer geupdatet und dann die weiteren Schritte befolgt. Kann man das so machen oder könnte das aktuell meine Probleme erklären?

Wenn mit Punkt 2

composer update --no-plugins --no-scripts --no-dev

und mit Punkt 3

composer update --no-dev

gemeint ist.

Dann JaNein (sorry hatte zuerst Ja geschrieben). Die beiden Befehle nacheinander haben bereits einen Sinn, wenn eine Fehlermeldung von Composer kommt diese zuerst analysieren was Grund sein könnte und versuchen zu beheben.

Eine Alternative welche häufig Abhilfe bringen kann ist

  1. vendor Verzeichnis löschen
  2. composer selfupdate 2.2.14
  3. composer install --no-dev oder composer update --no-dev

Dies hilft mir in vielen Abläufen wenn z.B. durch Modulinstallation was durcheinander gekommen oder halt auch bei einem Shop Update.

Immer durchdenken was man dort tut, was Composer macht und was das Ziel ist.

Dann solltest ja eine Fehlermeldung in oxideshop.log haben.

1 Like

Danke. Das sollte ich so langsam verinnerlichen.

Bei mir läuft der Shop nun. Bis auf eine Sache. Die Produktbilder werden nicht angezeigt. Bzw. es wird mir nur die nopic ausgegeben. Im Backend sind die Bilder vom Namen her richtig hinterlegt. Klickt man aber auch dort auf “Vorschau”, kommt das nopic-Bild.

Auch in der DB sind die Produktbilder richtig hinterlegt (oxpic1, oxpic2, usw.). Die Bilder sind auch im pictures generated Ordner vorhanden. Ich vermute, dass hier irgendwie ein Pfad falsch ist? In der config-Datei sind die Pfade richtig hinterlegt. Jemand eine Idee?

Das master Verzeichnis ist wichtig, aus dem master Verzeichnis werden die Bilder generiert. Das generated Verzeichnis kann jederzeit neu generiert werden.

Wahrscheinlich hast die Rechte nicht gesetzt wie in einer normalen Installationsanleitung in der Dokumentation erwähnt wird.

1 Like

Ich hatte mir gestern Abend damit beholfen, dass ich die Bilder neu hochgeladen habe. Da es bei mir nicht so viele Produkte gibt, ging das relativ schnell.

Dann kannst über den Bildnamen prüfen. ob der Pfad Deiner Bilder korrekt war und nur die Rechte nicht ausreichend. Bei Vorhandensein eines Bildes überschreibt oxid nicht, sondern hängt ein (1) ff. dran. Dann weißt beim nächsten Mal bescheid.

Wie kann man den Pfad von /out/pictures zu einem anderen Ordner (z.B. auf der Ebene von source unter /pictures) verlagern? Das heißt, auch wenn man im Backend Bilder abspeichert, sollen sie nicht im /out/pictures landen.

Problem ist halt, dass wenn ich ein Deployment über GIT durchführe, dass die lokalen Bilder auf Live ersetzt werden.

Edit:
Antwort selber gefunden.
Per Deploymentlib ein Symlink von /out/pictures auf den anderen Ordner setzen.

Hallo @Dirk_S ,

wart ihr schon erfolgreich?

Wir stehen vor der gleichen Herausforderung.
OXID 4.10.2 und PHP 5.6…

Wir haben einen externen Berater, aber der sagt eine Migration auf 6.4 sei nicht möglich… wir sind ja aber quasi darauf angewiesen, um PayPal nicht zu verlieren.

Uii :face_with_peeking_eye:

Wären wahrscheinlich mehrere Migrationsschritte, was eine Migration sehr aufwendig macht. Daher könnte man im Einzelfall, wenn z.B. die Kategorien- und Produktdaten aus einer externen Warenwirtschaft kommen, einen frischen Shop aufsetzen.

Letztendlich wird man Abstriche machen müssen je nach Budget z.B. alte Bestellhistorie, Kundendaten nicht mitnehmen.

Dies ist aus meiner Sicht die falsche Herangehensweise. Ihr solltet Interesse daran haben aktuelle Software einzusetzen. PHP Version 5.6 ist sehr veraltet und birgt verschiedenste Risiken.

Ggfs. wäre ein Neustart Eures Shops am sinnvollsten.

Mach doch bitte einen eigenen Thread dazu auf.

Verstehe ich nicht. Natürlich kann man den Shop auf 6.4 updaten:
4.10 → 6.0 → 6.1 → 6.2 → 6.3 → 6.4
Jeder dieser Schritte ist in der Doku beschrieben. Module und Theme aus der 4.10 kannst du nicht verwenden, du brauchst von beidem neue Versionen. Sollte man also bereits vor dem Update auf 6.0 deaktivieren.

1 Like

Normalerweise ist das, wie schon erwähnt wurde, kein Problem.

Beschreibe doch bitte, warum es aus Sicht des Beraters nicht möglich sein soll.