Neu Warenkorb Dropdown Navi: Entfernen Button

[MaxWe]

Moin Moin,

wir sind gerade am Umbauen unseres Warenkorbs. Wir wollen diesen weitesgehend aufs Dropdown Navi beschränken. Hierfür müssen wir einen entfernen Button für jede Pos im Dropdown Navi integrieren. Das integrieren des Buttons ist kein Problem, die Funktionalität dahinter leider schon.

Standardmäßig findet die Übermittlung des Formulars, durch den entfernen Button via POST statt. Hierdurch findet in der relevanten Funktion ein redirect (via Header) statt. Theoretisch suggeriert die genutzt Funktion (applyCartChanges) aus dem CartHelper, dass bei einem GET kein Redirect stattfindet. Nach ersten Tests funktioniert das einfache Umstellen des Submits auf GET aber leider nicht. Die Pos bleibt im Warenkorb und es passiert nichts.

Hat hier jemand bereits so eine Lösung umgesetzt oder einen Tip?

Meine Idee wäre nun die Basisfunktion zu nehmen und in eine eigene Umzusetzen. Hierfür müsste ich allerdings eine eigene URL für den Aufruf der richtigen .php integrieren (im Formular target statt /warenkorb, sowas wie /delwarenkorb). Wo könnte ich die Adresse hinterlegen? Das konnte ich leider so nicht finden.. Der Redirect dann wieder auf die aktuelle Seite stellt ja kein Problem dar.

Grüße

 

[FPrüfer]

Theoretisch suggeriert die genutzt Funktion (applyCartChanges) aus dem CartHelper, dass bei einem GET kein Redirect stattfindet. Nach ersten Tests funktioniert das einfache Umstellen des Submits auf GET aber leider nicht. Die Pos bleibt im Warenkorb und es passiert nichts.

Doch das funktioniert schon! Solche Aufrufe sind jedoch mittels Token gesichert. Wenn du das per GET aufrufen willst, musst du den Parameter token im Request mitschicken. Im Template kannst du den mittels token={$smarty.session.jtl_token} erzeugen.

 

[MaxWe]

Doch das funktioniert schon! Solche Aufrufe sind jedoch mittels Token gesichert. Wenn du das per GET aufrufen willst, musst du den Parameter token im Request mitschicken. Im Template kannst du den mittels token={$smarty.session.jtl_token} erzeugen.

Hmm der Token wurde sicher mitgeschickt. Die URL sieht dann so aus:

/Warenkorb?jtl_token=713998bcded528d484b1b4c11d6667bcebc19c6d5a866b4ca926e5e453f8aaf6&wka=1&anzahl%5B0%5D=1&dropPos=0

Die Seite nach dem Abschicken, sieht wie folgt aus:


In den Smarty Variablen ist auch noch der Warenkorb Inhalt hinterlegt..

Gibt es sonst vielleicht noch etwas zu beachten?

EDIT: Und er redirected auch weiterhin beim GET request

 

[FPrüfer]

Wer lesen kann...

... musst du den Parameter token im Request mitschicken.

Ich rede auch von token und nicht von jtl_token. jtl_token ist der POST-Parameter.

 

[MaxWe]

Wer lesen kann...

Ich rede auch von token und nicht von jtl_token. jtl_token ist der POST-Parameter.

Ach mensch.... ja mit token als key klappt es Ich danke dir vielmals!
Weißt du warum man die keys differenziert?.. Die Value ist gleich, einfach nur ein anderer keyname ....

 

[MaxWe]

Das Entfernen funktioniert nun, allerdings findet immer noch ein redirect auf den Warenkorb statt.
Hast du da vll. auch direkt noch eine Idee? @FPrüfer

Also klar, dass grundsätzlich ein Redirect stattfindet. Es wird ja der Warenkorb aufgerufen. Allerdings könnte die Funktion ja direkt zurück zur letzten Seite leiten. Ich befürchte aber, dass dies standardmäßig nicht unterstützt wird?

 

[MaxWe]

Oke Problem gelöst.. Muss dafür zwar leider die warenkorb.php anfassen, aber nur minimal.

Ersetze

$smarty->display('basket/index.tpl');

durch

if(isset($_GET['noRedirect']) && $_GET['noRedirect'] === 'Y'){
    \header(
        'Location: ' . $_SERVER['HTTP_REFERER'],
        true,
        303
    );
}else{
    $smarty->display('basket/index.tpl');
}

"HTTP_REFERER" zeigt auf die zuletzt aufgerufene URI des Nutzers.

Zusätzlich in der Warenkorb Form noch den neuen hidden input hinzufügen

<input type="hidden" name="noRedirect" value="Y">

 

[FPrüfer]

...Muss dafür zwar leider die warenkorb.php anfassen, aber nur minimal.

Die Core-Dateien zu ändern ist grundsätzlich eine schlechte Idee. Viel besser wäre es doch - auch für die User-Experience - den Get-Call per Ajax abzusetzen und bei Erfolg den angezeigten Warenkorb per DOM-Änderung zu manipulieren. Das würde zumindest alles per Template-Anpassung gehen.
Bei deiner Lösung solltest du jedoch auf alle Fälle entweder den Host aus $_SERVER['HTTP_REFERER'] entfernen und durch den aus dem Define für URL_SHOP ersetzen oder die URL anderweitig validieren, um nicht Referrer-XSS zu ermöglichen.

 

[MaxWe]

Hmm ja da gebe ich dir recht, ich bin da auch kein Fan von.. Für die UE scheint mir da kein großer Unterschied zu sein, höchstens ein Reload weniger. Wir werden es aber deinem Ratschlag entsprechend anpassen, mir gefällt das auch besser Meine aktuelle Lösung ist eher eine quick-and-dirty Lösung.

Quasi

$url = URL_SHOP . parse_url($_SERVER['HTTP_REFERER'], PHP_URL_PATH);