Typo3: Fatal Error im BE nach Bildwechsel

Nach dem Update auf Typo3 4.6.3 habe taucht in einem lokalen Projekt (Xampp 1.7.3) folgendes Problem auf: Über das Standard-Modul „Nur Bilder“ wird ein einziges Bild im FE angezeigt. Diese Bild soll nun nach den folgenden Schritten ausgetauscht werden:
Bild markieren
> Bild löschen
> Speichern
> Cache löschen
> Neues (bereits hoch geladenes) Bild aus > Fileadmin > images auswählen
> Speichern
> Cache löschen

Beim letzten Speichern wird der Fehler offensichtlich: das neue Bild wird in der Vorschau nicht mehr angezeigt, statt dessen nur ein grauer Kasten. Wird der cache gelöscht, erscheint (zunächst innerhalb des BE als exception error) folgende Meldung:

„Warning: require(PATH_tslibclass.tslib_pibase.php) [function.require]: failed to open stream: No such file or directory inC:\Programme\xampp\htdocs\t3lib\class.t3lib_div.php on line 5140

Fatal error: require() [function.require]: Failed opening required ‚PATH_tslibclass.tslib_pibase.php‘ (include_path=‘.;C:\Programme\xampp\php\PEAR;C:/Programme/xampp/htdocs/typo3/contrib/pear/‘) inC:\Programme\xampp\htdocs\t3lib\class.t3lib_div.php on line 5140″

Dieser Fehler setzt sich nun permanent fort. Ausloggen und erneutes Login im BE ist nicht mehr möglich, es erscheint nur noch diese Meldung. Eine genau Erklärung für die Ursache kann ich nicht liefern (Kommentare erwünscht!), aber zumindest den Weg, das System wieder gangbar zu machen.

Die Lösung muss bei der Datei „4dd75627d598e9268bf5fac60215189b952b5d86.php“ (oder ähnlich) im Verzeichnis C:\Programme\xampp\htdocs\typo3temp\Cache\Code\cache_phpcode angesetzt werden.Bevor die folgenden Ansätze probiert werden empfiehlt es sich, diese (eigene) Datei aus einem Backup zurück zu spielen.
Ansatz 1: die Datei löschen

Damit kann man sich wieder im BE anmelden. Und den o. g. Bildertausch durch führen. Allerdings nur max. einmal, denn das gleiche Problem taucht anschließend wieder auf.

 

Ansatz 2: die Datei mit Schreibschutz versehen

Dieser Schritt führt zu einer dauerhaften „Lösung“ insofern, man anschließend beliebig oft Bilder tauschen kann, ohne das es erneut crasht. Das Wort „Lösung“ finde ich aber unzutreffend, es ist eher ein workaround.

 

Ansatz 3: Caching abschalten

Das m. E. beste Verfahren ist es, das Cashing für das BE explizit abzuschalten. Anschließend muss allerdings geprüft werden, welche Performance-Einbußen bei großen Installation mit multiplem Zugriff durch Redakteure auftreten. Ich habe keine fest gestellt.

Zum Abschalten des BE-Caching, in der /typo3conf/localconf.php folgende Zeile einfügen:

$TYPO3_CONF_VARS[‚SYS‘][‚caching‘][‚cacheConfigurations‘][‚cache_phpcode‘][‚backend‘] = ‚t3lib_cache_backend_NullBackend‘;

Die Ursache für das Verhalten ist damit weder erklärt noch korrigiert, lediglich die (negative) Wirkung unterdrückt.

Es kam mittlerweile ein Lösungsansatz aus den Typo3 Mail Listen, der zeitlich nach Kommentar 6 zu platzieren ist. Demnach lag es doch an der Extension mh_omsqlio. Hier habe ich in der ./mh_omsqlio/ext_localconf php die Zeile

require_once(t3lib_extMgm::extPath(‚mh_omsqlio‘).’class.tx_mhomsqlio_tceforms.php‘);

in ein

if (TYPO3_MODE == ‚FE‘)
{
require_once(t3lib_extMgm::extPath(‚mh_omsqlio‘).’class.tx_mhomsqlio_tceforms.php‘);
}

gepackt. Das Problem war anschließend verschwunden.

