Hallo,
ich habe meine Version von 4.5.10 auf 4.6.0 gepatched. Nun tritt folgende erscheinung auf.
Wenn ich den Admin bereich betrete wird eine 114mb große oxeec_langcache_1_1_1_shop_default.txt Datei erzeugt.
Ich habe es darauf reduziert das die Datei im tpl/admin/de/lang.php ein “neues” array hat:
$aSeoReplaceChars = array(
'ä' => 'ae',
'ö' => 'oe',
'ü' => 'ue',
'Ä' => 'AE',
'Ö' => 'OE',
'Ü' => 'UE',
'ß' => 'ss',
);
Dieses array erzeugt so etwas wie eine Endlosschleife wenn es in core/oxlang.php bearbeitet wird.
Das resultat in der .txt sieht dann in etwa so aus:
‘ÃÂö’ => ‘oe’
‘ÃÃÂö’ => ‘oe’
‘ÃÃÃÂö’ => ‘oe’
…
Ist da schon wer drauf gestoßen?
Wenn ich das Array aus der lang.php entferne ist dei .txt Datei normal groß.
Hi,
ist ein bug, wie ich wieder festellen musste.
Hallo Bernd,
ich glaube, das hängt mit diesem hier zusammen:
https://bugs.oxid-esales.com/view.php?id=3998
Wenn alles in UTF-8 ausgegeben wird, sollte das doch vom Tisch sein, oder? Ausserdem hätten die Japaner dann mehr Spass mit der Datei
Gruß
Hi,
also du meinst wenn man den charset des $aLand Array auf UTF-8 setzt sollte das dann Funktionieren? Oder meinst du was anderes?
Also wenn ja, dann ist das bei mir so das das $aSeoReplaceChars Array im Cachefile leer ist… auch komisch…
Ich habe auch Probiert die Datenkodierung des Lang files umzustellen. Hatte auch nichts gebraucht außer Kaputte umlaute bei der Ausgabe(normal).
Es ist, so denke ich, falsch Programmiert. Den die Schleife, die im bugReport beschrieben ist, codiert immer wieder das gleiche Array um($aSeoReplaceChars) und dies wird expotentiel immer schlimmer.
ä => À
nächster Schleifendurchlauf
À => Ãâ¬
nächster Schleifendurchlauf
Ã⬠=> ÃÂâ¬
…
Und bei 3 lang Files ist das ja auch “erstmal” kein Problem. Bei 22, wie bei, ist die Datei dann 120mb groß.
Die Abhilfe ist ja in meinem Fall ganz simpel.
Am ende des Schleifendurchlauf einfach $aSeoReplaceChars = array();