EXCEPTION_LOG.txt - Tags

Hallo,

ich nutze die neue CE6.0 mit dem ROXIVE-Template. Bei versch. Kontrollen ist mir aufgefallen, dass ich die EXCEPTION_LOG.txt wöchentlich löschen muss. Ich habe hier schon 26 MB gehabt…

Nun habe ich mich ein wenig mit den Einträgen befasst.
[message EXCEPTION_SYSTEMCOMPONENT_CLASSNOTFOUND tag]

habe ich jetzt 278 Treffer in 8 Stunden.

Nun muss ich dazu sagen, dass ich eigentlich Tags hatte, auch das neue Modul dazu installiert hatte. Da das aber mit Roxive nicht angezeigt wird, habe ich das Modul wieder deinstalliert.

Der vollständige Eintrag ist:
[18 Feb 17:52:21.437273 2018] [exception] [type OxidEsales\Eshop\Core\Exception\SystemComponentException] [code 0] [file /xxx/vendor/oxid-esales/oxideshop-ce/source/Core/UtilsObject.php] [line 222] [message EXCEPTION_SYSTEMCOMPONENT_CLASSNOTFOUND tag]

Muss ich das Modul mit Composer deinstallieren? Wenn ja, ich habe das mit FTP gelöscht, wie bekomme ich das gerade gebogen?

Dann habe ich in dieser Zeit 1162 Treffer für /d3/ - Hier habe ich den Modul-Connector installiert.

Der vollständige Eintrag lautet:
[18 Feb 12:30:48.171123 2018] [exception] [stacktrace] #4 /xxx/source/modules/d3/modcfg/Modules/Application/Controller/d3_oxshopcontrol_modcfg_extension.php(130): OxidEsales\EshopCommunity\Core\ShopControl->_process(‘tag’, NULL, NULL, NULL)

und z.B.
[18 Feb 12:30:48.171123 2018] [exception] [stacktrace] #5 /xxx/vendor/oxid-esales/oxideshop-ce/source/Core/ShopControl.php(137): d3_oxshopcontrol_modcfg_extension->_process(‘tag’, NULL, NULL, NULL)

Was kann ich hier machen?

PS. Bei der alten Foren-Version konnte ich einstellen, wann ich z.B. eine Info zu diesem Beitrag haben möchte. Das habe ich hier so noch nicht gefunden. Habe ich da was übersehen?

mfg

Gert

1 Like

wenn das Problem mit flow nicht auftritt, sondern nur mit roxive, dann ist die weitere Vorgehensweise ja ziemlich klar

Hm, die Tags wurden ja aus der OXID 6 rausgenommen und sind jetzt in nem eigenen Modul: https://github.com/OXIDprojects/tags-module

Hallo tabsl,

mfg

Gert

Dann wäre zu klären ob im Roxive Template Anpassungen vorgenommen werden müssen …

Das geht natürlich noch immer :slight_smile:
https://forum.oxid-esales.com/u/GPassin/preferences/notifications <-- Dort bedienst Du die Grundeinstellungen, zusätzlich kannst Du noch diese Einstellung hier auf der Seite benutzen:

Hallo tabsl,

ich würde sagen, dass die Fehler durch Roxive verursacht werden und habe ein Ticket aufgemacht. Flow verursacht keine Fehler.

mfg

Gert

Hallo Marco,

Aaaaahhh…

mfg

Gert

Hallo,

ich habe hier noch ein Verständnisproblem. Wieso habe ich im Log so viele Verweise - ca. 60% - in das vendor-Verzeichnis?

www/bp60/vendor/oxid-esales/oxideshop-ce/source/Core/ShopControl.php(272):

mfg

Gert

https://getcomposer.org/doc/articles/vendor-binaries.md

@tabsl
https://getcomposer.org/doc/articles/vendor-binaries.md1

Also mit der Google-Übersetzung lese ich hier nur etwas über den Composer???

Die Log-Einträge werden aber im laufenden Betrieb verursacht.

mfg

Gert

Oxid teilt sich in core und application, application liegt in source und core in vendor.

Oh mann :frowning:https://www.ab-heute-programmieren.de/composer-ein-ueberblick/ :wink:

1 Like

Hallo,

ich wollte mich nun der Sache mal wieder annähern, bin aber nicht weiter gekommen.

Alle anderen Fehler habe ich beseitigt. Nur diese Meldungen finden sich jetzt noch in der EXCEPTION_LOG.txt:

[01 Apr 18:30:20.094413 2018] [exception] [type OxidEsales\Eshop\Core\Exception\SystemComponentException] [code 0] [file /is/htdocs/xxx/vendor/oxid-esales/oxideshop-ce/source/Core/UtilsObject.php] [line 222] [message EXCEPTION_SYSTEMCOMPONENT_CLASSNOTFOUND tag]

