Neu Bug: Uncaught TypeError: JTL\Catalog\Currency::setURL():

ronzei

Aktives Mitglied
8. Juli 2021
77
4
Shop Version 5.6.1

Code:
PHP Fatal error:  Uncaught TypeError: JTL\Catalog\Currency::setURL(): Argument #1 ($url) must be of type string, null given, called in /usr/www/..../includes/src/Language/LanguageHelper.php on line 1055 and defined in /usr/www/..../includes/src/Catalog/Currency.php:211
Stack trace:
#0 /usr/www/..../includes/src/Language/LanguageHelper.php(1055): JTL\Catalog\Currency->setURL()
#1 /usr/www/..../includes/src/Router/Controller/AbstractController.php(475): JTL\Language\LanguageHelper->generateLanguageAndCurrencyLinks()
#2 /usr/www/..../includes/src/Router/Controller/ProductController.php(416): JTL\Router\Controller\AbstractController->preRender()
#3 /usr/www/..../includes/src/Router/Controller/RootController.php(42): JTL\Router\Controller\ProductController->getResponse()
#4 /usr/www/..../includes/src/Router/Strategy/SmartyStrategy.php(32): JTL\Router\Controller\RootController->getResponse()
#5 /usr/www/..../includes/vendor/league/route/src/Route.php(124): JTL\Router\Strategy\SmartyStrategy->invokeRouteCallable()
#6 /usr/www/..../includes/vendor/league/route/src/Dispatcher.php(59): League\Route\Route->process()
#7 /usr/www/..../includes/src/Router/Middleware/OptinMiddleware.php(38): League\Route\Dispatcher->handle()
#8 /usr/www/..../includes/vendor/league/route/src/Dispatcher.php(59): JTL\Router\Middleware\OptinMiddleware->process()
#9 /usr/www/..../includes/src/Router/Middleware/CurrencyCheckMiddleware.php(30): League\Route\Dispatcher->handle()
#10 /usr/www/..../includes/vendor/league/route/src/Dispatcher.php(59): JTL\Router\Middleware\CurrencyCheckMiddleware->process()
#11 /usr/www/..../includes/src/Router/Middleware/LocaleCheckMiddleware.php(44): League\Route\Dispatcher->handle()
#12 /usr/www/..../includes/vendor/league/route/src/Dispatcher.php(59): JTL\Router\Middleware\LocaleCheckMiddleware->process()
#13 /usr/www/..../includes/src/Router/Middleware/CartcheckMiddleware.php(27): League\Route\Dispatcher->handle()
#14 /usr/www/..../includes/vendor/league/route/src/Dispatcher.php(59): JTL\Router\Middleware\CartcheckMiddleware->process()
#15 /usr/www/..../includes/src/Router/Middleware/WishlistCheckMiddleware.php(30): League\Route\Dispatcher->handle()
#16 /usr/www/..../includes/vendor/league/route/src/Dispatcher.php(59): JTL\Router\Middleware\WishlistCheckMiddleware->process()
#17 /usr/www/..../includes/src/Router/Middleware/SSLRedirectMiddleware.php(45): League\Route\Dispatcher->handle()
#18 /usr/www/..../includes/vendor/league/route/src/Dispatcher.php(59): JTL\Router\Middleware\SSLRedirectMiddleware->process()
#19 /usr/www/..../includes/src/Router/Middleware/MaintenanceModeMiddleware.php(43): League\Route\Dispatcher->handle()
#20 /usr/www/..../includes/vendor/league/route/src/Dispatcher.php(59): JTL\Router\Middleware\MaintenanceModeMiddleware->process()
#21 /usr/www/..../includes/src/Router/Middleware/LocaleRedirectMiddleware.php(37): League\Route\Dispatcher->handle()
#22 /usr/www/..../includes/vendor/league/route/src/Dispatcher.php(59): JTL\Router\Middleware\LocaleRedirectMiddleware->process()
#23 /usr/www/..../includes/vendor/league/route/src/Strategy/ApplicationStrategy.php(37): League\Route\Dispatcher->handle()
#24 /usr/www/..../includes/vendor/league/route/src/Dispatcher.php(59): Psr\Http\Server\MiddlewareInterface@anonymous->process()
#25 /usr/www/..../includes/vendor/league/route/src/Dispatcher.php(53): League\Route\Dispatcher->handle()
#26 /usr/www/..../includes/vendor/league/route/src/Router.php(97): League\Route\Dispatcher->dispatchRequest()
#27 /usr/www/..../includes/src/Router/Router.php(654): League\Route\Router->dispatch()
#28 /usr/www/..../includes/src/Shop.php(379): JTL\Router\Router->dispatch()
#29 /usr/www/..../index.php(9): JTL\Shop::dispatch()



