oxchkversion bricht nach 2 Minuten wegen max_execution_time = 120 ab.
Leider bietet Plesk keinen größeren Wert an. Manueller Eintrag der Variable in dem Plesk-Feld “Zusätzliche Konfigurationsanweisungen” wirkt offensichtlich nicht.
Ich habe das mal für 4.10.5 CE (NeueInstallation) geprüft. Hier gibt’s schon jetzt mehrere Einträge ala aServersData_24ac1b69a4f30773b11743511d7b1b16, ohne dass Admin -> Master Settings -> Settings -> Administration -> Allow a connection... aktiviert ist. Es sieht so aus, dass unter bestimmten Voraussetzungen in oxconfig geschrieben wird, ausgelöst von
`oxSystemEventHandler->onShopStart() über oxOnlineLicenseCheck->validateShopSerials() bis hin zu oxServersManager->saveToDb();
Die Einstellung im Admin ist bei mir auch nicht aktiviert.
Ich habe jetzt auf dem Testsystem PE 4.10.6 nochmal einen Test gemacht und zwei Seiten des Shops aufgerufen. Das hat folgende Einträge in oxconfig erzeugt:
| oxbaseshop | aServersData_ab587a9aa48229af821 | arr | 2017-11-08 10:38:39 |
| oxbaseshop | aServersData_ab587a9aa48229af821 | arr | 2017-11-08 10:39:00 |
| oxbaseshop | aServersData_ab587a9aa48229af821 | arr | 2017-11-08 10:39:04 |
| oxbaseshop | aServersData_ab587a9aa48229af821 | arr | 2017-11-08 10:39:04 |
| oxbaseshop | aServersData_ab587a9aa48229af821 | arr | 2017-11-08 10:39:05 |
| oxbaseshop | aServersData_ab587a9aa48229af821 | arr | 2017-11-08 10:39:05 |
| oxbaseshop | aServersData_ab587a9aa48229af821 | arr | 2017-11-08 10:39:06 |
| oxbaseshop | aServersData_ab587a9aa48229af821 | arr | 2017-11-08 10:39:06 |
| oxbaseshop | aServersData_ab587a9aa48229af821 | arr | 2017-11-08 10:39:06 |
| oxbaseshop | aServersData_ab587a9aa48229af821 | arr | 2017-11-08 10:39:06 |
| oxbaseshop | aServersData_ab587a9aa48229af821 | arr | 2017-11-08 10:39:06 |
| oxbaseshop | aServersData_ab587a9aa48229af821 | arr | 2017-11-08 10:39:06 |
| oxbaseshop | aServersData_ab587a9aa48229af821 | arr | 2017-11-08 10:39:06 |
| oxbaseshop | aServersData_ab587a9aa48229af821 | arr | 2017-11-08 10:39:07 |
| oxbaseshop | aServersData_ab587a9aa48229af821 | arr | 2017-11-08 10:39:07 |
| oxbaseshop | aServersData_ab587a9aa48229af821 | arr | 2017-11-08 10:39:08 |
| oxbaseshop | aServersData_ab587a9aa48229af821 | arr | 2017-11-08 10:39:10 |
| oxbaseshop | aServersData_ab587a9aa48229af821 | arr | 2017-11-08 10:39:10 |
| oxbaseshop | aServersData_ab587a9aa48229af821 | arr | 2017-11-08 10:39:11 |
Auf dem Produktionssystem sind seit gestern abend auch schon wieder 3800 Datensätze erzeugt worden.
Mir kommt es vor, als hätte sich mit 4.10.5 der oben erwähnte alte Bug wieder eingeschlichen. Bei mir ist das Problem zwei Tage nach dem Upgrade auf 4.10.5 aufgetreten. Das könnte natürlich auch Zufall sein.
Okay. Wird grad gecheckt.
Ich bleibe auch dabei:
Mit dem Patch von 4.10.4 auf 4.10.5 hat das Problem bei mir angefangen.
Ich habe das Patch am 20.08.2017 eingespielt. Ab da haben die Einträge angefangen.
Vielleicht haben es viele User noch gar nicht gemerkt, dass Ihre oxconfig immer noch oder überhaupt vollgeschrieben wird.
Zuvor hatte ich nach unzähligen Ursachen gesucht, warum mein eShop so langsam geworden ist.
Auch die max_execution_time hatte ich vor einigen Wochen auf max gesetzt, da mein eShop immer wieder ausstieg.
Als Ursache hatte ich mich auf “Bad Bots” konzentriert.
Performance von meinem Shop um Welten besser, seit ich die sinnlosen Einträge in der oxconfig manuell gelöscht habe.
Das dürfte der Fix für #6483 gewesen sein. #6484 ist “related”. Unten im Bug stehen jeweils die Commits dazu, vielleicht hilft das schonmal weiter:
https://github.com/OXID-eSales/oxideshop/commit/c0fcad094e9e000c299e10f819d67d7e4ee808ae
https://github.com/OXID-eSales/oxideshop/commit/e7e6088df97c847873377b8686c07206f7a35006
Gruß
Ich habe grade die beiden Dateien oxserverchecker.php und oxserversmanager.php in /core durch die aus der Version 4.10.4 ersetzt und das Problem ist verschwunden!
Die beiden Dateien waren in dem Patch 4.10.4 auf 4.10.5 enthalten (PE).
Das ist klar, weil es $this->_validateOnline(); da noch nicht gibt.
Ich tippe mal auf folgendes als Ursache:
$blSendData = (bool) $this->_getConfig()->getConfigParam('blLoadDynContents');
Hab jetzt mal die oxserversmanager.php aus der CE-Version reinkopiert und versucht, zu debuggen.
Dabei fällt mir auf, daß das Programm den Variablennamen mit 45 Stellen Länge erzeugt:
aServersData_ab587a9aa48229af8210353f8d4d0eda
erzeugt, diese aber in der Datenbank wegen der Längenbegrenzung des OXVARNAME-Felds in der Tabelle auf 32 Stellen abgeschnitten wird:
aServersData_ab587a9aa48229af821
Da der Vergleich scheitert, wird immer wieder ein neuer Datensatz eingesetzt.
Man muss also einfach das OXVARNAME-Feld in der oxconfig-Tabelle auf mind. 45 Stellen verlängern. Damit ist das Problem gelöst.
Nachtrag: grade fällt mir auf, daß das Feld in der CE-Version Länge 100 hat, deshalb tritt das Problem dort nicht auf!
Um es nochmal zusammenzufassen:
Es ist kein Bug im Code, sondern das Feld OXVARNAME in der Tabelle oxconfig wurde beim Einspielen der Patches nicht von 32 auf 100 Stellen verlängert, wie es sein sollte.
In der neueren Version sind die beiden Felder OXMODULE und OXVARNAME auf Länge 100 gesetzt.
Wer das Problem hat, sollte also die oxconfig prüfen und die beiden Felder ggf. verlängern
1 Like
Das kann ich nicht bestätigen. Das Feld besitzt seit Version 4.80 die Länge von 100 (zumindest in CE).
Das ist richtig (ab 4.9 nach meinen Unterlagen), insofern war meine Aussage “in den neueren Versionen” nicht korrekt.
Bei meiner Installation war das Feld nur 32 Stellen lang - aus welchem Grund auch immer - und das war die Ursache des Fehlers.
@m431342
Perfekt! Sau stark!
Das war´s! Bei mir stand auch noch der Wert 32 in den Feldern. Ich habe erhöht auf 100 - jetzt erfolgen keine sinnlosen Einträge mehr!
Vielen Dank an alle für die super Unterstützung.
Ich bin mir sicher, daß noch so einige auf diesen Beitrag stoßen werden.
Möglicherweise ist die updateApp nicht sauber durchgelaufen. Dann gibt’s aber in der Regel Fehlermeldungen 