Widget.php ohne Parameter & Searchbots

Guten Tag,

in den Exception-Logs finde ich ab und zu den Hinweis:

OxidEsales\\Eshop\\Application\\Controller\\StartController is not an instance of OxidEsales\\Eshop\\Application\\Component\\Widget\\WidgetController at /www/htdocs/w017fa71/oxid6.ifabrik-digital.de/vendor/oxid-esales/oxideshop-ce/source/Core/UtilsObject.php:231) [stacktrace]
#0 /aaa/source/oxfunctions.php(101): OxidEsales\\EshopCommunity\\Core\\UtilsObject->oxNew('OxidEsales\\\\Esho...', 'OxidEsales\\\\Esho...') 
#1 /aaa/vendor/oxid-esales/oxideshop-ce/source/Core/WidgetControl.php(130): oxNew('OxidEsales\\\\Esho...', 'OxidEsales\\\\Esho...') 
#2 /aaa/vendor/oxid-esales/oxideshop-ce/source/Core/ShopControl.php(272): OxidEsales\\EshopCommunity\\Core\\WidgetControl->_initializeViewObject('OxidEsales\\\\Esho...', NULL, NULL, NULL) 
#3 /aaa/vendor/oxid-esales/oxideshop-ce/source/Core/ShopControl.php(137): OxidEsales\\EshopCommunity\\Core\\ShopControl->_process('OxidEsales\\\\Esho...', NULL, NULL, NULL) 
#4 /aaa/vendor/oxid-esales/oxideshop-ce/source/Core/WidgetControl.php(62): OxidEsales\\EshopCommunity\\Core\\ShopControl->start('start', NULL, NULL, NULL) 
#5 /aaa/vendor/oxid-esales/oxideshop-ce/source/Core/Oxid.php(41): OxidEsales\\EshopCommunity\\Core\\WidgetControl->start() 
#6 /aaa/source/widget.php(10): OxidEsales\\EshopCommunity\\Core\\Oxid::runWidget() 
#7 {main} "] []

Prinzipiell ist die Exception auch richtig. Denn der Start-Controller ist ja auch kein Widget sondern eine Frontend-Controller.

In den Apache-Logs habe ich gesehen, das ein Search-Bot die Ursache dafür ist, denn der ruft die widget.php ohne weitere Parameter auf: https://www.meinedomain.de/widget.php. Aufgrund der fehlenden Angabe eines Controllers fällt OXID dann auf den Start-Controller zurück und wirft dann die Exception.

Wie der Bot auf die Idee gekommen ist, das ist eine andere Frage, aber ich würde das gern in Zukunft verhindern. Weiß jemand, ob ich die widget.php problemlos in die robots.txt aufnehmen kann?

ob sich der bot an die robots.txt hält ist fraglich …
besser ist es zB in der widget.php vor dem Laden der bootstrap.php eine Zeile einzufügen:
if (count($_REQUEST) == 0) die();

@patchwork.de

Danke für die Antwort, aber die Lösung ist nicht korrekt.

  1. Eine Core-Datei so anzupassen ist prinzipiell der falsche Weg
  2. Das die() im Quellcode hat für den Bot den selben Effekt wie schon jetzt, wenn Du Deinen Shop so aufrufst: https://www.deinshop.de/widget.php. Er bekommt eine weiße Seite mit Apache-Status 200. Das bedeutet für Ihn, hier bekomme ich zwar jetzt nichts zu sehen, aber hier kann ich noch einmal vorbei kommen. (genau das macht er auch bei uns genau einmal die Woche zur gleichen Zeit).
    Das einzige, was ich durch das die() erreiche ist, das ich den Fehler nicht mehr im Exception-Log sehe. Und daher kommt die Lösung nicht in Frage.

Ich habe jetzt die widget.php mit in die robots.txt mit aufgenommen. Im Shop gibt es bis jetzt keine Auffälligkeiten, dass das irgendeinen Einfluss auf das Kundenverhalten hat. Ich bin jetzt gespannt, ob es den Bot abhält.

Dennoch bin ich mit der Lösung noch nicht 100% zufrieden. Es müsste für die widget.php genau wie für die index.php einen redirect-Fallback geben. Rufe ich die index.php mit einem Fantasie-Controller auf, wird eine Exception geworfen und ich werde mit einer 302 auf die Startseite geleitet.

Für meinen Geschmack ist die 302 auch noch nicht der richtige Status-Code. Denn der sagt ja die Resource ist “vorübergehend” nicht erreichbar. D.h. der Bot kommt hier auch nach einer Woche wieder und schaut nach, ob die Resource wieder da ist. Besser wäre hier der Code 404 Not Found oder 503 Service unavailable.

@Mario_Lorenz
Hi Mario,
zur Info: Hierzu gibt es auch schon einen Bug-Eintrag: https://bugs.oxid-esales.com/view.php?id=6992
Leider bisher ohne Fix.

Grüße
Fabian

@Alpha-Sys: Vielen Dank! Den Bug-Eintrag beobachte ich jetzt.

Dann ersetzte das die() doch einfach mit einem 301 redirect auf die Startseite.
Natürlich kannst du auch andere codes senden. Ich hatte deine Frage nur so verstanden dass es keinen Eintrag in der exception.log mehr gibt.