TYPO3@lisardo

fUm die Vorschau von Bildern in einer eigenen Extension in einer der zahlreichen Lightboxen zu präsentieren sind ein paar Schritte nötig. Zuerst das Typoscript: 

Dabei sorgt file.maxW für die Breite des Vorschaubildes und parameter.cObject.file.maxW für die Breite des Bildes in der Lightbox. Der Eintrag bei ATagParams variiert nach verwendeter Lightbox. Ich verwende hier die Colorbox, die eine Klasse mit dem Namen "lightbox" wünscht. 

Im PHP der Extension muss dieses Typoscript passend verwendet und ergänzt werden: 

Kein großer Aufwand mehr im PHP ... Man übernimmt sinnvollerweise zuerst die Konfiguration in eine Variable ($lConf) und erweitert dann diese Konfiguration mit $lConf['file'] um den Pfad auf das Bild (in der Regel wohl aus der DB ausgelesen). Der Rest ist optional – wobei der title natürlich noch sinnvoll ist, da er in der Lightbox gezeigt wird. 

Damit ist sichergestellt, dass sowohl die direkt gezeigten Vorschaubilder wie auch die größeren Bilder in der Lightbox eine vorgegebene Maximalgröße bekommen. Weitere Attribute können natürlich nach Belieben entweder im Typoscript oder im PHP hinzugefügt werden. 

tt_news verwendet die Typoscript-Funktion filelink für die Ausgabe der Dateien, die mit einem News-Artikel verbunden werden. An sich ist das ziemlich leistungsfähig und auch gut zu konfigurieren. Kleines Beispiel: 

Die verschiedenen Optionen sind im TSref zu finden. 

Leider fehlt eine entscheidende Möglichkeit, nämlich eigene Icons für die Dateien zu verwenden. In filelinks ist der Ordner, aus dem die Icons geladen werden, nämlich hart im PHP kodiert. Und zwar einschließlich der Pixelgröße der verwendeten Icons. 

ich habe viele Fragen dazu im Netz gefunden und auch ein paar Lösungsvorschläge, die aber alle nicht funktionieren - Kunststück, wenn der Ordner wirklich hart im PHP des Core drinsteht. Eine Möglichkeit gibt es aber doch: 

Das ist dreckig, funktioniert aber ... Habe ich hier gefunden: Changing appearance of tt_news file list icons (ganz unten). Die Zahl (78) muss angepasst werden an den wrap für das icon ... 

IF-Konstrutionen in Typoscript sind reichlich verzinkt und kosten viel Hirnschmalz, vor allem wenn mehrere Bedingungen miteinander verknüpft werden sollen. Mein Problem: 

Ein neu erstelltes Inhaltselement soll es ermöglichen, bequem und schnell einen Downloadlink mit einem Vorschau-Bild zu erstellen. Es soll folgende Features haben: 

• die Vorschau-Bilder sollen nebeneinander floaten
• die Vorschaubilder sollen unabhängig vom Frontend-User-Login zwar immer erscheinen, bei bei fehlendem Login oder falscher Benutzergruppe abgedimmt werden. 
• die Download-Links auf den Vorschaubildern sollen nur erscheinen, wenn der Besucher in einer bestimmten Frontend-Usergruppe ist
• zusätzlich soll der Redakteur mit einer Checkbox bestimmen können, dass ausnahmsweise der Downloadlink auch dann gezeigt wird, wenn der Besucher nicht eingeloggt ist. 

Das kann alles noch über Typoscript gelöst werden. Die Schritte: 

1. Extension erstellen, die tt_content um mehrere Felder erweitert
2. Die extTables.php so anpassen, dass im Backend die richtigen Felder gezeigt werden 
3. die Extension um ein Typoscript-Setup erweitern, das den Output vornimmt. 

Und darin ist die oben erwähnte IF-Konstruktion erforderlich: der Link wird gerendert, wenn der Besucher in der Usergruppe 10 ist ODER wenn eine Checkbox durch den Redakteur angeklickt wurde. 

Der wesentliche Teil des Typoscripts sieht so aus:

Eine OR-Verknüpfung geht am einfachsten über ein cObject. Das Ergebnis des gesamten cObjects wird true, wenn eine Zeile true wird. Man kann also auf diese Art beliebig viele Fehler mit OR verbinden. Etwas kniffliger ist es, wenn man auf einen bestimmten Wert prüfen will und nicht nur auf true oder false, weil in diesem Fall eine weitere IF-Konstruktion eingeschachtelt werden muss. 

Ganz am Schluss darf natürlich nicht vergessen werden, mit Hilfe der Extension naw_securedl und einer .htaccess-Datei im Uploads-Ordner der Extension die Downloads gegen Deeplinks abzusichern.  

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. 

Im RTE kann man horizontale Linien einfach mittels Blockstilen zur Verfügung stellen, die einem Absatz zugewiesen werden können. Diese Stile müssen allerdings vom Entwickler zur Verfügung gestellt werden. 

Dieser Absatz hat z. B. eine Linie oberhalb, die auf diese Art eingefügt wurde. 

Der RTE kann allerdings auch das HTML-Element <hr /> einsetzen, das unabhängig ist von den Blockelementen bzw. Absätzen.

Standardmäßig macht der RTE dabei leider einen Fehler: er packt die Linie in einen Absatz: <p><hr /></p>, was beim Validieren der Seite zu einem Fehler führt. Dieser Fehler stört allerdings die optische Darstellung nicht, wer also mit einem Validierungsfehler leben kann, muss nichts weiter unternehmen. 

Der Fehler kann eleminiert werden, wenn in das TypoScript-Template der Seite diese Zeilen eingefügt werden:

Leider hat das aber andere negative Konsequenzen. Wenn ich z. B. hier so eine Linie einfüge:

werden die folgenden Absätze nicht mehr richtig geparst. So werden z. B. in meinen Code-Snippets der <pre>-Tag nicht mehr korrekt von  tx-vjrtecodesnippets erkannt und geparst: 

lib.parseFunc_RTE.externalBlocks := addToList (hr)
lib.parseFunc_RTE.externalBlocks.hr.stripNL = 1

Ausserdem werden offensichtlich Links nicht mehr geparst. Das ganze ist ein Problem, das offenbar seit 2007 im Bugtracker steht, aber bis heute nicht wirklich gelöst wurde (hier sollte eigentlich ein Link stehen, der aber nicht geparst wird. Er folgt im nächsten Absatz, den ich in ein neues Inhaltselement packe.) 

Fazit:

Ich empfehle die Verwendung von Blockstilen wie ganz oben beschrieben. Wenn man unbedingt <hr /> verwenden muss, so sollte der Workaround gründlich getestet werden. Wenn – wie bei mir hier – die Fehler nicht gefixt werden können, dann muss man wohl oder übel mit dem Syntaxfehler des RTE leben. Wie gesagt: die Darstellung ist ja korrekt, es gefällt nur den Validatoren nicht.

Und hier ist der Link in den Bugtracker nochmals ...

[Update]
Für den Bug gibt es seit kurzem einen Fix im Bugtracker von Stanislas Rolland, der das Problem behebt. (Vielen Dank an Stanislas!)

Also Patch einspielen, oder aufs nächste Update von TYPO3 warten, dann wirds wohl dabei sein. 

[Update 2]

In Version 4.4.6 funktioniert es jetzt.