Bei uns scheint jetzt alles sauber zu laufen, Zahlungen gehen durch und keine Meldungen mehr in den Logfiles.
2 „Gefällt mir“
Das kann ich bestätigen.
Das ist nun doch bemerkenswert, da es immerhin 1 Jahr und 7 Tage gedauert hat seit v5. Rechne ich v4 dazu, wo man mit 4.3.3. Express einfach abschalten muss(te), kämen noch ein par Monate hinzu für ein funktionierendes Plugin, wo die einzige Neuerung gegenüber v3 die für Paypal so wichtigen BNPL Erweiterungen vorhanden sind.
Aber immerhin.
Hallo,
es gibt nun ein neues Updata auf Version 6.1.3. Im changelog steht da „PT-13146 - Behebt ein Problem bei der Überprüfung der Transaktionsfähigkeit ohne PPCP“. Was bedeutet das genau ?
Kann da jemand vielleicht helfen.
beste Grüße
K-H
Moin,
das bedeutet, wenn du im PayPalBackendModul auf „Autorisieren“ klickst, haben wir vorher vorausgesetzt, dass die Response immer eine Einstellung für Kauf auf Rechnung und Kreditkarte hat. Es kann aber unter Umständen sein, dass diese nicht in der Response auftauchen. Das wurde gefixt.
Seit einem der letzten Updates haben wir vermehrt folgende Exception:
Unable to load template snippet 'frontend/paypal_unified_v2_pay_upon_invoice/index.tpl|frontend/plugins/seo/index.tpl'
{
"uri": "/PaypalUnifiedV2PayUponInvoice/index/payPalUnifiedCurrentRequestId/b10e9227-998b-4489-b301-e8e6c71c9deb/sComment//puiDateOfBirth/day%1D6%26month%3D5%26year%3D1970/puiTelephoneNumber/XYZ/__csrf_token/ABC",
"method": "GET",
"query": {
"module": "frontend",
"controller": "PaypalUnifiedV2PayUponInvoice",
"action": "index",
"payPalUnifiedCurrentRequestId": "b10e9227-998b-4489-b301-e8e6c71c9deb",
"sComment": [],
"puiDateOfBirth": {
"day": "1",
"month": "1",
"year": "1900"
},
"puiTelephoneNumber": "XYZ7",
"__csrf_token": "ABC"
},
"post": []
}
Was fehlt da?
Hallo @PingPong
hast du die Request Daten abgeändert, oder stehen die wirklich so im Log? Falls ja, dann sieht das eher nach einem automatischen Bot-Request aus, der dann ignoriert werden kann.
Viele Grüße aus Schöppingen
Michael Telgmann
Ist das dein Ernst?
Natürlich habe ich die Daten abgeändert!
Das eigentliche Problem ist das:
Unable to load template snippet 'frontend/paypal_unified_v2_pay_upon_invoice/index.tpl|frontend/plugins/seo/index.tpl'
wenn es nicht mein Ernst wäre, würde ich nicht fragen… Ich hab über die Jahre schon viel gesehen und vermeintlich „dumme“ Fragen, haben schon oft zum Ziel geführt.
Der Fehler, dass das Template nicht geladen werden kann, ist nur das was am Ende aufploppt. Da dieser Controller aber gar kein Template hat und auch keins laden soll, wird die Ursache an einer anderen Stelle liegen.
Gibt es denn davor oder danach noch mehr Log-Einträge, die dazu passen könnten? Kannst du den Fehler reproduzieren?
Du könntest kurzfristig in der config.php das Log-Level anpassen, um noch mehr Infos zu bekommen. Achtung, das wird den Log ziemlich voll hauen:
'logger' => [
'level' => 100,
],
Das ist kein Logeintrag, sondern eine Exception-Mail, die ich als Admin bekomme, wenn eben eine Exception im Shop geworfen wird )in dem Fall von Smarty).
Der Logeintrag (core) dazu mit Level ERROR:
SmartyException: Unable to load template snippet 'frontend/paypal_unified_v2_pay_upon_invoice/index.tpl|frontend/plugins/seo/index.tpl' in /engine/Library/Smarty/sysplugins/smarty_internal_templatebase.php:127 Stack trace:
#0 /engine/Library/Enlight/View/Default.php(286): Smarty_Internal_TemplateBase->fetch()
#1 /engine/Library/Enlight/Controller/Plugins/ViewRenderer/Bootstrap.php(180): Enlight_View_Default->render(Object(Enlight_Template_Default))
#2 /engine/Library/Enlight/Controller/Plugins/ViewRenderer/Bootstrap.php(207): Enlight_Controller_Plugins_ViewRenderer_Bootstrap->renderTemplate(Object(Enlight_Template_Default))
#3 /engine/Library/Enlight/Controller/Plugins/ViewRenderer/Bootstrap.php(124): Enlight_Controller_Plugins_ViewRenderer_Bootstrap->render()
#4 /engine/Library/Enlight/Event/Handler/Default.php(90): Enlight_Controller_Plugins_ViewRenderer_Bootstrap->onPostDispatch(Object(Enlight_Controller_ActionEventArgs))
#5 /engine/Library/Enlight/Event/EventManager.php(207): Enlight_Event_Handler_Default->execute(Object(Enlight_Controller_ActionEventArgs))
#6 /engine/Library/Enlight/Controller/Action.php(230): Enlight_Event_EventManager->notify('Enlight_Control...', Object(Enlight_Controller_ActionEventArgs))
#7 /engine/Library/Enlight/Controller/Dispatcher/Default.php(467): Enlight_Controller_Action->dispatch('indexAction')
#8 /engine/Library/Enlight/Controller/Front.php(226): Enlight_Controller_Dispatcher_Default->dispatch(Object(Enlight_Controller_Request_RequestHttp), Object(Enlight_Controller_Response_ResponseHttp))
#9 /engine/Shopware/Kernel.php(195): Enlight_Controller_Front->dispatch()
#10 /vendor/symfony/http-kernel/HttpCache/SubRequestHandler.php(85): Shopware\Kernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#11 /vendor/symfony/http-kernel/HttpCache/HttpCache.php(479): Symfony\Component\HttpKernel\HttpCache\SubRequestHandler::handle(Object(Shopware\Kernel), Object(Symfony\Component\HttpFoundation\Request), 1, true)
#12 /engine/Shopware/Components/HttpCache/AppCache.php(270): Symfony\Component\HttpKernel\HttpCache\HttpCache->forward(Object(Symfony\Component\HttpFoundation\Request), true, NULL)
#13 /vendor/symfony/http-kernel/HttpCache/HttpCache.php(452): Shopware\Components\HttpCache\AppCache->forward(Object(Symfony\Component\HttpFoundation\Request), true)
#14 /vendor/symfony/http-kernel/HttpCache/HttpCache.php(346): Symfony\Component\HttpKernel\HttpCache\HttpCache->fetch(Object(Symfony\Component\HttpFoundation\Request), true)
#15 /engine/Shopware/Components/HttpCache/AppCache.php(196): Symfony\Component\HttpKernel\HttpCache\HttpCache->lookup(Object(Symfony\Component\HttpFoundation\Request), true)
#16 /vendor/symfony/http-kernel/HttpCache/HttpCache.php(224): Shopware\Components\HttpCache\AppCache->lookup(Object(Symfony\Component\HttpFoundation\Request), true)
#17 /engine/Shopware/Components/HttpCache/AppCache.php(117): Symfony\Component\HttpKernel\HttpCache\HttpCache->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#18 /www/htdocs/abc/xyz.de/shopware.php(122): Shopware\Components\HttpCache\AppCache->handle(Object(Symfony\Component\HttpFoundation\Request))
#19
Der entsprechende CRITICAL-Eintrag dazu:
Unable to load template snippet 'frontend/paypal_unified_v2_pay_upon_invoice/index.tpl|frontend/plugins/seo/index.tpl'
Die zeitlich passenden DEBUGs und NOTICEs aus dem Plugin-Log sehen unauffällig aus.
Die Fehlermeldung sehe ich auch sehr, sehr selten in Shops. So selten, dass ich bei Rechnungskauf schon gar nicht mehr hinterhersuche - irgendwas von 1 unter +100000 Besuchern oder so. Wie oft kommt das denn bei dir und kannst du abgebrochene Warenkörbe/Kunden dazu in der Datenbank finden?
Findest Du im Webserver Error-Log vielleicht so einen 500er Error?
Uncaught TypeError: SwagPaymentPayPalUnified\Components\PayPalOrderParameter\ShopwareOrderData::__construct(): Argument #1 ($shopwareUserData) must be of type array, null given, called in…
Den kannst du dann mit dem Aufruf der URI aus dem Template-Fehler provozieren. Klichst du bei der 500er Fehlermeldung auf den „Aktualisieren“ Button im Browser, wird der Smarty-Fehler ausgelöst.
Ob das jetzt von Bots generierte Aufrufe sind, oder irgendetwas mit abgebrochenen alten Bestellungen zu tun hat, weiß ich nicht.
Ich denke auch, dass der Template-Fehler ein Folgefehler ist.
Wie häufig das vorkommt, weis ich nicht. Mir fällt das eben in letzter Zeit auf, weil ich die Mails entsprechend vom Shop bekomme.
Abgebrochene Warenkörbe usw. gibt es dazu nicht, soweit ich das erkennen kann.
error-Log müsste ich nachgucken.
Wenn es den 500er tatsächlich so gibt, sollte sich @Michael_Telgmann mal damit auseinander setzen - dann ist das schlicht ein Programmierfehler bzw. eine nicht behandelte Fehlerquelle 
Der Controller macht intern irgendwelche redirects, lädt also richtigerweise kein eigenes Template. Fliegt aber vorher irgendwo was weg, weil eben keine adäquate Fehlerbehandlung implementiert ist, greift die normale Templatelogik → lade Template nach Namenskonvention.
Hallo @PingPong
ich hatte ja bereits nachgefragt, ob sich der Fehler reproduzieren lässt. Falls du da einen Weg kennst, werden wir uns das auf jeden Fall anschauen. Ansonsten kann ich leider nur sagen: „Works on my machine“ 
Viele Grüße aus Schöppingen
Michael Telgmann
Ja, der Fehler lässt sich reproduzieren - durch die Benutzung des Shops. Sonst hätten nicht mindestens zwei Nutzer das Problem!
Ich als Entwickler würde jetzt erstmal dem 500er auf die Spur gehen. Ganz offensichtlich wird dort im Code eine Ausnahme nicht behandelt bzw. der aufrufende Code behandelt die Ausnahme nicht.
/**
* @param array<string, mixed> $shopwareUserData
* @param array<string, mixed> $shopwareBasketData
*
* @phpstan-param CheckoutBasketArray $shopwareBasketData
*/
public function __construct(array $shopwareUserData, array $shopwareBasketData)
{
$this->shopwareUserData = $shopwareUserData;
$this->shopwareBasketData = $shopwareBasketData;
}
Eventuell löst das das Problem schon?
Durch die Benutzung deines Shops 
Wenn du die Ursache des Problems schon identifiziert hast, kannst du gerne eine Fix auf GitHub bereitstellen: GitHub - shopware5/SwagPaymentPayPalUnified: PayPal products unified in one plugin
Wir freuen uns über jeden Beitrag 
1 „Gefällt mir“