Hi
Ich habe das Typo3 CMS einer bestehenden Site auf 4.5.0. upgegraded und seither habe ich Probleme mit dem Aufbau der Website im Frontend, teilweise auch im Backend z.B. beim laden von Admin Extension.
Lösche ich alle Cache Dateien "temp_CACHED...etc..localconf.php" braucht das CMS unendlich lange einzelene Seiten im FE aufzubauen. Das kann sogar bis zu 30 min dauern bis eine einzelene Page dargestellt wird. Das gleiche gilt dann natürlich für alle anderen einzelnen Pages.
Im Backend funktionieren alle /sysext/ Erweiterungen nach dem Löschen des Caches normal, alle Admin Extension (z.B. Awstats) jedoch zeigen das selbe Problem wie die Pages im FE.
Sobald alle Pages gecached sind, funktioniert die Seite perfekt.
Weiß jemand wo das Problem sein kann (CMS, PHP, DB Zugriff, Server zu schwach, etc.) bzw. wie kann ich bei der Fehlersuche das Problem eingrenzen?
Jeder Anhaltspunkt würde mir weiterhelfen.
Danke.
Gruss, spoke
Sind denn auch alle erforderlichen Datenbankänderungen gemacht worden?
Hi ankes
Ich hoffe nicht, dass ich etwas vergessen habe:
- Typo3-src files eingespielt
- Installtool upgrade procedure
- DB compare und import
- Cache löschen
Die DB habe ich erst im Nachhinein per Hand mit phpmyadmin auf UTF8 umgestellt:
ALTER database ... CHARACTER SET utf8_unicode_ci;
ALTER TABLE ... CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
Folgendes habe ich in der localconf.php:
$TYPO3_CONF_VARS['BE']['forceCharset'] = 'utf-8';
$TYPO3_CONF_VARS['SYS']['setDBinit'] = 'SET NAMES utf8;';
$TYPO3_CONF_VARS['SYS']['UTF8filesystem'] = '1';
Leider hat auch die Umstellung auf UTF8 das Problem nicht gelöst.
Fehlt in der Vorgehensweise noch etwas?
Übrigens, der Upgrade war von v4.3.x nach v4.5.0.
Danke, spoke
Wenn es mein Problem wäre, würde ich jetzt nach und nach alle Extensions (keine SystemExtensions) deaktivieren und immer wieder testen.
ankes schrieb
Wenn es mein Problem wäre, würde ich jetzt nach und nach alle Extensions (keine SystemExtensions) deaktivieren und immer wieder testen.
Hi ankes
Danke für deine Hilfe.
Ich glaube ich konnte die Fehlerursache eingrenzen. Wenn ich folgendes in die localconf.php schreibe und demnach das Logging ausschalte, läuft die Seite soweit normal:
$GLOBALS['TYPO3_CONF_VARS']['SYS']['enableDeprecationLog'] = 0;
Mehrere Tests (mit/ohne Parameter in localconf.php) haben bisher gezeigt, dass es mit dem zusammenhängen muss. Ich werde das Problem mal mit besagtem Eintrag über einen längeren Zeitraum beobachten und ggf. später nochmal ein Update geben.
Ganz klar ist mir hingegen noch nicht ganz, warum das CMS bei eingeschaltetem Logging und dann bei Aufruf einer Page so lange zum Aufbau der Seite braucht. Es scheint wahrscheinlich etwas mit dem Zugriff auf das Log oder etwas mit Speicherbelastung zu tun zu haben.
Reicht es, einfach dass Logging auszuschalten oder soll ich die Ursache des Problems beheben?
Danke, Walter
Hallo Walter,
das deprecation-Log ist nicht irgendein Log, das halt so vor sich hin logged, sondern es meldet alle "deprecated" Funktionaufrufe, also Aufrufe, die bereits nicht mehr unterstützt werden, oder deren Unterstützung demnächst ausläuft. Mit anderen Worten, du hast mind. eine sehr alte Extensions laufen, die Dinge tut, die nicht mehr erlaubt sind, bzw. demnächst aus dem Core rausgenommen werden. Anstatt das Log einfach auszuschalten, solltest du es mal aufmachen und nachschauen, was da geschrieben wurde. Es kann sein, dass eine einzelne Extension hier Probleme macht oder dass es mehrere sind.
Ausserdem solltest du einen Blick in die Tabelle sys_log werfen. Dort werden unter anderem Fehler und Warnung von PHP geloggt. Wenn tatsächlich das Deprecation-Log so rasant vollläuft, dass es die Performance stört, gehe ich davon aus, dass das sys-log ebenfalls betroffen sein könnte. Kann sein, dass diese Tabelle volläuft, ohne dass du es merkst.
Gruß
Peter, TYPO3 @ lisardo (Augsburg)
Hallo Peter
Ich danke dir für die Erklärung. Es macht natürlich Sinn die Ursache zu beheben.
Ich habe
$GLOBALS['TYPO3_CONF_VARS']['SYS']['enableDeprecationLog'] = 0;
wieder aus der localconf.php rausgelöscht und nun wieder
[SYS][enableDeprecationLog] = file
in der Konfiguration.
Nach Analyse des Logs habe ich auch die Ursache erkannt. Ein bestimmter von mir falsch definierter TS Code scheint nach den ersten Tests das Log zu sehr beansprucht zu haben.
Im sys-log habe ich auch einige Warnungen gefunden. Dazu werde ich erst aber mal eine Suche zur Fehlermeldung starten.
Besten Dank nochmals, Walter