Scheint ein Core-Bug in JTL-Shop 5.6.1 zu sein, ausgelöst durch fehlende Validierung in Currency::setURL().
 

NoOne

Sehr aktives Mitglied
16. März 2024
515
173
Das wird vermutlich nicht validiert, weil das eigentlich unmöglich ist. Dass die URL nicht generiert werden kann, kann eigentlich nur passieren, wenn im Cache noch eine Sprache hinterlegt ist, die im Shop nicht mehr aktiv ist. Leer mal den Objekt-Cache.
 

ronzei

Aktives Mitglied
8. Juli 2021
77
4
Danke für's drüberschauen und antworten.

Nur, es wurden keine Sprachen gelöscht.

Das "eigentlich unmöglich" hat sich mit dem Error auf "ist möglich" erhöht ;)
setURLFull(string $url) wenig später ebenfalls im Error- Log

Mag durch eine fehlende Übersetzung oder was auch immer kommen, aber
wenn nicht sichergestellt ist, dass null daher kommen könnte, sollte eben validiert werden.
 

NoOne

Sehr aktives Mitglied
16. März 2024
515
173
Da bin ich anderer Meinung. Wenn keine URL generiert werden kann (in diesem Fall: $url = $AktuellerArtikel->getURL($currentLangID), ergo die URL der aktuellen Sprache), dann ist ein Fatal korrekt. Weil das nicht recoverable ist. Keine URL = Artikel nicht aufrufbar. Wenn das kein Cache-Problem ist, dann ist das ein Fehler in den Daten oder der Datenbank. Dass die URL für einen Artikel nicht existiert, ist eben eine Unmöglichkeit. Cache, Datenbank-Manipulation, unvollständiges Backup wiederhergestellt oder ziemlich falsch gelaufener Abgleich. In 3 von den 4 Fällen, möchtest du vermutlich nicht, dass dort was anderes angezeigt wird als ein Fehler.

Eigentlich unmöglich = Darf nicht passieren -> Kann in nichts anderem als in einem Fatal enden.
 

ronzei

Aktives Mitglied
8. Juli 2021
77
4
Catalog/Currency.php

Alle Plugins deaktiviert
Cache alles geleert

Code:
// CUSTOM DEBUG 8.1.2026
    public function setURL(?string $url): self
    {
       if ( !$url) error_log("❌ FEHLER Currency::setURL(NULL) ". $_SERVER['REQUEST_URI']);
       $this->cURL = $url ?? '';
       //$this->cURL = $url;

        return $this;
    }

// CUSTOM DEBUG 8.1.2026
    public function setURLFull(?string $url): self
    {
       if ( !$url) error_log("❌ FEHLER Currency::setURLFull(NULL) ". $_SERVER['REQUEST_URI']);
        //$this->cURLFull = $url;
       $this->cURLFull = $url ?? '';

        return $this;
    }

