Neu 5.5.0 wenn nur eine Versandart existiert, kein Checkout möglich...

elcheffe

Sehr aktives Mitglied
7. Juli 2010
610
82
... da die Zahlungsarten nicht angezeigt/geladen werden.

Bei zwei Versandarten muss man Eine aktiv auswählen. Dann werden auch die Zahlungsarten eingeblendet.


Und ohne Zahlungsart geht es natürlich auch im Checkout nicht weiter.
Workaround: zweite Versandart als Dummy anlegen.


Könnt ja mal checken ob ihr das reproduzieren könnt (Nova Template).
 
  • Gefällt mir
Reaktionen: sah

NoOne

Sehr aktives Mitglied
16. März 2024
583
194
HolyMoly... Ich hab schon herumgerätselt, was da passiert. Danke für den Tipp mit nur einer qualifizierten Versandart...

Fix dafür (funktioniert zumindest bei mir):
In der /includes/src/Router/Controller/CheckoutController.php die Funktion getActiveShippingMethod hiermit ersetzen:

PHP:
public function getActiveShippingMethod(array $shippingMethods): int
    {
        if (isset($_SESSION['Versandart'])) {
            $_SESSION['AktiveVersandart'] = (int)$_SESSION['Versandart']->kVersandart;
        } elseif (!empty($_SESSION['AktiveVersandart']) && GeneralObject::hasCount($shippingMethods)) {
        $active  = (int)$_SESSION['AktiveVersandart'];
            $reduced = \array_reduce($shippingMethods, static function ($carry, $item) use ($active) {
                return (int)$item->kVersandart === $active ? (int)$item->kVersandart : $carry;
            }, 0);
            if ($reduced !== (int)$_SESSION['AktiveVersandart']) {
                $_SESSION['AktiveVersandart'] = $this->getShippingService()->getFirstShippingMethod(
                    \array_map(
                        static function (stdClass $shippingMethod): ShippingDTO {
                            return ShippingDTO::fromLegacyObject($shippingMethod);
                        },
                        $shippingMethods
                    ),
                    $this->customerGroupID,
                    (int)($_SESSION['Zahlungsart']->kZahlungsart ?? '0'),
                )->kVersandart ?? 0;
            }
        } else {
            $_SESSION['AktiveVersandart'] = $this->getShippingService()->getFirstShippingMethod(
                \array_map(
                    static function (stdClass $shippingMethod): ShippingDTO {
                        return ShippingDTO::fromLegacyObject($shippingMethod);
                    },
                    $shippingMethods
                ),
                $this->customerGroupID,
                $_SESSION['Zahlungsart']->kZahlungsart ?? 0,
            )->kVersandart ?? 0;
        }
        
        return (int)$_SESSION['AktiveVersandart'];
    }

Hier ist genau markiert, was mit dem obigen Code ersetzt werden muss: https://gitlab.com/jtl-software/jtl...CheckoutController.php?ref_type=tags#L767-802

Technischere Erklärung:
Das ist die gleiche Funktion, aber vertauscht bei der Übergabe an getFirstShippingMehtod die Reihenfolge der Parameter. Ursprünglich wurde die Zahlungsart vor der Kundengruppe übergeben und das ist exakt falsch herum.

Ich hab das auch mit mehreren qualifizierten Versandarten getestet, das funktioniert nach der Änderung ebenfalls noch.
 
  • Gefällt mir
  • Ich liebe es
Reaktionen: sah und noEE

christian1701

Sehr aktives Mitglied
19. Juli 2007
2.939
121
Wien
Was heisst in dem Fall Gelöst und Zielversion Shop 5.5.1
Geben tuts die ja noch nicht, oder?
Ich möcht da nicht selbst herumändern wenn der Bugfix morgen vielleicht kommt.
 
Zuletzt bearbeitet:

taylor-wheels

Aktives Mitglied
25. März 2024
7
1
Mal ehrlich aus meiner Sicht - einfach absolut geschäftsschädigend. Man macht nach Updates natürlich Testbestellungen, um zu sehen, ob alles noch funktioniert. Aber für einige Läder oder Kundengruppen gibt es nur ein Versandart. Für derartige Fehler sollte ein sofortiges Update nachgeschoben werden. Der ganze Spaß mit der Fehlersuche kostet mich locker über 500 Euro. Zahlt das JTL für mich?

Für mich ist der Fall auch erst gelöst, wenn der Bugfix verfügbar ist!

