Kategorie: TYPO3

Typo3: TSConfig global definieren

Jeder, der schon einmal ein Multi-Tree-Projekt in Typo3 hatte, kennt das Problem. TSConfig-Konfigurationen, wie z.B. die Einstellungen des RTE-Editors oder die Anpassungen der Content-Spalten, müssen für jeden Tree in die Page TSConfig eingetragen werden. Bei einer Änderung muss die TSConfig in jedem Tree aktualisiert werden. Ähnlich sieht es mit der User TSConfig aus. Hier kann zwar theoretisch eine BE-Benutzergruppe mit der Konfiguration erstellt werden. Aber diese muss dann auch erstmal jedem Benutzer zugewiesen werden. Wenn das bei einem Benutzer vergessen wird, erhält dieser die Konfiguration nicht.

Die Lösung dieses Problems liegt darin, die TSConfig in die Datei extTables.php auszulagern.

Für die User TSConfig sieht das so aus …

t3lib_extMgm::addUserTSConfig('
	# enter your
	# configuration
	# here
');

… und für die Page TSConfig so:

t3lib_extMgm::addPageTSConfig('
	# enter your
	# configuration
	# here
');

Alle hier eingetragenen TSConfig-Einstellungen sind in ganzen Typo3-Projekt gültig. Unabhängig vom Benutzer, von der Seite und vom Seitenbaum.

User-Bestätigung bevor Dateien gelöscht werden

Die Typo3-Extension „jm_gallery“ bietet eine umfangreiche Fotogalerie. Dazu gehört die Aufteilung in Kategorien, anlegen verschiedener Alben, eine Kommentarfunktion zu den Bildern und viele weitere tolle Features. Ein großer Vorteil dieser Extension ist, dass die Alben und Bilder mit einer AJAX-Oberfläche über das Frontend gepflegt werden können.

Somit kann ein Frontend-Login-Bereich eingerichtet werden, über den die Benutzer die Bilder komfortabel pflegen können und nicht den mühsamen (und bei dieser Extension etwas unübersichtlichen) Weg der Backend-Pflege gehen müssen. Die Benutzer können Kategorien anlegen, Bilder hinzufügen, Bilder löschen und auch ganze Kategorien wieder löschen. Und genau hier liegt ein kleines Problem: Löscht der Benutzer eine Kategorie, erscheint keine Sicherheitsabfrage und die Kategorie wird incl. aller Dateien sofort gelöscht. Dadurch kann durch einen einzigen unvorsichtigen Klick die vorherige mühsame Arbeit zunichte gemacht werden.

Mit folgender Anpassung am Template wird eine kurze und einfache JavaScript-Bestätigung vorgeschaltet, die den Benutzer noch einmal darauf hinweist, was geschieht und ob er das wirklich will.

Folgender Abschnitt im Template …

href="javascript:GalleryAdmin.deleteAlbum(###CATEGORY_UID###,###ALBUM_UID###);"

… muss durch diesen Code ersetzt werden:

href="javascript:askToDelete(###CATEGORY_UID###,###ALBUM_UID###);"

Und diese JavaScript-Funktion muss an geeigneter Position eingefügt werden:

/**
 * Ask the user before the album is deleted.
 */
function askToDelete(catID, albumID) {

	var askText = 'Soll das Album wirklich endgültig vom Server gelöscht
	               werden?\n\nDieser Vorgang kann nicht rückgängig
	               gemacht werden.';

	if(confirm(askText)) {
		GalleryAdmin.deleteAlbum(catID, albumID);
	}
}

Durch diese Änderung kann der Benutzer wie gewohnt die Bilder und Alben verwalten, wird aber vor dem Löschen eines Albums darauf hingewiesen, welche Folgen die Aktion haben wird und danach gefragt, ob er es wirklich tun will. Dieser eine Klick mehr stört wahrscheinlich niemanden wirklich, aber kann vor sehr viel Ärger, Problemen und Mehraufwand schützen.

Typo3: E-Mail-Adressen in Extension verschlüsseln

Typo3 bietet eine Funktionalität, um E-Mail-Adressen zu verschlüsseln und vor Spam zu schützen, doch ein Risiko stellen Extensions dar. Was, wenn in dieser E-Mail-Adressen im Klartext zu sehen sind? Mit wenig Code lässt sich die Adress-Verschlüsselung in die eigene Extension integrieren.

So, oder ähnlich, sieht das TypoScript aus das angibt, wie E-Mail-Adressen im Auftritt angezeigt werden sollen:

config.spamProtectEmailAddresses = 1
config.spamProtectEmailAddresses_atSubst = (at)
config.spamProtectEmailAddresses_lastDotSubst = (dot)

Mit der Funktion $this->cObj->getMailTo() kann dieser Schutz auch in die eigene Extension integriert werden.

Hier ein kleines Beispiel:

$email = $this->cObj->getMailTo($row['email'], $row['email']);
$content .= '<a href="'.$email[0].'">'.$email[1].'</a>';

Und schon wird die E-Mail-Adresse nach dem selbem Schema verfremdet, wie im Rest des Auftrittes und ist somit für automatische Adress-Sammler schwerer bis gar nicht zu finden. Die oben genannten Einstellungen gelten für die Extension, wie für den ganzen restlichen Auftritt.

Typo3-Contentelement „Tabelle“ mit sIFR-Headline

Für ein aktuelles Typo3-Projekt war es erforderlich, eine Tabelle mit folgenden Anforderungen zu erstellen: einfache Pflegbarkeit für jedermann, Tabellenzellen abwechselnd gestylt und Headlines in einer Schrift, die garantiert nicht auf jedem Rechner verfügbar ist.

Um das Problem mit der leichten Pflegbarkeit zu lösen, bot sich das Typo3-Contentelement „Tabelle“ an. Hier lässt sich leicht eine Tabelle aufbauen, ohne über HTML-Kenntnisse zu verfügen und auch ein Wizard wird angeboten, um die Erstellung noch weiter zu erleichtern.
Für den Redakteur ist hier nur wichtig, dass er die Option „Position der Kopfzeile“ auf den Wert „oben“ setzt.

Dadurch wird die erste Zeile von Typo3 nicht als normale Tabellenzeile an den Browser gegeben, sondern in folgendem Format:

<thead><th>...</th><th>...</th><th>...</th></thead>

Der Head-Bereich einer Tabelle kann mit CSS gesondert gestylt werden um ihn als Überschrift kenntlich zu machen.

Mit Hilfe von sIFR können in HTML-Seiten Überschriften in jeder beliebigen Schriftart dargestellt werden. Dazu benötigt der Client lediglich JavaScript und das Flash-Plugin.

Mein erster Versuch, die sIFR-Datei einzubinden sah so aus:

... sSelector:".contenttable thead th" ...

und das Ergebnis so:

Scheinbar kann sIFR die Breite der <th>-Elemente nicht korrekt auslesen und dadurch die Schrift in der eingebetteten SWF-Datei nicht in die richtige Größe bringen. Abhilfe dieses Problems schuf ein kleiner Trick:

Im TypoScript fügte ich diese Zeile ein, wodurch der Inhalt aller Tabellenzellen automatisch noch in ein <p>-Element gefasst werden.

tt_content.table.20.innerStdWrap.wrap = <p>|</p>

Der sIFR-Code wurde entsprechend angepasst

... sSelector:".contenttable thead p" ...

und das Resultat sah so aus:

Die Breite wurde korrekt erkannt, die Schriftgröße innerhalb der sIFR-Datei stimmte, aber aufgrund eines anderen Styles hat das <p>-Element einen Abstand nach unten, der hier in der Tabelle nicht erwünscht ist.

Also wurde das <p>-Element durch ein <div>-Element ersetzt. Sowohl im TypoScript

tt_content.table.20.innerStdWrap.wrap = <div>|</div>

als auch im sIFR-Aufruf

... sSelector:".contenttable thead div" ...

Wodurch das Ergebnis schließlich so war, wie vom Kunden gewünscht:

Die weitaus geringere Herausforderung war die abwechselnde Hintergrundfarbe der Tabellenzeilen.

Die Zeilen werden von Typo3 schon automatisch abwechselnd mit den CSS-Klassen tr-odd bzw. tr-even versehen. Somit reichen wenige Zeilen in der CSS-Definition, um die abwechselnde Hintergrundfarbe zu erzeugen:

tr.tr-odd td { background-color: #EBEBEB; }
tr.tr-even td { background-color: #E1E1E1; }

Typo3-Update: Sicherheit und Kompatibilität

Selbstverständlich ist es immer empfehlenswert, die aktuellsten Typo3-Updates zu installieren. Dadurch werden bekannte Sicherheitslöcher geschlossen, die Performance erhöht, es gibt hin und wieder neue Features und auch die Usability wird optimiert. Trotzdem werden von vielen Admins die Updates nicht eingespielt. Dies geschieht oft aus Faulheit oder Bequemlichkeit, oft weil der Admin nicht ausreichend über Updates informiert ist und oft weil ein Projekt einfach vergessen wird. Anders könnte es jedoch ausnahmsweiße bei den aktuellen Typo3-Updates werden.

In dieser Woche hat die Mozilla Foundation die Version 3 des beliebten Browsers „Firefox“ veröffentlicht. Nach einer unvergleichbaren Marketingaktion wurden der Browser bereits jetzt über 8 Millionen mal herunter geladen. Es ist also davon auszugehen, dass der Browser schon bei vielen Benutzern im produktiven Einsatz ist.

Jedoch hat das Typo3-Backend von älteren Versionen Probleme mit dem Firefox 3 – oder anders herum. Jedenfalls funktionieren die Frames nicht mehr und eine Bedienung wird nahezu unmöglich. Dieses Problem wurde in den neusten Typo3-Versionen 4.0.9, 4.1.7 und 4.2.1 (Download hier) behoben und die Bedienung mit dem Firefox 3 funktioniert wieder.

So hat die Mozilla Foundation der Typo3-Community – wahrscheinlich unabsichtlich – einen großen Dienst erwießen und auch faule Administratoren werden früher oder später nicht um die Updates herum kommen.

Schriftdateien vor Download schützen

In einem anderen Beitrag wurde bereits erwähnt, dass es bei der Verwendung von Schriften zur Grafikerzeugung in Typo3 schnell zu einem Lizenzverstoß kommen kann.
Dass viele Typo3-Entwickler die für den GIFBUILDER benötigten Schriftdateien in den Ordner fileadmin/fonts legen, ist kein Zufall sondern hat durchaus seinen Sinn. Liegen diese Dateien in jenem Ordner, kann der Administrator sie wunderbar und bequem mit der Typo3-eigenen Filelist (dt. Dateiliste) verwalten, austauschen, updaten, etc. Aber wie bereits in oben verlinktem Beitrag erwähnt wurde, liegt die Datei dann praktisch für die ganze Welt zum Download bereit, was einen gravierenden Lizenzverstoß darstellt.
Um das zu verhindern, könnte man die Datei außerhalb des Web-Verzeichnisses abspeichern. Typo3 könnte die Schrift dann noch immer finden, aber der Download der Datei wäre nicht mehr möglich. Dieses Vorgehen hätte jedoch zwei deutliche Nachteile. Zum Einen wären die Font-Dateien nicht mehr über die Filelist sichtbar und pflegbar und zum Anderen müsste man sich bei einem Backup oder einem Umzug nicht nur um das Web-Verzeichnis kümmern, sondern auch immer an die extern liegenden Schriftdateien denken. Das würde sicherlich früher oder später einen Fehler und somit auch Ärger hervorrufen.
Eleganter wäre es also, die Schriftdateien weiterhin wie gewohnt innerhalb des Ordners fileadmin abzuspeichern. Aber wie kann man diese dann vor dem Download schützen. Die Lösung dafür ist eine kleine aber feine .htaccess-Datei. Mit solchen Dateien lassen sich auf Apache-Systemen individuelle Einstellungen für einzelne Verzeichnisse vornehmen.
Legt man folgende Dateien in den Ordner, in dem alle Schriftdateien liegen (z.B. fileadmin/fonts), ist der Zugriff von außerhalb gespert.

Order Deny,Allow
Deny from all

Auch der scheinbar komplizierte Fall, dass die Schriftdateien nicht in einem eigenen Ordner liegen, ist für die .htaccess-Datei kein Problem. Die Datei mit folgendem Inhalt könnte man z.B. direkt in den Ordner fileadmin legen und fortan wären alle Dateien mit der Endung .ttf die in diesem Verzeichnis oder einen Unterverzeichnis in beliebiger Tiefe liegen, von außen unerreichbar. Liegen Schriftdateien auch mit weiteren Endungen vor, muss die Datei dementsprechend angepasst werden.

<Files *.ttf>
Order Deny,Allow
Deny from all
</Files>

Das Tolle am Schutz der Dateien mittels .htaccess ist, dass diese von einem Web-Besucher über das http-Protokoll nicht erreichbar sind. Typo3 greift mit seinem GIFBUILDER jedoch nicht mit dem http-Protokoll auf die Datei zu, sondern nutzt dafür direkt das Dateisystem des Servers. Typo3 kann die Schriftdateien also weiterhin ungestört zum generieren von Grafiken nutzen, aber die Datei kann nicht herunter geladen werden.
Außerdem liegen die Schriften noch immer für den Typo3-Entwickler schön aufgeräumt in der Filelist.

Lizenzverstoß bei eingebetteten Schriften in TYPO3

Ein sehr nettes Feature in TYPO3 ist, dass direkt Schriften in Navigationen oder Headlines über die Grundfunktion „GIFBUILDER“ eingebettet werden können. TYPO3 generiert dann direkt mit der gewünschten Schrift eine Grafik. Hierzu muss die gewünschte Schrift auf den Webserver gelegt werden, dass TYPO3 direkt darauf zugreifen kann. In den meisten Fällen wird das von TYPO3 empfohlene Verzeichnis „/fileadmin/fonts/“ verwendet.
Zu den ganzen Vorteilen die TYPO3 mit dieser Funktion bietet, ist die Verleitung groß, unbewusst einen Lizenzverstoß zu begehen. Die wenigsten, die diese Funktion nutzen wissen, dass wenn in ein beliebiges Verzeichnis auf dem Server ein Schrift kopiert wird die in TYPO3 eingebunden wird, eine Verletzung der Lizenz- und Nutzungsbedingungen der Schriftanbieter zwangsläufig stattfindet. Ab dem Zeitpunkt, wo die Schrift auf den Webserver kopiert wird, ist sie für jeden, der die technische Voraussetzung hat, frei zum Download. Das ist natürlich nicht im Interesse der Schriftenanbieter. Zu Recht!

Grundsätzlich sollten Sie das Verzeichnis, in dem Sie die Schriften ablegen, mit einem HTACCSS Passwortschutz versehen. Dann ist gewährleistet, dass das Verzeichnis nur über eine Eingabe eines Passworts und Benutzername erreichbar ist. Das macht einen Zugriff doch eher unwahrscheinlich.

Linotype wehrt sich derzeit heftig mit Abmahnungen gegen solche Verstöße.

Links über Domains hinweg

Man sollte meinen, TYPO3 würde mit der Verwendung von config.typolinkCheckRootline wunderschöne Links über die verschiedenen Bäume und Domains generieren. Anders lautende Hinweise konnte ich auch in der TSRef nicht finden.
In der Praxis ärgerte mich TYPO3 jedoch an dieser Stelle, da der Sprachparameter nicht an den Link gehängt wurde und der User somit immer wieder auf der Standardsprache landete.

Die Lösung für das Problem war dann letzten Endes eine zusätzliche TypoScript-Konfiguration. Diese konnte ich jedoch nicht in der TSRef finden, sondern stolperte vielmehr nur nach langem Suchen im World Wide Web darüber. Seltsam. Aber jetzt geht’s und der User bleibt danke folgender zusätzlicher Zeile bei seiner Sprache:

config.typolinkEnableLinksAcrossDomains = 1

Eine Lösung, wie die Cross-Domain-Links auch von realurl geparst werden, habe ich jedoch noch nicht gefunden.