Der Shop läuft unter PHP 7.1
Der Composer unter SSH läuft mit PHP 7.2 (wenn ich 7.1 einstelle, dann bringt mir composer update bei irgendeinem der vielen Module einen Fehler).
Bezüglich dem Segmentation fault habe ich aber vorhin schon PHP 7.1, 7.2 und 7.3 durchprobiert.
Kann ich im jetzigen Zusand des Shops irgendwie über die Console Module deinstallieren oder muss ich hier wieder einige Schritte zurück?
[quote=“Sir_Paladin, post:21, topic:98061”]
wenn ich 7.1 einstelle, dann bringt mir composer update bei irgendeinem der vielen Module einen Fehler)
[/quote]`
Das Live-Shopupdate ist nun endlich durch … aber es war rückblickend eine schwere Geburt.
Wie von Daniel empfohlen hatte ich alle D3-Module deinstalliert.
Bei der Deaktivierung des Modulconnectors über das backend trat ein Fehler auf, weshalb ich das Modul nicht deaktivieren konnte. … extrem seltsamer Fehler (denn dieser Fehler ist bem Support von D3 nicht aufgetreten). Nachdem ich meine Cookies zum Shop gelöscht hatte, konnte ich auch endlich dieses Mudul deaktivieren. … sehr komisch!
Dann habe ich wieder meine Update-Generalprobe begonnen…
und dabei kam WIEDER dieses Segmentation error.
In meiner Verzweiflung hatte ich dann diesen Befehl mehrmals hintereinander (Pfeil hoch → Enter) (mit oben beschriebener Speicherplatzerhöhung für PHP) ausgeführt und beim dritten mal lief das Skript durch. Juhuuu! Aber dennoch mit einem negativem Beigeschmack. Naja.
Als ich dann das Live-Update durchgeführt hatte, kam wieder der Segmentation error.
Und beim zweiten mal nicht mehr, dafür aber ein PHP-Fehler, der das Skript abbrach.
Selber PHP-Fehler hatte ab da dann auch das composer update blockiert.
Es war ein Fehler im paypalplus-Modul im Zusammenhang mit onDeavtivate.
Modul über die Konsole deaktivieren hatte den selber Fehler geworfen.
→ Dann hatte ich das onDeactivate-Event aus der yaml-Datei chirurgisch entfernt.
→ Ab da haben dann wieder alle Schritte funktioniert.
Zu meiner Überrsachung: Die installation und Konfiguration des neuen PayPal-Checkout-Moduls funktioniert komplett reibungslos.
Danke nochmal für Eure Anteilnahme.
Nachtrag: Das Modul für die Trusted-Shops-Integration ist auch auf ominöse Art und weise verschwunden … aber das ist kein Beinburch. Es schein inkompatibel gewesen zu sein - irgendein Skript hatte hier eine rote Meldung gebracht mit dem Hinweis, dass die MAtadata-Version 1.1 nicht mehr unterstützt wird.
Ich muss leider nochmal eine Frage in den Raum stellen.
Irgendwie habe ich mir irgendwas kaupttgemacht und nun habe ich Verständnisprobleme.
Wenn ich COMPOSER_MEMORY_LIMIT=-1 composer update --no-dev
ausführe, dann geht der Shop kaputt. Weiße Seite im Frontend und Backend.
Vermutlich wird der autoloader gar nicht generiert. Siehe:
Du hast in deinem Shop die Pakete unter “require-dev” bereits installiert. Wenn du jetzt composer update mit dem Parameter “–no-dev” aufrufst, dann werden diese wieder deinstalliert, und das verursacht manchmal Probleme. Wenn du composer install aufrufst, werden die Versionen aus der composer.lock installiert, also quasi der letzte Zustand, und da sind die Pakete wieder dabei. Ich würde den --no-dev Parameter in Zukunft bei composer update einfach erstmal weglassen.
Dann kannst du schauen welche PHP-Version in deinem Frontend aktiv ist (kann man im Backend sehen unter Systeminfo), und welche PHP-Version auf der Kommandozeile aktiv ist (“php -v”). Wenn die Version in der Kommandozeile abweicht, kannst in der composer.json die Version, für die kompiliert wird, explizit setzen: Enforcing a PHP Version for Installed Composer Packages – Andy Carter
Das sollte dann die Version sein die im Frontend verwendet wird.