TYPO3@lisardo

Damit meine ich ein recht gängiges Problem: per E-Mail oder per Lesezeichen wird ein Link aufgerufen, der auf eine zugangsbeschränkte Seite verweist. Das übliche Verhalten von TYPO3 ist, dass die zugangsbeschränkte Seite dann leer gezeigt wird und sich der Besucher zuerst zum Login durchklicken und danach dann seine Seite wieder suchen muss. Irgendwie uncool. 

Ein paar Lösungen, die ich im Internet gefunden habe: 

• Nicht die Seiten zugangsbeschränken, sondern nur die Inhalte. Ausserdem auf jede Seite eine Login-Box. Damit tauchen nach dem Login die Inhalte auf. 
• Die zugangsbeschränkten Seiten in den Zweig unterhalb der Login-Seite positionieren. Damit wird zumindest erreicht, dass nicht die leere Seite gezeigt wird, sondern die Login-Seite. 

Das sind keine wirklichen Lösungen, es sind bestenfalls Workarounds. Es gibt aber eine Lösung, die nicht mal besonders schwierig ist. 

Schritt 1

In der localconf wird ein Eintrag für die Fehler-404-Seite eingefügt, z. B.: 

Dabei wird entweder direkt die Login-Seite angegeben, oder es wird eine eigene Fehlerseite im Backend angelegt, die zusätzlich das Login-Formular enthält (so habe ich es hier gelöst). Ich bevorzuge letzteres: wenn man ein zweites Login-Formular auf der Fehlerseite einrichtet, können die regulären »Weiterleitungen nach Login« nicht in die Quere kommen. 

Schritt 2

Im Plugin »felogin« muss eine referrer-Weiterleitung eingestellt werden:
Redirect-Options – Defined by Referrer. 

Das wars, ab sofort werden alle Links auf zugangsbeschränkte Seiten auf die neue Login-Seite weitergeleitet und ein Referrer übergeben. Der wird dann von felogin benutzt, um die beabsichtigte Seite anzuspringen. 

Getestet in TYPO3 4.4.6 – sollte aber in 4.5 auch funktionieren. 

Update: 

Der Artikel ist mittlerweile etwas älter geworden. Für die TYPO3-Versionen des Viererzweigs stimmt er noch, aber nicht mehr für TYPO3 6.x. Hier ist es deutlich einfacher geworden, da irgendwann seit Version 4.6 oder 4.7 der Core prinzipiell Lightboxen vorsieht. Ich habe einen kleinen Artikel verfasst, der beschreibt  wie man eine Lightbox anlegen kann, ganz ohne Extension, und diese auch im RTE freischaltet: Lightbox im RTE (rtehtmlarea) ohne Extension. 

----

Prinzipiell ist es möglich, mit Hife der Extension rtelightbox eine Lightbox im RTE umzusetzen – in der Regel reicht es einfach, eine gängige Lightbox zu installieren und danach im Template folgende statische Typoscript-Templates einzubinden: 

• das Template der jeweiligen Lightbox
• Clickenlarge Rendering (rtehtmlarea)
• RTE Lightbox (rtelightbox)

und zwar muss das Template von RTE Lightbox an letzter Stelle stehen. 

Leider hat die Extension aber einen kleinen Fehler: sie bindet das unbearbeitete Originalbild in die Lightbox ein, heisst, man erhält unter Umständen ein viel zu großes Bild in der Lightbox. 

Wenn FCEs eingesetzt werden, so muss unter Umständen für jede Spalte ein eigener Wert für die Bildgröße eingesetzt werden. Das geht über eine Modifikation der DataStructure – also des XML – des FCE.

Ziel ist die Erstellung einer Extension, die alle Features zur Mehrsprachigkeit bietet, die zur Ausstattung von TYPO3 gehören.

Die Datenbank-Struktur

Diese drei Felder müssen zusätzlich in der Extension in der »ext_tables.sql« angelegt werden:

Die »ext_tables.php« muss so erweitert werden:

Und das »columns«-Array in der »tca.php« ebenfalls:

Wichtig: Damit die Zuordnung der Sprach-Overlays funktioniert, muss oben bei »foreign_table« die korrekte Tabellenbezeichnung der Extension eingegeben werden, ebenso bei »foreign_table_where« – insgesamt also dreimal.

