Ich kann gut hier zustimmen. Bereits über 10 Emails geschrieben an die Firma, es gibt immer eine Antwort, aber keine Lösung. Mal Gemini und Claude über den Plugin Inhalt laufen lassen und beide haben die Gründe für die Fehler gefunden. Seltsam.
Code:
Pluginjtl_stripe_pluginServicesStripeService::authenticated {
error: Could not connect to Stripe (https://api.stripe.com/v1/webhook_endpoints). Please check your internet connection and try again. If this problem persists, you should check Stripes service status at https://twitter.com/stripestatus, or let us know at support@stripe.com.nn(Network error [errno 6]: Could not resolve host: api.stripe.com)
}
Pluginjtl_stripe_pluginControllersIOController::ioRequest {
error: Syntax error
}
###################
✦ In JTL-Shop 5 wird HOOK_IO_HANDLE_REQUEST bei jeder IO-Anfrage ausgelöst. Der IOController dieses Plugins versucht, jede dieser Anfragen als JSON zu dekodieren. Wenn eine andere Komponente des Shops oder ein externer Aufruf (z. B. ein
Bot) ungültiges JSON an io.php sendet, fängt dieses Plugin die Exception ab und loggt sie als eigenen Fehler. Das ist ein Designfehler des Plugins, da es zu global agiert.
Der Verbindungsfehler in StripeService::authenticated tritt auf, wenn der Server api.stripe.com nicht auflösen kann (DNS-Problem). Diese Methode wird an mehreren Stellen in der Bootstrap.php aufgerufen. Ich werde mir nun die
Bootstrap.php genauer ansehen.
✓ ReadFile Bootstrap.php
✦ Die Analyse der Log-Fehler hat folgende Ursachen ergeben:
1. Fehler: IOController::ioRequest { error: Syntax error }
* Ursache: Dieser Fehler tritt auf, weil das Plugin auf den globalen Hook HOOK_IO_HANDLE_REQUEST reagiert. Dieser Hook wird bei jeder IO-Anfrage im JTL-Shop ausgelöst (nicht nur für Stripe-relevante).
* Technischer Hintergrund: Das Plugin versucht im IOController, den Inhalt jeder Anfrage mittels json_decode zu verarbeiten. Wenn eine Anfrage (z. B. von einem Bot, einem anderen Plugin oder einer fehlerhaften Browser-Anfrage) kein
gültiges JSON enthält, wirft PHP einen Fehler. Das Stripe-Plugin fängt diesen ab und schreibt ihn in sein eigenes Log-File.
* Fazit: Dies ist oft "Hintergrundrauschen". Das Plugin loggt hier Fehler, die eventuell gar nichts mit Stripe zu tun haben, sondern durch ungültige Aufrufe an den Shop verursacht werden.
2. Fehler: StripeService::authenticated { error: Could not connect to Stripe ... Could not resolve host: api.stripe.com }
In der Datei Services/StripeService.php ist die Prüfung so programmiert:
1 public function authenticated(): bool
2 {
3 if (isset($_SESSION['isStripeCredentialsValid'])) {
4 return $_SESSION['isStripeCredentialsValid'];
5 }
6
7 try {
8 (new WebhookEndpoint())->all(); // Hier wird Stripe kontaktiert
9 } catch (\Exception $e) {
10 $this->error(__METHOD__, ['error' => $e->getMessage()]); // Fehler wird geloggt
11 return false; // Es wird false zurückgegeben, ABER NICHTS in der Session gespeichert
12 }
13
14 $_SESSION['isStripeCredentialsValid'] = true; // Nur bei Erfolg wird es gespeichert
15 return true;
16 }
Das Problem:
Wenn die Verbindung fehlschlägt, wird der Fehler geloggt und false zurückgegeben. Da das Plugin den Fehlerzustand aber nicht in der Session speichert (kein "Negativ-Caching"), versucht es bei jedem einzelnen Seitenaufruf erneut, Stripe
zu erreichen.
3. Woher kommen die Aufrufe?
Das Plugin ruft diese Prüfung in der Bootstrap.php bei fast jeder Interaktion auf:
* Artikel-Detailseiten: Jedes Mal, wenn ein Kunde (oder ein Suchmaschinen-Bot) eine Produktseite aufruft.
* Warenkorb: Bei jedem Aufruf des Warenkorbs.
* Bestellvorgang: Bei jedem Schritt im Checkout.
Wenn also 500 Mal eine Seite aufgerufen wird, während das DNS-Problem besteht, erzeugt das Plugin 500 Log-Einträge. Da auch Bots (Google etc.) ständig Seiten aufrufen, kommen diese hohen Zahlen schnell zustande.
####################