TYPO3@lisardo

Mit less kann die Entwicklung von umfangreichen CSS-Strukturen vereinfacht werden: Es ermöglicht den Variablen, Operationen und Funktionen innerhalb einer CSS-Datei. So können zum Beispiel zu Beginn der CSS-Datei Farben, Maße und andere einheitliche Elemente definiert und anschließend als Variablen (oder eigentlich eher als Konstanten) verwendet werden. Mit Hilfe von »nested rules« kann man (wie im Typoscript) auf die lästigen Selektoren verzichten und statt dessen die CSS-Regeln einfach ineinander verschachteln. Und vieles mehr – bitte einfach auf der Originalseite nachlesen, es gibt da eine gute Dokumentation aller Techniken. 

Obwohl mich less fasziniert, seit ich es zum ersten Mal gesehen habe (was für eine Zeitersparnis beim Entwickeln!) setze ich es bisher nicht ein, da die less-Dateien natürlich irgendwie aufbereitet werden müssen, bevor der Browser sie interpretieren kann. Das funktioniert entweder direkt im Bowser über JavaScript oder serverseitig über ein Ruby-Skript.

Genauer erklärt ist das Ganze hier: less: The dynamic stylesheet language. 

Nun ist Ruby nicht auf allen Servern installiert und der Einsatz im Browser über JavaScript schmeckt mir auch nicht. Also war das für mich bisher ein interessanter Ansatz, aber mehr auch nicht. Bis mir das hier untergekommen ist: less.app for Mac OS X. Die App funktioniert so: ich versehe meine CSS-Datei mit der Endung .less und arbeite darin mit den less-Befehlen, wie üblich in Textmate. Vorher übergebe ich den ganzen Prohekt-Ordner an die less-App, teile der App mit, in welchen Ordner die CSS-Dateien kompiliert werden sollen, und jedes Mal wenn ich jetzt die less-Datei speichere, wird die CSS-Datei kompiliert, auf Wunsch auf minifiziert. Da die Datei geparst wird, werden dabei auch gleich noch alle kleinen Syntaxfehler gefunden ... Schöner gehts nicht; das wird in Zukunft verwendet!

Auf der Seite gibts ein kurzes Video, das den Einsatz erklärt. 

Weiterführende Links

• less: The dynamic stylesheet language
• less.app for Mac OS
• Less.app for Windows (Sort of)
• Less Framework 4

Ich hatte die letzten Tage wieder lausige Probleme mit einer TYPO3-Installation, deren Datenbank-Tabellen in latin1 kodiert waren (DEFAULT CHARSET=latin und Kollation latin1_swedish_ci), in denen sich aber utf8-Daten befinden. Wenn man den Dump auf die übliche Art erstellt - oder auch z. B. über phpMyAdmin - erhält man beim Wiedereinspielen Umlautprobleme dieser Art: Ã¶ für ö. Das passiert, weil utf8-Daten beim Dumpen nochmals nach utf8 kodiert werden ... 

Dieser Müll passiert immer dann, wenn die Tabellen in MySQL als latin angelegt wurden (DEFAULT CHARSET=latin, meist noch in MySQL 3.x) und auch über eine Datenverbindung mit SET NAMES latin1 beschickt wurden (weil das der Standard in php war), in TYPO3 aber forceCharset =utf-8 eingestellt wurde (eben ohne gleichzeitig setDBinit auf "SET NAMES utf8" zu setzen).

Damit konnte man mit einem normal installierten MySQL 3.x sehr einfach erreichen, dass TYPO3 die Daten auf der Webseite selbst als utf8 präsentiert und sie auch so in den Tabellen abspeichert - leider aber in latin-kodierten Tabellen und über eine latin-Verbindung. Die Konsequenz ist, dass MySQL der Meinung ist, dass es latin-Daten in den Tabellen hat, und deshalb beim Erstellen eines Dumps die Daten dann ganz folgerichtig nach utf8 kodiert. Da die Daten aber leider schon in utf8 sind erhalten wir Datenmüll. 

In etwa war mir schon klar, was passiert und warum, nur eine saubere Lösung wußte ich keine. Eine wirklich gute Beschreibung des Problems (und vor allem praktikable Lösungswege!!) habe ich gerade jetzt in einem richtig guten Artikel von Kristian Köhntopp gefunden: FAQ: Mein mysqldump zerstört meine Umlaute. 