Sorry JTL: Das ist dilettantisch!!! :mad::mad::mad:
 
  • Gefällt mir
Reaktionen: sah

NoOne

Sehr aktives Mitglied
16. März 2024
583
194
"Sofort" ein Bugfix ist unrealistisch. Auch Bugfixes müssen vorher durch eine QA. Den Hotfix da oben konnte ich jetzt auch nur bei mir testen, aber da es ein relativ einfacher Fehler ist, einfach nur Parameter vertauscht, ist unwahrscheinlich, dass der Bugfix schlussendlich großartig anders aussieht.

QA findet halt immer unter Laborbedingungen statt. Es ist nahezu unmöglich, dass dabei jeder Fehler auffällt. Die Erwartung ist da auch einfach unrealistisch. Der Fehler tritt z. B. auch ungepatcht nicht bei mir auf, wenn für die Standardkundengruppe die Zahlungsarten geholt werden sollen. Dann sind beide Parameter = 1. Und wenn beide Parameter gleich sind, ist egal, in welcher Reihenfolge sie übergeben werden.
 

sfeider

Aktives Mitglied
12. Dezember 2011
2
0
Ich docke mich mal an die Fehlermeldung an.
Vielen Dank für den Bugfix! Ich rätsel nun seit 2 Stunden, was ich falsch eingestellt habe und wollte nun gerade ein Ticket erstellen.
 

JuMert

Aktives Mitglied
9. Februar 2023
40
5
HolyMoly... Ich hab schon herumgerätselt, was da passiert. Danke für den Tipp mit nur einer qualifizierten Versandart...

Fix dafür (funktioniert zumindest bei mir):
In der /includes/src/Router/Controller/CheckoutController.php die Funktion getActiveShippingMethod hiermit ersetzen:

PHP:
public function getActiveShippingMethod(array $shippingMethods): int
    {
        if (isset($_SESSION['Versandart'])) {
            $_SESSION['AktiveVersandart'] = (int)$_SESSION['Versandart']->kVersandart;
        } elseif (!empty($_SESSION['AktiveVersandart']) && GeneralObject::hasCount($shippingMethods)) {
        $active  = (int)$_SESSION['AktiveVersandart'];
            $reduced = \array_reduce($shippingMethods, static function ($carry, $item) use ($active) {
                return (int)$item->kVersandart === $active ? (int)$item->kVersandart : $carry;
            }, 0);
            if ($reduced !== (int)$_SESSION['AktiveVersandart']) {
                $_SESSION['AktiveVersandart'] = $this->getShippingService()->getFirstShippingMethod(
                    \array_map(
                        static function (stdClass $shippingMethod): ShippingDTO {
                            return ShippingDTO::fromLegacyObject($shippingMethod);
                        },
                        $shippingMethods
                    ),
                    $this->customerGroupID,
                    (int)($_SESSION['Zahlungsart']->kZahlungsart ?? '0'),
                )->kVersandart ?? 0;
            }
        } else {
            $_SESSION['AktiveVersandart'] = $this->getShippingService()->getFirstShippingMethod(
                \array_map(
                    static function (stdClass $shippingMethod): ShippingDTO {
                        return ShippingDTO::fromLegacyObject($shippingMethod);
                    },
                    $shippingMethods
                ),
                $this->customerGroupID,
                $_SESSION['Zahlungsart']->kZahlungsart ?? 0,
            )->kVersandart ?? 0;
        }
       
        return (int)$_SESSION['AktiveVersandart'];
    }

Hier ist genau markiert, was mit dem obigen Code ersetzt werden muss: https://gitlab.com/jtl-software/jtl...CheckoutController.php?ref_type=tags#L767-802

Technischere Erklärung:
Das ist die gleiche Funktion, aber vertauscht bei der Übergabe an getFirstShippingMehtod die Reihenfolge der Parameter. Ursprünglich wurde die Zahlungsart vor der Kundengruppe übergeben und das ist exakt falsch herum.

Ich hab das auch mit mehreren qualifizierten Versandarten getestet, das funktioniert nach der Änderung ebenfalls noch.
Eine Frage, kann ich den Code einfach 1:1 in der Datei ersetzen?
 

sah

Sehr aktives Mitglied
11. Juni 2021
445
45
Herten
Hier als diff
Diff:
--- CheckoutController.php.bak  2025-05-19 15:43:15.000000000 +0200
+++ CheckoutController.php      2025-06-10 11:36:14.358022274 +0200
@@ -781,8 +781,8 @@
                         },
                         $shippingMethods
                     ),
