isotope-payment-sepa-bundle für Contao 4.9.x (4.13.x ?)

[albis]

Hallo,

versuche dieses SEPA Payment Bundle für Contao 4.9 (bzw. 4.13.x) zum laufen zu bekommen, was auch soweit funktioniert.

Das von Contao verwendete und veraltete "mcrypt" wurde mit "sodium" ersetzt.

Nur bei der Konfiguration der Zahlungseinstellung im isotope werden die Subpalettes von hier nicht angezeigt:

vendor/grusch-it/isotope-payment-sepa-bundle/src/Resources/contao/dca/tl_iso_payment.php

erst wenn ich dieses Datei unter:

contao/dca/tl_iso_payment.php

ablege funktioniert es.

Genauso verhält es sich mit "Notification Center notification types" unter:

vendor/grusch-it/isotope-payment-sepa-bundle/src/Resources/contao/config/config.php

... erst wenn ich diese nach:

contao/config/config.php

kopiere, werden diese korrekt angewendet.

funktioniert die Überschreibung in diesem Fall neuerdings anders? ... bzw. wie muss die "tl_iso_payment.php" und "config.php" modifiziert werden das diese auch innerhalb des Moduls funktionieren?

habe dazu (mein erstes!) Repro aufgemacht:
https://github.com/albirs/isotope-pa...e/contao-4.9.x

bin über jeden Hinweis dankbar!

VG

[Spooky]

Hier fehlt 'isotope' im Array: https://github.com/grusch-it/isotope...Plugin.php#L27

[albis]

Danke Spooky! ... damit funktioniert es!

[a-v-l]

Hallo albis, hallo Spooky (und Michael aka grusch-it),

vielen Dank für euere Arbeit an dem SEPA-Zahlungsmodul! Ich habe das etwas aktualisiert und (fast) erfolgreich im Einsatz. Sobald es komplett fehlerfrei läuft, würde ich das Modul außerdem gerne als Erweiterung auf packagist.org publizieren – falls albis oder grusch-it das nicht machen wollen…

Nun zu meinem sehr merkwürdigen Problem:
In https://github.com/a-v-l/isotope-pay...ayment.php#L53 werden mit $objOrder->payment_data = $_SESSION['SEPA_PAYMENT']->all(false); die payment_data gefüllt, die dann in Zeile 58 mit $objOrder->save(); in die Datenbank geschrieben werden (sollten). Das klappt in der Regel auch wunderbar. Wenn der Warenkorb jedoch ein Download-Produkt ohne Versand* enthält, wird payment_data zwar gefüllt, aber nicht abgespeichert.

Leider ist das ganze ziemlich schlecht zu debuggen, da es beim Checkout mehrere Page-Weiterleitungen gibt, die dann jeweils mit exit(); unterbrochen werden müssen, und da Isotope aktuell noch dermaßen voll mit php8-Fehlern/Warnungen ist, dass der Symfony-Profiler nicht genutzt werden kann.

Ich hänge jetzt schon mehrere Tage an diesem einen Problem :-P also falls mir jemand einen Tipp hat, wäre ich überdankbar!!!

Grüße Arndt

*edit:
Ich habe mal auch für die PDFs (Download-Produkt) den Versand aktiviert: Keine Änderung, die payment_data wird weiterhin nicht gespeichert…

[a-v-l]

Es könnte doch ein Problem von Isotope selbst sein. Mit unzähligen \Symfony\Component\VarDumper\VarDumper::dumps konnte ich in https://github.com/isotope/core/blob...tion.php#L1639 die Methode addItemsToTemplate() ausfindig machen, die bei Aufruf in addToTemplate() (Zeile 1492) mein payment_data verschluckt.

Edit: Never trust your IDE! Die aufgerufene Methode befindet sich nicht der gleichen Datei/Klasse (obwohl es dort eine mit gleichem Namen gibt!), sondern in https://github.com/isotope/core/blob...Order.php#L562! Dort gibt es in Zeile 573 die folgende Zeile:

$arrDownloads = array_merge($arrDownloads, $objDownload->getForTemplate($this->isPaid(), $this->orderdetails_page)); 

Die darin aufgerufene Funktion $objDownload->getForTemplate($this->isPaid(), $this->orderdetails_page) scheint payment_data zu manipulieren. (Wobei $this->isPaid() nicht das Problem ist.

Bleibt Isotope\Model\ProductCollectionDownload::getForTem plate (https://github.com/isotope/core/blob...wnload.php#L81)
Es ist mir allerdings vollkommen schleierhaft, wieso diese Funktion $this->payment_data auf null setzt. Kann mich da jemand erhellen?

[a-v-l]

Es ist mir allerdings vollkommen schleierhaft, wieso diese Funktion $this->payment_data auf null setzt. Kann mich da jemand erhellen?

Ich konnte den Ursprung des Übels darauf eingrenzen, dass in Zeile 99 (https://github.com/isotope/core/blob...wnload.php#L99) die Methode Contao\Model::getRelated zweimal in Kette aufgerufen wurde:

$baseUrl = null;
if ($orderDetailsPageId > 0 && ($orderDetailsPage = PageModel::findByPk($orderDetailsPageId)) !== null) {
     /** @var Order $order */
    $order = $this->getRelated('pid')->getRelated('pid');

    $baseUrl = $orderDetailsPage->getFrontendUrl().'?uid='.$order->uniqid;
} 

Warum das dann dazu führt, dass $this->payment_data überschrieben wird, ist mir zwar immer noch nicht klar, aber bei "einmaligem" Aufrufen gibt es das Problem nicht. So habe ich einfach in Zeile 99 eine andere Methode verwendet, um an die benötigte \Isotope\Model\ProductCollection\Order-Instanz zu kommen:

$order = Order::findByPk($this->getRelated('pid')->pid); 

Zeile 98: /** @var Order $order */ kann man sich auch sparen, da oben in der Datei ja use Isotope\Model\ProductCollection\Order; angegeben ist.

Wie gesagt, ich weiß nicht genau, warum $this->getRelated('pid')->getRelated('pid') zu diesem Problem geführt hat. Die nun verwendete Lösung sollte jedoch keine Nachteile haben.
Schätze, das wird mein erster PR für Isotope!