[01 Apr 18:30:20.094413 2018] [exception] [stacktrace] #0 [internal function]: OxidEsales\EshopCommunity\Core\UtilsObject->oxNew(‘tag’)
[01 Apr 18:30:20.094413 2018] [exception] [stacktrace] #1 /is/htdocs/xxx/source/oxfunctions.php(103): call_user_func_array(Array, Array)
[01 Apr 18:30:20.094413 2018] [exception] [stacktrace] #2 /is/htdocs/xxx/vendor/oxid-esales/oxideshop-ce/source/Core/ShopControl.php(372): oxNew(‘tag’)
[01 Apr 18:30:20.094413 2018] [exception] [stacktrace] #3 /is/htdocs/xxx/vendor/oxid-esales/oxideshop-ce/source/Core/ShopControl.php(272): OxidEsales\EshopCommunity\Core\ShopControl->_initializeViewObject(‘tag’, NULL, NULL, NULL)
[01 Apr 18:30:20.094413 2018] [exception] [stacktrace] #4 /is/htdocs/xxx/vendor/oxid-esales/oxideshop-ce/source/Core/ShopControl.php(137): OxidEsales\EshopCommunity\Core\ShopControl->_process(‘tag’, NULL, NULL, NULL)
[01 Apr 18:30:20.094413 2018] [exception] [stacktrace] #5 /is/htdocs/xxx/vendor/oxid-esales/oxideshop-ce/source/Core/Oxid.php(26): OxidEsales\EshopCommunity\Core\ShopControl->start()
[01 Apr 18:30:20.094413 2018] [exception] [stacktrace] #6 /is/htdocs/xxx/source/index.php(15): OxidEsales\EshopCommunity\Core\Oxid::run()
[01 Apr 18:30:20.094413 2018] [exception] [stacktrace] #7 /is/htdocs/xxx/source/oxseo.php(28): require(’/is/htdocs/wp12…’)
[01 Apr 18:30:20.094413 2018] [exception] [stacktrace] #8 {main}

Wie kann ich dem Problem näher kommen? Prinzipiell kann es ja am Tag-Modul, am Template oder auch an Oxid liegen.

Ich habe getestet, das beim normalen Betrieb, also ganz normal surfen auf der Seite, keine Einträge generiert werden.

Kann es sein, dass die Einträge generiert werden, wenn User über Links auf meine Seiten kommen?

mfg

Gert

Wie in der Fehlermeldung ersichtlich wird versucht die Klasse tags zu laden, welche es in OXID 6 nicht mehr gibt. Diese wurde jetzt in das Tag-Modul ausgelagert und heisst oetagcontroller.

Anscheinend nutzt du noch alte Template-Fragmente …

Hallo tabsl,

vielen Dank für die Info. Ich habe es an den Template-Ersteller weiter geleitet.

mfg

Gert

Scheint immer noch aktuell zu sein. Hatte sich hier schon was getan? Wir haben bei einem Shop nämlich denselben Fehler. EXCEPTION_SYSTEMCOMPONENT_CLASSNOTFOUND tag ["[object]
Danke.

Nachtrag: Erledigt, sind nur die Abfragen von Suchmaschinen über cl=tag.

@GPassin & @rubbercut

Genau richtig erkannt: Die Ursache sind Search-Bots die Eure alten Tag-Links noch kennen. Und warum die immer wieder im Log auftauchen liegt daran, dass OXID beim Aufruf einer alten Tag-Url oder generell einer URL die auf einen Controller basiert, der nicht mehr verwendet wird, zwei Dinge macht:

  1. Mit einem 302-header den Aufruf auf die Startseite umleiten.
  2. Eine Exception werfen

302 besagt:URL dass die angeforderte Ressource vorübergehend auf die URL verschoben wurde, die durch den Location -Header angegeben wurde. Das bedeutet für den Bot, dann komme ich noch einmal vorbei und probiere es noch einmal.

Sprich, Ihr werdet die Exeption-Einträge solange nicht los, bis Ihr entweder:

  1. Die URL bzw. den Controller wieder bereitstellt
    oder
  2. Statt dem 302 Header einen Header ausgebt, der den Bot bremmst: 301 oder 308 (moved permanently)

Ich selbst bin da in einer Zwickmühle. Der 302-Header passt ja, wenn tatsächlich ein Controller mal vorrübergehend klemmt. Darum ist die OXID-Lösung grundlegend nicht verkehrt. Es wäre aber auch irgendwie trotzdem smart, bei bestimmten Controllern bewusst einen anderen Header zu wählen, um die Exeptions in den Griff zu bekommen.

1 Like