Ich werde es demnächst testen, da ich an der Stelle Gutscheine bald arbeite.
Was probiert werden könnte ob ab PHP Version 7.2 Fehlermeldung verschwindet, weil die interne PHP Funktion session_write_close() sich mit dieser Version der Rückgabewert geändert hat. Könnte sein, dass das OXID Framework bereits an den neuen Rückgabewert orientiert. Aber ein erster Blick in Code spricht dagegen.
Sollte eigentlich nicht so sein, weil OXID 6.2.2 auf PHP 7.1 getestet wurde: OXID eShop version 6.2.2 • OXIDforge. Falls doch, ist es offenbar ein Bug.
Der Bug wurde noch nicht bearbeitet. Cool, dass es bei Dir so funktioniert!
Aber wenn ich das richtig im Bug verstehe, wäre eigentlich nur die EE betroffen. Lese ich Deine Fehlermeldung, scheint es auch in der CE so zu sein, oder?
Ich würde es anders lösen, weil in Deiner überladenen Klasse Article2ShopRelations steht oben im Kopf ausdrücklich drin, dass die Klasse nicht überladen sollst!
/**
* This class handles multi-shop item relations with shops.
*
* For example: article is available in one or few shops or sub shops.
*
* @internal Do not make a module extension for this class.
* @see http://wiki.oxidforge.org/Tutorials/Core_OXID_eShop_classes:_must_not_be_extended
*/
class Element2ShopRelations
In Deinem Eingangspost sieht man ja die Ablaufverfolgung knallen tut es bei $config->pageClose(); Aufruf in der ShopControll Klasse.
Landen tut man im OxidStartController Klasse bei der Methode pageClose() und von dort springt er in die Session Klasse Methode freeze().
Dort würde ich mir den Rückgabewert von session_write_close(); einmal mitloggen was dort zurück kommt.
Ich würde wahrscheinlich die freeze() Methode überladen und prüfen ob ich das Problem an dieser Stelle fixen kann.
Session-Daten werden normalerweise nach Beenden eines Scripts gespeichert, ohne dass session_write_close() aufgerufen werden muss, aber da Session-Daten gesperrt werden, um gleichzeitiges Schreiben zu verhindern, kann jeweils immer nur ein Script auf eine Session einwirken. Bei der Verwendung von Framesets zusammen mit Sessions werden Sie merken, dass wegen dieser Sperrung ein Frame nach dem anderen geladen wird. Sie können die Zeit zum Laden aller Frames reduzieren, indem Sie die Session beenden, sobald alle Änderungen an den Session-Variablen durchgeführt sind.
Vielleicht wird die Session einfach zulangsam geschlossen, dass dann anschließend und/oder vorab die Datenbank Verbindung knallt. Problem könnte sein, dass ja versucht wird die Warenkorb Session in der Datenbank vorab zu speichern bevor die Session beendet wird.
Immerhin weiß man dadurch nun, dass die gespeicherten Warenkörbe in der Datenbank nicht schuld sein können. Das es sich ausschließlich um den Warenkorb in der Session handelt.
Da steht nun im Raum warum man dafür eine Datenbank Objekt benötigt?
Wahrscheinlich die aufwendigste Prozessdur im Shop die Warenkorbberechnung betroffen die ja bei einem eingelösten Gutschein erneut durchgeführt werden muss. Wo im Hintergrund diverse Datenbankabfragen laufen.
Das Kernproblem könnte sein, dass das Basket Objekt als Referenz an die Session übergeben wird, besser wäre ab PHP 7 mit einem Clone damit man Konflikte vermeiden kann.