-                    (int)($_SESSION['Zahlungsart']->kZahlungsart ?? '0'),
                     $this->customerGroupID,
+                    (int)($_SESSION['Zahlungsart']->kZahlungsart ?? '0'),
                 )->kVersandart ?? 0;
             }
         } else {
@@ -793,8 +793,8 @@
                     },
                     $shippingMethods
                 ),
-                $_SESSION['Zahlungsart']->kZahlungsart ?? 0,
                 $this->customerGroupID,
+                $_SESSION['Zahlungsart']->kZahlungsart ?? 0,
             )->kVersandart ?? 0;
         }
 

alex9019

Sehr aktives Mitglied
17. Mai 2018
371
51
Ist das nun wirklich gelöst?

Ich habe heute von einem italienischen Kunden die Rückmeldung erhalten, dass die Zahlungsarten nicht angezeigt werden:

Screenshot 2025-10-16 221020.png

Wie es scheint, nur in der mobilen Version.

Habe es versucht nachzustellen und im Chrome Browser wurden diese nicht angezeigt.
Nach mehrmaligem klicken auf "Ulteriori" kamen sie dann irgendwann.

Im Safari Browser wurden die Zahlungsarten umgehend angezeigt.
 
Ähnliche Themen
Titel Forum Antworten Datum
Neu Artikelbild verknüpfen verknüpft nur alle Bilder, wenn kein Bild 1 da ist JTL-Ameise - Fehler und Bugs 0
Artikel erkennbar machen wenn nur als Dropshippimg zur Verfügung gestellt wird JTL-Wawi 1.10 5
Neu Vorgang wenn Mahngebühren nicht bezahlt wurden? User helfen Usern - Fragen zu JTL-Wawi 3
Neu Benachrichtigung wenn Worker Abgleich fehlschlägt? User helfen Usern - Fragen zu JTL-Wawi 0
Neu Artikel ändern Bilder erst, wenn alle Variationen gewählt wurden Allgemeine Fragen zu JTL-Shop 1
In Diskussion Warnung per Mail wenn Paket seit x Tagen in Filiale zu Abholung (DHL Sendungsverfolgung) Track&Trace JTL-Workflows - Ideen, Lob und Kritik 6
Kein Versenden-Button wenn "Artikel vor dem Verpacken bestätigen" aktiv JTL-Wawi 1.11 2
Rechteverwaltung - Verkaufspreise nur einsehbar, nicht bearbeiten? JTL-Wawi 1.10 1
Neu fEKNetto - zwei Einträge je LiefArtikel mit gleichem Lieferant - nur einer aktualisiert User helfen Usern - Fragen zu JTL-Wawi 1
Neu Epson TSE GetStorageInfo kommt nur Einrichtung / Updates von JTL-POS 0
Eingangsrechnungen mit Einstellung "Nur gelieferte Positionen übernehmen" - Versandkosten werden nicht mit übernommen JTL-Wawi 1.11 4
Geänderte Preise kommen nur teilweise in den Shop JTL-Wawi 1.11 6
Neu Teillieferung nur mit Rechnung über ganzen Auftrag oder ohne Rückstandsmeldung möglich Arbeitsabläufe in JTL-WMS / JTL-Packtisch+ 1
Neu Alte Produktbilder erscheinen im JTL-Shop trotz Löschung und neuem Upload immer wieder – JTL-Wawi enthält nur neue Bilder JTL-Wawi - Fehler und Bugs 16
Neu Fehler beim Abgleich, aber nur 1 einer von 3 Shopify Shops Shopify-Connector 2
Neu Synchronisation funktioniert nur bei manchen Produkten Shopify-Connector 7
Neu Strukturierte Daten vom Typ "Produkt" werden nach Update auf JTL Shop 5.6.1 nur fehlerhaft erkannt JTL-Shop - Fehler und Bugs 3
Artikel Eigene Felder kommen nur beim ersten Shopabgleich in den JTL-Shop JTL-Wawi 1.11 2
Neu JTW WAWI benötigt schnellstmöglich wieder eine funktionierende DATEV Schnittstelle!! JTL-Wawi - Ideen, Lob und Kritik 2
Neu SQL-Server geht eine Stunde nach Allgemeine Fragen zu JTL-Shop 4
Neu Wokflow alle Sendenummer in eine Mail User helfen Usern - Fragen zu JTL-Wawi 2

Ähnliche Themen