[10-Jan-2026 19:57:11 Europe/Berlin] ❌ FEHLER Currency::setURL(NULL) /?a=190893&lang=eng&curr=CHF?curr=CHF
[10-Jan-2026 19:57:11 Europe/Berlin] ❌ FEHLER Currency::setURLFull(NULL) /?a=190893&lang=eng&curr=CHF?curr=CHF
[10-Jan-2026 19:57:11 Europe/Berlin] ❌ FEHLER Currency::setURL(NULL) /?a=190893&lang=eng&curr=CHF?curr=CHF
[10-Jan-2026 19:57:11 Europe/Berlin] ❌ FEHLER Currency::setURLFull(NULL) /?a=190893&lang=eng&curr=CHF?curr=CHF
[10-Jan-2026 19:57:11 Europe/Berlin] ❌ FEHLER Currency::setURL(NULL) /?a=190893&lang=eng&curr=CHF?curr=CHF
[10-Jan-2026 19:57:11 Europe/Berlin] ❌ FEHLER Currency::setURLFull(NULL) /?a=190893&lang=eng&curr=CHF?curr=CHF
[10-Jan-2026 19:57:11 Europe/Berlin] ❌ FEHLER Currency::setURL(NULL) /?a=190893&lang=eng&curr=CHF?curr=CHF
[10-Jan-2026 19:57:11 Europe/Berlin] ❌ FEHLER Currency::setURLFull(NULL) /?a=190893&lang=eng&curr=CHF?curr=CHF
[10-Jan-2026 19:57:11 Europe/Berlin] ❌ FEHLER Currency::setURL(NULL) /?a=190893&lang=eng&curr=CHF?curr=CHF
[10-Jan-2026 19:57:11 Europe/Berlin] ❌ FEHLER Currency::setURLFull(NULL) /?a=190893&lang=eng&curr=CHF?curr=CHF
[10-Jan-2026 19:57:11 Europe/Berlin] ❌ FEHLER Currency::setURL(NULL) /?a=190893&lang=eng&curr=CHF?curr=CHF
[10-Jan-2026 19:57:11 Europe/Berlin] ❌ FEHLER Currency::setURLFull(NULL) /?a=190893&lang=eng&curr=CHF?curr=CHF


Keine Ahnung woher die doofe Anfrage herkommt.

Fakt ist, dass mit
setURL(?string $url)
und
$this->cURLFull = $url ?? ''; bzw. $this->cURL = $url ?? '';
den Fehler abfangen kann.
Der Shop läuft dann normal weiter, es wird die Sprache umstellt, CHF auswählt und der Artikel anzeigt.

Das ist mir eigentlich lieber als ein Fatal error.
Die Logik von NoOne kann ich nicht nachvollziehen, denn da könnte man genauso gut einen Fatal erzeugen statt 404 anzuzeigen...

Dass das Ganze jeweils 6x aufgerufen wird ist wieder eine andere Sache....
 

css-umsetzung

Offizieller Servicepartner
SPBanner
6. Juli 2011
8.075
2.309
Berlin
Firma
css-umsetzung
Es macht keinen Sinn, das Problem zu umgehen, man sollte es eher finden

Der Aufruf selbst ist ja schon fehlerhaft wenn ich davon ausgehe das du es wirklich so versucht hast
/?a=190893&lang=eng&curr=CHF?curr=CHF
 

NoOne

Sehr aktives Mitglied
16. März 2024
515
173
Ein 404 ist einfach etwas, das nicht gefunden wird, kein Fehler, ob fatal oder nicht, aus ungültigen Daten und ggf. Datenbankinkonsistenzen. Ansonsten könnte man nämlich auch einfach einen fehlenden Preis ignorieren und den Artikel gratis oder zu einem Fallback-Preis von 1 € anbieten. Ich bin mir sicher, das wär dir vermutlich nicht recht.

Dass ?a=kArtikel in diesem Fall verwendet wird, deutet schon darauf hin, dass die Artikel-URLs fehlen. Sicher kannst du das ignorieren, bis du es nicht mehr ignorieren kannst, weil irgendwas nicht funktioniert. Z. B. der Link von Suchmaschine auf Shop, weil /ArtikelMitEnglischemNamen in einen 404 läuft, weil kein Eintrag in tSeo dafür vorhanden ist. Oder wenn du im Ranking abgestraft wirst, weil URLs mit nichtssagenden Artikel-IDs bei Google landen. Zudem werden hier auch noch URLs generiert, die praktisch ungültig sind und je nach strenge der Serverkonfiguration in einen 400 Bad Request laufen können oder unerwartetes Verhalten zeigen könnten.

