Neu Konfigurator max. Komponenten

[MaxWe]

Moin,

wir sind grade auf ein Problem mit dem Konfigurator Plugin gestoßen. Wir arbeiten sehr viel mit Variationen (Bsp: 1 Motiv gibt es auf 10 Produkten, im Schnitt gibt es pro Produkt 3 Farben, jede Farbe gibt es in 5 Größen => 1x10x3x5 = 150 Kinderartikel pro Motiv) Im Schnitt sind es tatsächlich sogar um die 275.
Wir wollen nun zbsp ein T-Shirt Bundle anbieten, bei dem man aus ~5 Motiven sich die T-Shirts aussuchen kann. Allein das sind aber schon ca. 5x1x2x7 = 70 Komponenten (MotivexT-ShirtxFarbenxGrößen). Dazu sollten eigentlich noch 2 Gruppen mit Postern / anderem Zeug kommen. Ich sag mal, wir kämen auf 90 Komponenten.

Nun mussten wir heute durch probieren feststellen, dass bei 40 Komponenten schluss ist und ich das Bundle nicht mehr sauber Bestellen kann. Die Bestellung wird erzeugt, aber bei sofortüberweisung als Beispiel, wird man nicht mehr weitergeleitet. Bei Barzahlen wird man zurück zur Bezahlmethode verwiesen und bei Vorkasse erscheint keine Bestellnr. oder sonstiges.

Die Zahlungsarten funktionieren ansonsten Tipp Top und auch mit kleineren Bundles gibt es kein Problem, erst ab dieser Grenze.
Hat hier jemand vielleicht Lösungvorschläge oder machen wir generell etwas falsch? :/ Ist etwas zum verzweifeln^^

Beste Grüße

 

[JulianG]

Hallo @MaxWe

normalerweise besteht bei vielen Konfigurator-Komponenten eher ein Problem, wenn man entsprechend viele gewählt hat und dann den konfigurierten Artikel in den Warenkorb legen will. Geht das normal schnell?
Der Bestellabschluss könnte ggf. auch ein Problem sein, vielleicht ist das Ganze also komplett Zahlungsart-Unabhängig. Bei Vorkasse dürfte es aber kein Problem sein; selbst wenn die Bestellnummer im Browser nicht angezeigt wird, sollte es eine Bestellnummer geben.
Wird ggf. schlicht und ergreifend im Bestellabschluss nach Zahlungspflichtig Bestellen eine weisse Seite angezeigt?

Welche Shop-Version ist im Einsatz und was hat der Shop bei folgenden Werten:
- Maximale PHP Ausführungszeit
- PHP-Speicherlimit

 

[MaxWe]

Moin @JulianG

Das in den Warenkorb legen ist von der Geschwindigkeit her eigentlich ok gewesen. Allgemein war die Bedienung nicht in Lichtgeschwindigkeit, aber in einem vertretbarem Rahmen.
EDIT2: Ich habe nun nochmal getestet. Die Bestellung wird erstellt. Bei Vorkasse wird aber keine Bestellnr. und auch keine Zahlungsart angezeigt.



Shop Version: 4.06.9 (zu diesem Zeitpunkt, nun 4.06.11)
PHP runtime: 180s
PHP-Speicherlimit: 512mb
Maximale Übertragungsgröße Datei/POST: 16mb

EDIT: So sieht bei uns übrigens ein Bundle aktuell aus: https://www.tumilostore.de/Arazhul-Hoodie-Bundle
Und bei den Hoodies sollten geplant eben mehr Variationen angeboten werden.

Beste Grüße

 

[MaxWe]

Ebenfalls wird scheinbar kein Log Eintrag für diese Bestellung erstellt. Er scheint also irgendwo zwischen dem Erstellen der Bestellung und eintragen in die Datenbank und dem Erstellen des Log Eintrages ein Problem zu haben. Die Bestellung ist mittlerweile auch in der Wawi. Ich denke die Zahlungsanbieter werden erst nach dem Log Eintrag behandelt, was deren Abbruch erklären würde?

Oke, der Datenbankeintrag in tBestellung wird erstellt. Log nicht und ggf. in Folge dessen wird auch kein Eintrag in tbestellid erstellt. Da ist irgendwo das Problem

 

[MaxWe]

Das Log ist das Problem. Scheinbar habt ihr dort ein Bug drin. Ich nehme an der Logeintrag wird zu groß bei zu vielen Artikeln o.Ä.
Mit ausgeschaltetem Log läuft es

 

[JulianG]

@MaxWe Du meinst das Systemlog mit welchem Loglevel?

 

[MaxWe]

@JulianG Genau, das Systemlog. Das Loglevel "Hinweis" ist das.

 

[Mathias@tn]

