Das hier ist ein Konzept, das ich umgesetzt habe, den Quellcode darf/möchte ich (noch) nicht veröffentlichen.
Aufgabenstellung: im Extranet dem Benutzer das Datum seines letzen Logins anzeigen. Problem: Sobald sich ein Benutzer in Typo einloggt, wird automatisch das Datum neu gesetzt, so dass der Benutzer immer den Zeitpunkt vor ein paar Minuten zu sehen bekommt.
Egal wie der Benutzer sich einloggt – newloginbox oder felogin (neu als Systemextension in 4.2), das Einloggen und das Setzen des Wertes findet immer auf Core-Ebene statt. Die felogin bietet zwar eine Möglichkeit für einen Hook an, da ist das Setzen des Wertes aber schon passiert und auf den alten Wert kann man nicht mehr zugreifen.
Um das Problem zu lösen, braucht man in der fe_users Tabelle zwei weitere Felder – ein Backup-Feld für lastlogin und ein Feld mit dem tatsächlichen letzen Login, nennen wir sie mal ll_bkp und real_ll.
Bei Login-Vorgang passiert folgendes: Ganz am Anfang auf Core-Ebene wird der Benutzer eingeloggt, der Wert lastlogin wird gesetzt. Wenn die Extension aufgerufen wird, wird aus dem Backup (der ist noch der alte) der Wert ins Real-Last-Login übertragen, und das Backup mit dem neuen lastlogin-Wert (der aktuelle Zeitpunkt) überschrieben. Warum braucht man das Backup-Feld? Weil man keine Möglichkeit hat, das lastlogin vor dem Überschreiben irgendwie zu sichern. Und das macht man „manuell“ in der Extension.
Natürlich muss sich der Benutzer mindestens zweimal einloggen, damit im real_ll ein vernünftiger Wert steht (ist aber auch so logisch).
Wann kann man das einbauen? Man kann den Hook in der newloginbox oder felogin nutzen, um den eben beschriebenen Kopiervorgang auszuführen. Das wird dann beim Einloggen einmal ausgeführt. Das mit dem Hook klappt leider nicht, wenn die Login-Seite die Eigenschaft gesetzt hat, beim Einloggen ausgeblendet zu werden und stattdessen die Logout-Seite angezeigt wird. Da kommt es nach dem Einloggen gar nicht erst zur Ausführung des felogin/newloginbox Codes und des dazugehörigen Hooks.
Da besteht die Möglichkeit, die Extension auf jeder Seite einzubinden und die Werte nur dann zu kopieren, wenn ein Benutzer eingeloggt ist und das Backup sich vom lastlogin-Wert unterscheidet. Sobald man es einmal kopiert hat, ist es nicht mehr der Fall. Die Werte, die man zum Vergleichen benötigt stehen praktischerweise direkt im GLOBALS Objekt, das beim Einloggen mit allen in der Datenbank verfügbaren Daten des Benutzerdatensatzes geladen wird.

Bei der Entwicklung von eigenen Extensions arbeite ich im BE fast nur noch mit Flexforms – es ist wirklich toll, dass man damit fast alles an Eingaben realisieren kann. Ich wollte mal ein paar sinnvolle Schnipsel zusammenstellen, wie man bestimmte Sachen definiert, ansonsten muss man in tt_news nachschauen (wunderbares Beispiel) und in anderen Extensions, wenn man was bestimmtest benötigt.
Wenn man den Kickstarter nutzt, dann wird gleich das richtige Grundgerüst definiert, aber hier ist es nochmal:




1






Die Sheets werden in Typo3 in Form von Reitern dargestellt. Ein Sheet kann einen beliebigen Namen haben (würd ich behaupten), der Kickstarter erzeugt eines, das sDEF heißt. Darin befindet sich ein Element namens ROOT und darin wird in TCEforms der Inhalt des Sheets definiert.




LLL:EXT:np_content_slideshow/locallang_db.xml:ff.settings

array






Innerhalb des el-Elements (ist vom Typ Array) können nun unterschiedliche Felder definiert werden. Der Name dieser Felder ist beliebig (darf keine Leer- und Sonderzeichen enthalten), darüber kann der Wert der Felder im Plugin in der PHP-Klasse ausgelesen werden.
Hier ist z.B. eine Checkbox:



1
LLL:EXT:extensionname/locallang_db.xml:ff.random

check




Der Wert heißt „random“ und kann im BE (MVC-Style) wie folgt ausgelesen werden:

$random = intval($this->configurations->get(‚random‘));

Ich habe mit das irgendwie so angewöhnt, die Locallang-Wert mit ff. zu versehen, damit man erkennt, dass es in den Flexforms verwendet wird.
Reicht für heute 🙂

Problem war, dass Redakteure keine Inhalte löschen konnten, aber auch nur manchmal. Es war möglich in der Listenansicht, aber nicht über das Mülleimer-Symbol in der „normalen“ Content bearbeiten Ansicht.
Die Rechte waren auf den ersten Blick richtig gesetzt, die Zugriffsrechte auch. Beim Anlegen der Elemente war es auch komisch – innerhalb eines 2-spaltigen FCEs war es nicht möglicht, dahinter oder davor schon. Wenn man doch ein Element innerhalb des 2-spaltigen FCE anzulegen versuchte, wurde es nicht korrekt verknüft und als „nicht verwendet“ dargestellt.

Die Lösung: Templa Voila bringt ein weiteres Feld mit, das sich in der Liste der „allowed excludfields“ gut tarnt – Seite:Inhalt. Dieses Feld muss bei der Gruppe mit ACLs ausgewählt werden und schon funktioniert es.

http://www.typo3.net/forum/list/list_post//73930/

Vergesse ich andauernd – so kann man das aktuelle Jahr in TypoScript ausgeben:

10 = TEXT
10.data = date: Y

Für weiteres in der Funktion date von php nachschauen:
d.m.Y. für aktuelles Datum
Update:
Bei vielen Seiten steht das aktuelle Jahr und das Copyright-Zeichen im Footer der Seite. Am besten kann man das mir diesem Schnipsel lösen, dann ist das Jahr immer aktuell. Wie man den Wrap gestaltet, ist jedem selbst überlassen.

10 = TEXT
10 {
data = date:U
strftime = %Y
wrap = ©| npostnik.de
}