Etwas, das auf eine problematische Konfiguration oder eben auf fehlende Daten oder eine Datenbankinkonsistenz hindeutet, darf man nicht einfach übergehen und weiter machen als wär nichts passiert. Dass das hier klappt, ist reines Glück. Im Zweifel wird das über den HOOK_TOOLSGLOBAL_INC_SETZESPRACHEUNDWAEHRUNG_WAEHRUNG an Plugins weitergegeben und sorgt da für Chaos.

Also: Nachgucken, ob ein Eintrag in tseo für cKey='kArtikel' und kKey=190893 existiert. Spezifisch für kSprache von englisch, standardmäßig 2.

Und wenn nicht: Artikel für den Shop deaktivieren, abgleichen, Artikel wieder aktivieren, abgleichen und dann nochmal prüfen, ob der Eintrag existiert. Und prüfen, ob Abgleiche fehlschlagen.
 

ronzei

Aktives Mitglied
8. Juli 2021
77
4
Dass ?a=kArtikel in diesem Fall verwendet wird, deutet schon darauf hin, dass die Artikel-URLs fehlen. Sicher kannst du das ignorieren, bis du es nicht mehr ignorieren kannst, weil irgendwas nicht funktioniert. Z. B. der Link von Suchmaschine auf Shop, weil /ArtikelMitEnglischemNamen in einen 404 läuft, weil kein Eintrag in tSeo dafür vorhanden ist. Oder wenn du im Ranking abgestraft wirst, weil URLs mit nichtssagenden Artikel-IDs bei Google landen. Zudem werden hier auch noch URLs generiert, die praktisch ungültig sind und je nach strenge der Serverkonfiguration in einen 400 Bad Request laufen können oder unerwartetes Verhalten zeigen könnten.
Ich habe mir das genauer angeschaut: Der Fatal Error entsteht, wenn Bots URLs mit ?a=…&lang=… anfragen.
Solche Anfragen scheinen durchaus üblich zu sein.
Die cSeo eines Artikels kann sich über die Zeit durchaus ändern, kArtikel bleibt so lange es den Artikel im Shop gibt.
Daher sind a=nnnn Anfragen aus der Sicht von Bots gar nicht so blöd.

Anscheinend hat JTL hier nicht vorgesorgt, denn zum Zeitpunkt der ersten getURL Anfrage scheint es noch keine Logik für die Currency zu geben => NULL => Fatal error da strikt string in der function verlangt.

Anscheinend ein Edge Case bei Bots, der bei üblichen Anfragen über den Browser mit SESSION usw. sehr wahrscheinlich nicht vorkommen kann.

Meine Lösung ($this->cURLFull = $url ?? '''; verhindert den Fatal Error, Shop läuft weiter.

Der übersetzte Artikel wird in der angefragten Sprache zurückgegeben.
Die Currency - wenn nicht ohnehin die Standardwährung des Shops - wird halt ignoriert.

Ich meine, dass das gscheiter ist den Artikel zurückzugeben als ein Fatal Error und dadurch möglicherweise Ranking zu verlieren.

Wobei das $this->cURLFull = $url ?? ''; eher nur ein kurzfristiger pragmatischer Ansatz ist.

Es macht keinen Sinn, das Problem zu umgehen, man sollte es eher finden
Genau. Finde ich auch.
 

css-umsetzung

Offizieller Servicepartner
SPBanner
6. Juli 2011
8.075
2.309
Berlin
Firma
css-umsetzung
Die cSeo eines Artikels kann sich über die Zeit durchaus ändern, kArtikel bleibt so lange es den Artikel im Shop gibt.
Daher sind a=nnnn Anfragen aus der Sicht von Bots gar nicht so blöd.
Doch sind sie, denn der Shop kann damit umgehen wenn sich die URL ändert.
Es gibt keinen Grund mit der kArtikel Variante zu arbeiten.

Ich habe deine Variante in meinem Shop getestet, auch wenn die URL so kompl. falsch ist.
Keiner meiner Shops verursacht hier Probleme.
 

css-umsetzung

Offizieller Servicepartner
SPBanner
6. Juli 2011
8.075
2.309
Berlin
Firma
css-umsetzung
  • Gefällt mir
Reaktionen: ronzei