Extensionmanager: Fatal error: Call to a member function getUid() on a non-object

Gestern war es wieder einmal so weit: leises Fluchen war zu hören. Grund hierfür war, dass der Extensionmanager einer frischen TYPO3-Installation keine Extension installieren wollte, sondern seinen Dienst mit einer Fehlermeldung abbrach:

Fatal error: Call to a member function getUid() on a non-object in /var/www/test/typo3/6.1.5/typo3/sysext/extensionmanager/Classes/Utility/Repository/Helper.php on line 251

Recht schnell war verständlich, dass hier auf ein nicht vorhandenes Repository versucht wird zuzugreifen. Aber warum? Bei einer frischen Installation sollte das doch funktionieren? Und es tut doch normal auch… Wir wollten es wissen. Was geht hier (manchmal) schief?

Wir setzten schnell eine frische Test-Installation auf – alles passt. Dann gab so eine Idee: „Ach, ähm, ich musste die Datenbankstruktur gestern nochmal neu anlegen“. Also löschten wir alle Tabellen aus der Datenbank und legten diese via Install Tool -> Database Analyser -> COMPARE neu an. Und siehe da, der Extensionmanager versagt seinen Dienst mit obiger Meldung 🙂

Weiterlesen»

tt_news: BE-User Zugriff auf alle Kategorien geben

Wenn TYPO3-Websites mit vielen Redakteuren und Redakteursgruppen arbeiten, dann werden oft auch die Zugriffsrechte auf News-Beiträge bzw. -Kategorien eingeschränkt. Dies ist bequem über die BE-User bzw. -Gruppen zu regeln, indem dort aus dem Kategoriebaum die erlaubten Kategorien ausgewählt werden.

Nun gibt es aber oft auch Chefredakteure, die alles sehen können sollen. Bisher war dies kein Problem – einfach keine Kategorie explizit zuweisen. Dies wurde implizit als „alle Kategorien“ gewertet. Seit Version 3 verhält sich tt_news jedoch unerwartet anders, nämlich genau anderherum: ist keine Kategorie angegeben, hat der (Chef-)Redakteur auch keinerlei Berechtigungen.

Soll das Newssystem aber dynamisch sein, d.h. auch neue Kategorien durch Nicht-Admin-User angelegt werden können, oder ist das System mit vielen Kategorien versehen, wird es unmöglich, alle Kategorien einzeln zuzuweisen bzw. nachzutragen, falls eine neu hinzukommt.

Ursache

Die Ursache wurde bereits im Januar 2010 erkannt (#13232). Die Methode, die für das Backend eine Liste der erlaubten Kategorien liefern soll, liefert im Falle einer leeren Kategorieauswahl „0“ statt eines leeren Strings. Bei genauerer Betrachtung wird dies auch klar: vor der Rückgabe wird der Wert durch die Methode t3lib_div::intExplode() geschickt, um sicher zu gehen, dass nur INT-Werte in der Liste sind. Leider wird hier der dritte Parameter $onlyNonEmptyValues nicht auf TRUE gesetzt, wodurch die default-Belegung (FALSE) bleibt. Und was gibt ein intval(„“)? Genau…

Im Bugtracker finden sich zwei Patches dazu. Die von mir bevorzugte Lösung: 0013232_2.diff

Fehler 500 mit TYPO3 beim Versenden von E-Mails

TYPO3 (zumindest bis zur Version 4.3.3) hat einen bekannten, nicht geschlossenen Bug der – je nach Serverkonfiguration – eine weiße Seite oder einen 500 Servererror liefert.
Der Fehler tritt auf, wenn PHP mit Suhosin als fastCGI installiert ist, was allerdings mittlerweile sehr üblich ist.

Hier ist der Fehler nochmal näher beschrieben: http://bugs.typo3.org/view.php?id=13701

Abhilfe schafft das auskommentieren der entsprechenden ini_set Zeile in t3lib/class.t3lib_htmlmail.php
Mit einem Texteditor, oder z.B. wie folgt:

sed -i 's,@ini_set\(\'sendmail_from,//@ini_set\(\'sendmail_from,1' t3lib/class.t3lib_htmlmail.php

Ein Patch zum sauberen Fixen wurde im Zuge des RFC #13701 an die Core-Liste versandt, stieß aber auf wenig Interesse bzw. Zustimmung, sodass er nicht in den Core eingeflossen ist. Für Interessierte ist er hier bereitgestellt:

Update 2010-05-31:

Committed bug_13701.diff to:
* trunk rev. 7787
* 4.3 rev. 7788