Damit die Redakteure später nicht nur Language-Overlay-Datensätze anlegen, sondern einen Datensatz direkt einer Sprache zuordnen können (um z. B. Datensätze in einer Fremsprache anlegen zu können, ohne dass es zuvor einen Datensatz in der Standardsprache gibt), muss auch noch das »types«-Array in der »tca.php« erweitert werden:

Damit erscheint im Backend ein DropDown-Menü mit einer Auswahl von allen definierten Alternativ-Sprachen sowie der Auswahl »Alle«.

Im Backend müsste jetzt alles richtig ausgegeben werden: Die Redakteure können neue Datensätze anlegen, diese einer oder allen Sprachen zuordnen, oder nachträglich Datensätze in der Standardsprache übersetzen. Also genauso wie bei den normalen Inhaltselementen.

Natürlich muss die Ausgabe im Frontend das entsprechend berücksichtigen

Ausgabe von sprachabhängigen Texten ins Template

Damit sind nicht die Inhalte aus den Datentabellen gemeint sondern zum Beispiel Überschriften oder Labels für Formularfelder, die ebenfalls den Sprachen angepasst werden müssen. Diese Texte werden zunächst in die »locallang.xml« im pi1-Ordner der Extension eingetragen:

Diese Datei muss in UTF-8 abgespeichert werden, sonst gibt es entweder eine leere Frontend-Seite oder eine Fehlermeldung, je nach TYPO3-Version. Sie darf weder HTML noch Entities enthalten. In der Regel wirds das nicht brauchen (da die Datei ja UTF-8 ist), aber falls doch, gibt es folgende Möglichkeiten:

Entitiy definieren:

Sieht komisch aus, funktioniert aber. Die nächste Möglichkeit ist wahrscheinlich einfacher:

HTML in »locallang.xml«

Jeder HTML-eintrag muss also mit

maskiert werden.

Ausgabe ins Frontend

Damit eine Ausgabe möglich wird, muss die »class.tx_meineExtension_pi1.php« erweitert werden:

Die Zeile $this->pi_loadLL(); lädt die notwendige Klasse.

Die eigentliche Ausgabe des Textes erfolgt so:

Die Optionen bedeuten:

• Name/Bezeichnung des Eintrags in der »locallang.xml«
• Defaultwert – in der Regel ein englischer Begriff, als Platzhalter, falls der Eintrag in der locallang.xml fehlt
• TRUE wenn der Wert durch htmlspecialchars() laufen soll

Daten aus den Datentabellen auslesen

Das erweist sich als das eigentliche Problem. Ich habe noch keine endgültige Lösung, aber die folgende funktioniert fürs erste.

1. Schritt: Daten aus der Tabelle holen. Dabei interessiert erstmal nur der WHERE-Teil des sql-Statements, der Rest dürfte klar sein:

Erläuterung: In der Defaultsprache wird »$this->cObj->enableFields()« aufgerufen, damit die versteckten Datensätze (und die gelöschten etc) nicht sichtbar werden. Bei den Alternativ-Sprachen entfällt das in diesem Schritt sondern folgt erst in einem weiteren. Die Zeile »’ AND (sys_language_uid ….« wählt alle Datensätze aus, die in »sys_language_uid« 0 (= Standardsprache) oder -1 (= alle Sprachen) stehen haben. Sie wählt aber auch alle Datensätze in der Alternativsprache aus, die keinen Eintrag in der Standardsprache haben.

Im nächsten Schritt werden die Sprach-Overlays geholt: die Felder des Datensatzes werden mit den Einträgen in der Alternativ-Sprache überschrieben:

Je nach Spracheinstellung werden dabei auch Einträge entfernt – also z. B. wenn sys_language_mode=strict eingestellt ist, werden alle nicht übesetzten Einträge entfernt.

Über GLOBALS[‘TSFE’]->fe_user kann man sich die gesamte Konfiguration der Frontenduser ausgeben lassen:

Ergebnis:

Dabei werden die Daten des eingeloggten Benutzers und seiner Benutzergruppe ausgegeben. Damit kann einfach überprüft werden, ob es sich um einen gültigen Benutzer handelt und ob er der richtigen Gruppe angehört.