Wir haben mal verschiedene Sets erstellt, die aus mehreren fixen Komponenten plus einer wählbaren Artikelvariante bestanden.
Diese Sets bestanden also jeweils aus einer Stückliste plus einer Auswahl von über 100 Artikelvarianten (inkl. Bild), welche mit dem Konfigurator auswählbar gemacht wurde.

Jede Bestellung, die diese Sets beinhaltete, verabschiedete sich beim Bestellabschluss mit einem weißen Bildschirm. Die Bestellungen kamen zwar in der Wawi an, jedoch wussten die Kunden das nicht und haben dann halt nochmal bestellt... und nochmal. Ergebnis: nur Ärger.

Nach verschiedenen Support-Tickets war die Lösung, die Artikelauswahl per Konfigurator auf ca. 25 bis 30 Artikel zu beschränken.

Wir werden bald einen Artikel per Konfigurator online bringen, der durch ca. 9 Auswahlmöglichkeiten á 2 bis 3 Optionen auf ca. 1600 verschiedene Varianten kommen müsste. Ich sag dann bescheid, wie es gelaufen ist.
Aber mehr als 25 bis 30 Optionen in einem Dropdown inkl. Bild ist definitiv nicht funktionabel.

 

[MaxWe]

Vor genau diesem Problem standen wir auch.
Wie oben bereits beschrieben liegt das Problem sehr wahrscheinlich bei den Logs (Genauer gesagt bei dem "Hinweis Log"). Bei der Erstellung des Logeintrages für eine Bestellung mit einem zu großem Bundle entsteht ein Fehler, der den Prozess stört. Ich nehme an, dass alle Artikel in einem Bundle irgendwie im Logeintrag behandelt werden und bei zu vielen wird er Eintrag einfach zu groß und es entsteht ein Fehler.

Durch das Deaktivieren der Logs sollte auch euer Problem theoretisch behoben sein. Könnt ihr ja mal testen

Beste Grüße

EDIT: Falls ihr nicht auf das Log verzichten wollt, könntet Ihr versuchen folgendes auszukommentieren, dadurch werden nur Bestellabschlüsse nicht mehr gelogt. In der Datei includes/bestellabschluss_inc.php ~Zeile 305-307 . Natürlich auf eigene Gefahr!

if (Jtllog::doLog(JTLLOG_LEVEL_NOTICE)) {
        Jtllog::writeLog('Bestellung gespeichert: ' . print_r($Bestellung, true), JTLLOG_LEVEL_NOTICE, false, 'kBestellung', $kBestellung);
    }

 

[JulianG]

@MaxWe

Ich habe dafür ein Ticket eröffnet. Das "Hinweis" Loglevel ist standardmäßig gar nicht aktiv, aber bei vielen Konfigurationsgruppen wird in diesem auch extrem viel gesichert. Ich sehe allerdings gar keinen Grund dafür. Das sollte nur für Debugging Zwecke notwendig sein und deswegen sehe ich das als falsches Loglevel an: https://issues.jtl-software.de/issues/SHOP-2950

@Mathias@tn
Wir hatten hier kürzlich einen ähnlichen Fall, da hat sich aber rausgestellt, dass in der Datenbank Indizes deaktiviert waren. Nachdem wir diese manuell wieder aktiviert haben, waren bei dem Kunden auch wieder mehr als 30 kein Problem.

 

[MaxWe]

@MaxWe

Ich habe dafür ein Ticket eröffnet. Das "Hinweis" Loglevel ist standardmäßig gar nicht aktiv, aber bei vielen Konfigurationsgruppen wird in diesem auch extrem viel gesichert. Ich sehe allerdings gar keinen Grund dafür. Das sollte nur für Debugging Zwecke notwendig sein und deswegen sehe ich das als falsches Loglevel an: https://issues.jtl-software.de/issues/SHOP-2950

Perfekt Ich bin da ganz bei dir! Ich war überrascht, dass es so gelogt wird. Allerdings war es vermutlich bequemer für den Entwickler, da dieser so einfach nur das Bestellobjekt loggen musste ;D Allerdings sollte auch im Debug Log das Objekt irgendwie bearbeitet werden oder die mögliche Logeintrag Größe erhöht werden. Ansonsten ensteht ja das gleiche Problem..

 

[Mathias@tn]

@Mathias@tn
Wir hatten hier kürzlich einen ähnlichen Fall, da hat sich aber rausgestellt, dass in der Datenbank Indizes deaktiviert waren. Nachdem wir diese manuell wieder aktiviert haben, waren bei dem Kunden auch wieder mehr als 30 kein Problem.

Interesant. Das behalte ich mal im Hinterkopf, falls nochmal Probleme auftreten sollten. Mittlerweile arbeite ich an einem anderen Shop. Der macht bisher keine Probleme, aber wir fangen auch grade erst mit dem Konfigurator an.