Ich würde raten, dass die Variablen ohne Frontend Edit kleiner sind, ich hatte ja schon mal den Batzen gesehen der bei claus zurückgeschrieben wird. War da nicht irgendwas mit mysql_max_ .... ?
Eventuell gibt es viele Strukturebenen. Im Admin Modus (FE Session ON und eingeloggt) werden andere Daten gecacht, als nur als "normaler" Nutzer. Möglicherweise läuft irgendwas über.
Mal testen, was passiert, wenn man den Wert in der conf.in.php auf 0 oder 1 ändert
pepe wrote:Kanns vielleicht an der Laufzeitbegrenzung von PHP-Scripts liegen? mySQLdumper umgeht die Problematik durch Aufteilung in mehrere kleine Pakete
Es geht ja um das array was in die DB geschrieben wird und das war so gross dass es nicht mal in ein Skype Feld passt ... ich weiss, damit kann man nix anfangen.
Soll ich dir mal einen account machen auf einer der Maschinen ? Ich denke danach ist das Problem Geschichte !!
wie groß das serialisierte Array auch ist, 16MB groß darf es maximal werden. Das ist eine Menge. Testweise kann sysvalue_value auf Longtext umgestellt werden! Dann passen dort max. 4GB rein.
Würde zuwenig PHP Speicher vorhanden sein, müsste das Script bereits an anderer Stelle abbrechen.
PHP memory_Limit steht auf 128M
db_pers war vorher auch schon auf 1
Es hat (auch) irgendwas was mit der Situation eingeloggt / nicht eingeloggt im BE und dem Schalter frontend_edit 1/0 zu tun, "glaube" ich...
...denn der triggert den error / no error
Kleine Korrektur:
$phpwcms['SESSION_FEinit'] = 0; // set 1 to enable sessions in frontend, 0 to disable sessions in frontend
damit geht alles gut.
$phpwcms['SESSION_FEinit'] = 1; // set 1 to enable sessions in frontend, 0 to disable sessions in frontend
damit entsteht der besagte error
Ist nicht nachvollziehbar. Das ist eine "ganz" frische Installation? Oder irgendwelche Hacks, Frontend Render Scripte, Module, die dort dazwischenfunken könnten.