Lesebefehl für alle, die sich mit derartig verkorksten TYPO3-Installationen rumschlagen müssen. Seine Regel am Schluss kann ich nur dringend unterstreichen: 

»Lüge die Datenbank nicht an. Wenn Du SET NAMES latin1 eingestellt hast, sende latin1. Wenn Du SET NAMES utf8 eingestellt hast, sende utf8.« 

Also: $TYPO3_CONF_VARS['BE']['forceCharset'] = 'utf-8' erfordert zwingend auch $TYPO3_CONF_VARS['SYS']['setDBinit'] = 'SET NAMES utf8;' sonst gibts Datenmüll.  

Nachtrag

Ich habe gerade wieder so eine Installation in den Fingern :-( Aber mit der Lösung von Köhntopp klappt es bei mir, etwa in der Art: 

Ich habe gestern das Heise-Skript »socialshareprivacy« (siehe mehr dazu in meinem Artikel bzw. auf der Originalseite von Heise) in eine TYPO3-Extension eingebaut und ins TER hochgeladen (Downloadlink). Sie heißt einfach socialshareprivacy. Sie ist so aufgebaut, dass

• bei Neuerungen im Heise-Skript das Skript einfach in der Extension ausgetauscht werden kann
• notfalls auch über Typoscript eine externe Variante eingebunden werden kann
• das verwendete jQuery entweder automatisch durch die Extension eingebunden wird (default) oder ein bereits vorhandenes verwendet wird (Konfiguration im Extension Manager). 
• praktisch alle Konfigurationsmöglichkeiten des Originalskripts über Typoscript möglich sind. 

Zu beachten ist, dass das Skript von Heise nur eine Instanz pro Seite erlaubt, die Extension kann also nur einmal pro Seite eingebunden werden. 

Installation: 

Die Installation ist simpel: einfach im Extension Manager runterladen, installieren und danach zwei Einstellungen tätigen: die Facebook APP-ID eintragen und anklicken, ob jQuery aus der Extension geladen werden soll oder nicht. 

Facebook APP-Id: 

Eine Anleitung wie man an diese ID kommt ist hier zu finden: Hinweis zur Facebook App-ID

Einbinden in eine einzelne Seite: 

Das Plugin wird in die Seite eingebunden wie alle anderen Plugins: einfach als Inhaltselement. Es gibt nichts zu konfigurieren, einbinden reicht. 

Einbinden ins Template: 

Das geht am besten über Typoscript: 

Im klassischen Template-Stil: 

MARKER < plugin.tx_socialshareprivacy_pi1

oder über TemplaVoila: 

lib.myplaceholder < plugin.tx_socialshareprivacy_pi1

Typoscript-Konfiguration: 

In der Extension-Dokumentation ist keine genaue Beschreibung aller Optionen, aber man kann sich einfach die ext_typoscript_setup.txt vornehmen, dort sind alle Optionen mit Beispielinhalten drin. Eine genaue Beschreibung der einzelnen Optionen ist auch auf der Heise-Seite zu finden. Man kann sie sogar von dort entnehmen und nach folgenden Regeln in sein Setup schreiben: 

1. Allgemeine Optionen: 

plugin.tx_socialshareprivacy_pi1.info_link = 

etc. 

2. Facebook-Optionen: 

plugin.tx_socialshareprivacy_pi1.services.facebook.status = on

etc. 

3. Twitter und Google+: 

plugin.tx_socialshareprivacy_pi1.services.twitter.___

plugin.tx_socialshareprivacy_pi1.services.gplus.___

etc. 

Textausgaben

Ich habe die Textausgaben für die Popups nicht ins Typoscript verlegt sondern in eigene Language-Dateien, um eine einfache Mehrsprachigkeit zu ermöglichen (auch wenn das in dem Fall schlicht Quatsch ist ... sehr deutsch, diese Angelegenheit). So können die Texte aber auch einfach über Typoscript geändert werden:

plugin.tx_socialshareprivacy_pi1._LOCAL_LANG.de.txt_help = 

etc. 

Fehler und Verbesserungsvorschläge: 

Bitte nicht einfach behalten sondern an mich senden, entweder per E-Mail oder über das Kontatkformular. 

Update

Die Extension ist ab Montag, 24.12.2012 in Version 1.2.1 im TER und jetzt kompatibel zu TYPO3 4.5 bis 4.7 und 6.0. 

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 ...