8 Einträge zu “Typo3: Fatal Error im BE nach Bildwechsel

  1. Aua, ne.. sorry, das geht ja alles absolut gar nicht!

    Egal ob das Abschalten des Autoloader Caches oder manuell an den Cache-Dateien herumzuspielen. Um Himmels Willen, mir wird schlecht..

    Bitte wende dich an eine der TYPO3-Mailinglisten oder zur Not an ein Forum.

    Füge mal in devIpMask deine IP-Adresse ein, dass dir der DebugExceptionHandler einen Stack-Trace mit ausgibt. Dann kannst du vielleicht ehr sehen, wo der Aufruf mit dem falschen Parameter PATH_tslibclass.tslib_pibase.php her kommt. PATH_tslib ist ja eigentlich eine Konstante, sollte also nicht einfach als String vor dem Pfad angefügt werden…

    Steffen

  2. Danke für deine Nachricht Steffen!

    Ich hatte den Fall bereits gepostet ( bit.ly/z5SqWD ), ohne eine Antwort zu bekommen. Deine Empfehlung habe ich mir angeschaut. Ergebnis ist die folgende protokollierte Fehlermeldung:

    Core: Error handler (BE:sad: PHP Warning: Invalid argument supplied for foreach() in C:\Programme\xampp\htdocs\t3lib\l10n\parser\class.t3lib_l10n_parser_llphp.php line 95

  3. Schau Dir alle installierten Extensions an, die eine ext_autoload.php haben. In einer dürften „komische“ Sachen drinstehen. Es ist eh seltsam dass eine Datei die für das Frontend gedacht ist (tslib_pibase) im Backend eingebunden wird.

    Alles Andere ist wie von Steffen erwähnt rumdoktorn am Symptom und nicht an der Ursache…

  4. Hallo Helmut,

    was meinst du mit „komische Sachen“?

    Die ext_autoload.php lässt sich (22 mal und nur) im Ordner C:\Programme\xampp\htdocs\typo3\sysext\ finden. Also kann der Fehler nicht von einer selbst installierten ext sein.

    Die Php im Unterordner /rtehtmlarea finde ich noch ganz interessant:

    $rtehtmlareaExtensionPath . ‚class.tx_rtehtmlareaapi.php‘,
    ‚tx_rtehtmlarea_base‘ => $rtehtmlareaExtensionPath . ‚class.tx_rtehtmlarea_base.php‘,
    ‚tx_rtehtmlarea_statusreport_conflictscheck‘ => $rtehtmlareaExtensionPath . ‚hooks/statusreport/class.tx_rtehtmlarea_statusreport_conflictscheck.php‘,
    ‚tx_rtehtmlarea_pi1‘ => $rtehtmlareaExtensionPath . ‚pi1/class.tx_rtehtmlarea_pi1.php‘,
    ‚tx_rtehtmlarea_pi2‘ => $rtehtmlareaExtensionPath . ‚pi2/class.tx_rtehtmlarea_pi2.php‘,
    ‚tx_rtehtmlarea_pi3‘ => $rtehtmlareaExtensionPath . ‚pi3/class.tx_rtehtmlarea_pi3.php‘,
    ‚tx_rtehtmlarea_browse_links‘ => $rtehtmlareaExtensionPath . ‚mod3/class.tx_rtehtmlarea_browse_links.php‘,
    ‚tx_rtehtmlarea_select_image‘ => $rtehtmlareaExtensionPath . ‚mod4/class.tx_rtehtmlarea_select_image.php‘,
    ‚tx_rtehtmlarea_user‘ => $rtehtmlareaExtensionPath . ‚mod5/class.tx_rtehtmlarea_user.php‘,
    ‚tx_rtehtmlarea_parse_html‘ => $rtehtmlareaExtensionPath . ‚mod6/class.tx_rtehtmlarea_parse_html.php‘,
    );
    unset($rtehtmlareaExtensionPath);
    ?>

    – schließlich finde ich in einem weiteren Unterordner hier die „select_image.php“.

    Die einzelnen 22 Dateien sind von zum Teil deutlich unterschiedlicher Größe und dementprechend anderem Inhalt und Aufbau. Ich kann jedoch die Inhalte nicht wirklich interpretieren und so leider auch keinen Fehler erkennen.

  5. Wie schon in meinem Post angedeutet: PATH_tslib ist eine Konstante. Die wird wohl nur gesetzt, wenn du dich im Frontend aufhälst.

    Irgendwas versucht bei dir jetzt aber eine Klasse der tslib zu nutzen, weshalb der Autoloader die Datei lesen will. Da die Konstante PATH_tslib nicht gesetzt ist, verwendet PHP den Konstantennamen als String (yay..) und findet natürlich keine Datei namens PATH_tslibclass.tslib_pibase.php.

    Ich denke nicht, dass der Fehler in einer Autoload-Datei liegt, sondern nur daran, dass eine Klasse aus der tslib in einem Kontext genutzt werden soll, in der PATH_tslib nicht gesetzt ist.

    Was du im Forum da überall gepostet hast war zwar auch komisch, sind letztendlich aber nur Warnungen, nicht der eigentliche Fehler.

    Wie gesagt.. sei so gut und schreib’s auf eine vernünftige Mailingliste (typo3-english), dann hilft dir hoffentlich wer. Ich mach das Browser-Tab jetzt jedenfalls zu und schau nicht weiter nach neuen Kommentaren.

    Steffen

  6. Eine weitere Facette: es sind die Erweiterungen ADODB, mh_lib und mh_omsqlio installiert (mh_omsqlio ist für meine Bedürfnisse eine der besten Erweiterungen, um im FE direkt mit Tabelleninhalten zu arbeiten).

    DEINSTALLIERE ich mh_omsqlio, funktioniert alles wieder und es kommt keine einzige Fehlermeldung. Nach der erneuten Installation dieser ext ist der Fehler wieder da. Der Autor mh hat freundlicherweise einen Blick darauf geworfen und bestätigt, dass es hier eigentlich keine Abhängigkeiten geben kann.

    Dem vertraue ich und kann es nachvollziehen, da diese ext in mehreren Internetpräsenzen auf der neuen Typo3 Version problemlos läuft.

    Was aber auch bedeutet, dass die Suche nach der Lösung keinem direkten Teil der Installation zugeordnet werden kann.

    Von daher werde ich die lokale Installation vorerst auf Typo3 4.5.10 weiter laufen lassen, und zu gegebener Zeit dieses Thema weiter verfolgen.

    Weitere Kommentare sind natürlich jederzeit willkommen.

Antwort an admin Abbrechen

Die E-Mail Adresse wird nicht veröffentlicht. Required fields are marked *