Redirect bei checkout_confirmation nach checkout_payment

[montana]

Hallo alle zusammen,

ich bin wahrscheinlich nicht der einzige der das Gutscheinsystem verflucht. Bis jetzt hat noch keiner der Bugfixes bei mir geholfen und nach 2 Tagen dreh ich langsam durch.

Problem ist folgendes:
Kunde gibt Gutscheincode ein (Gutscheinwert >= dem Bestellwert) und geht zur Kasse. Lieferadresse stimmt, weiter.
Rechnungsadresse stimmt, Zahlungsweise gibts keine, AGB's bestätigen und weiter.
Doch bei checkout_confirmation kommt man immer wieder zurück zu checkout_payment und ich sehe nicht wo der Fehler liegt.

Die 3 Fälle aus der checkout_process welche eine Umleitung produzieren würden treffen nicht zu:

Code: Alles auswählen

if (!isset ($_SESSION['sendto'])) {
   xtc_redirect(xtc_href_link(FILENAME_CHECKOUT_PAYMENT, '', 'SSL'));
}

Code: Alles auswählen

if ((xtc_not_null(MODULE_PAYMENT_INSTALLED)) && (!isset ($_SESSION['payment']))) {
   xtc_redirect(xtc_href_link(FILENAME_CHECKOUT_PAYMENT, '', 'SSL'));
}

Code: Alles auswählen

// redirect to payment service
   if ($tmp)
      $payment_modules->payment_action();

Wo ist da also nun der Fehler? ich verstehs nicht.
Die Bestellsumme liegt bei 0.00€ und beide Artikel habe Attribute. Aber die Patches für Attributfehler funktionieren auch nicht.

/edit
ganz vergessen: xt:Commerce v3.0.4 SP2.1

[montana]

Also ich hab den Fehler jetzt gefunden versteh aber nicht so ganz warum er auftritt und kann ihn deshalb auch nicht beheben

checkout_confirmation.php Zeile 84

Code: Alles auswählen

if (isset ($_SESSION['credit_covers']))
{
   $_SESSION['payment'] = 'no_payment'; // GV Code Start/End ICW added for CREDIT CLASS
}

Hier wird die Bezahlmethode auf 'no_payment" gesetzt, trifft in meinem Fall auch zu weil, Gutscheinwert >= Bestellsumme.
So, $_SESSION['credit_covers'] ist auch vorhanden. Das komische is nur, dass die Abfrage, erst nach einen Refresh der Seite funktioniert und die Bezahlmethode richtig setzt. Aber warum ?

Jetzt hab ich also ein wenig rumprobiert (und auch rum probiert ) und bin darauf gekommen, dass in folgenden Zeilen (ca. ab 105) der Wurm steckt:

Code: Alles auswählen

// GV Code Start
$order_total_modules = new order_total();
$order_total_modules->collect_posts();
$order_total_modules->pre_confirmation_check();
// GV Code End

Vor $order_total_modules->pre_confirmation_check(); geht die Abfrage nicht beim ersten Mal sondern erst nach einem Refresh, direkt dahinter geht sie. Das heißt also, $order_total_modules->pre_confirmation_check(); muss mindestens einmal ausgeführt werden und setzt dann wohl die Session Variable.
Kurz in der order_total.php die Funktion pre_confirmation_check() angeschaut und die Vermutung wurde bestätigt.
Nur was zum Geier soll jetzt die Abfrage eins höher die niemals wahr werden kann ausser bei einem Refresh und wie löse ich jetzt das Problem ? ich kann ja nicht einfach die Abfrage verschieben, da sind sicher Abhängigkeiten...

[montana]

Mein Beitrag hier drüber is bisschen komisch. Bin beim Schreiben auf die Idee mit mit dem pre_confirmation_check() gekommen.

Lange Rede kurze Sinn, da sich hier keiner äußern will/kann hab ich den Fehler nach eigenem bemessen selbst gefixt.

checkout_payment.php Zeile:164

Code: Alles auswählen

} else {
   $smarty->assign('GV_COVER', 'true');
   $_SESSION['credit_covers'] = true;
}