Mit folgender Konfigurations-Möglichkeiten im User TSconfig lässt sich der Upload im RTE-aktivieren:

options.uploadFieldsInTopOfEB = 1

Und diese Konfigurations-Option erlaubt es dem Benutzer dann sogar noch, auch direkt Ordner anzulegen, um die Uploads besser strukturieren zu können:

options.createFoldersInEB = 1

Sind beide Optionen gesetzt, erscheinen die Upload-Felder direkt im Dateiauswahl-Dialog des RTEs.

Funktionsweise von nc_staticfilecache

Die Extension generiert aus dynamisch erzeugten TYPO3-Seiten – vorausgesetzt, sie enthalten ausschließlich cachebare Elemente – statische HTML-Dokumente als exakte Kopien und legte diese auf dem Webserver ab. Voraussetzung dafür ist die Verwendung einer Extension, die TYPO3 um lesbare Pfade erweitert, wie z.B. realurl oder simulatestatic.

Durch eine Anpassung der mod_rewrite-Konfiguration wird dann bei jeden Seitenaufruf vom Webserver selbst geprüft, ob zu dieser Seite eine statische Variante gespeichert ist. Existiert diese statische Variante, wird diese direkt an den Client ausgeliefert, ohne dass TYPO3 ins Spiel kommt. Es muss kein PHP-Parser gestartet werden, kein TYPO3 geladen werden und keine Datenbankabfrage durchgeführt werden. Laut Eigenbeschreibung der Extension sind dazu Beschleunigungen bis zu 23000% möglich.

Um die Auslieferung von veraltetem Content zu verhindern, werden die statischen Dateien beim löschen des Frontend-Caches mit gelöscht. Darüber hinaus sollte auch noch ein Cron-Job eingerichtet werden, wie im Extension-Handbuch beschrieben. Dieser löscht die statischen HTML-Seiten automatisch nach ihrer definierten Lebensdauer. Diese Lebensdauer entspricht der im Backend eingestellten Cache-Dauer, die zu jeder Seite in den Seiteneigenschaften vorgenommen werden können.

TYPO3-Auftritt mit nc_staticfilecache beschleunigen

Der leichteste Schritt ist die Installation der Extension über den TYPO3-Extension-Manager. Anschließend ist im Modul “Web > Info” der neue Punkt “Statischer HTML Cache” verfügbar. Hier ist ersichtlich, welche Seiten gecached wurden bzw. warum einzelne Seiten nicht gecached wurden.

Die Meldung config.no_cache is true zeigt an, dass die komplette Seite nicht gecached werden kann. Das kann mehrere Gründe haben:

1. Caching in den Seiteneigenschaften deaktiviert
2. Caching im TypoScript deaktiviert (config.no_cache = 1)
3. eine Extension deaktiviert das Caching für diese Seite ($GLOBALS['TSFE']->set_no_cache())

Die Meldung page has INTincScript zeigt an, dass einzelne Elemente nicht gecached werden können. Das können z.B. Plugins sein, die als USER_INT anstatt als USER geladen werden oder TypoScript-Elemente, die vom Typ COA_INT anstatt vom Typ COA sind. Ein Hilfsmittel, um die INT-Elemente ausfindig machen zu können, ist der “TypoScript-Objekt-Browser”, der sich im Modul “Web > Template” einsehen lässt, sobald eine Seite im Seitenbaum ausgewählt wurde.
Ist ein INT-Objekt ausfindig gemacht, gilt es zu überlegen, ob sich das Caching für dieses Element nicht evtl. doch erlauben lässt. Ist dies der Fall, kann der Typ via TypoScript geändert werden:

	# noncacheable INT objects
plugin.user_myextension = USER_INT
lib.mytyposcriptobject = COA_INT

	# cacheable objects
plugin.user_myextension = USER
lib.mytyposcriptobject = COA

Nachdem die Extension installiert ist, und die Seiten als statische Kopien auf dem Webserver abgelegt werden, muss noch die mod_rewrite-Konfiguration angepasst werden. Eine Beispiel-Konfiguration dazu befindet sich in Extension-Handbuch. Diese muss aber je nach Serverumgebung und realurl- bzw. simulatestatic-Konfiguration noch angepasst werden.

Fazit

Durch einen geschickten Einsatz der Extension “nc_staticfilecache” lässt sich der TYPO3-Auftritt extrem beschleunigen und die Serverlast deutlich reduzieren. Voraussetzung dafür ist jedoch ein durchdachter Einsatz von nicht-cachebaren INT-Elementen, die es zu vermeiden gilt. Schließlich kann ein einziges Plugin, das nicht gecached werden darf, schon den kompletten Einsatz der Extension verhindern.

Die Extension “nc_staticfilecache” ist in ihrer aktuellsten Version über das Extension Repository erhältlich.

AJAX mit eID-Machanismus

Mit dem integrierten eID-Mechanismus von TYPO3 ist es möglich, eigene PHP-Scripte ohne großen Overhead aufzurufen. Instanziert wird dabei nur alles, was man unbedingt braucht oder will. Der Nachteil dabei ist jedoch, das viele interne TYPO3-Bordmittel nicht zur Verfügung stehen. So müssen z.B. für die Spracherkennung oder wenn TypoScript-Bedingungen beachtet werden sollen, komplizierte Workarounds integriert werden. Dadurch wird das anfänglich schlanke Script schnell aufgebläht und unübersichtlich. Und im schlimmsten Fall entstehen dadurch sogar Sicherheitslücken, beispielsweise dann wenn es dem Benutzer Möglich ist, über das AJAX-Backends Daten abzufragen für die er in seiner Benutzergruppe ggf. gar keine Berechtigung haben sollte.
Der eID-Mechanismus ist also meiner Meinung nach für einfache und unkomplizierte Abfragen geeignet. Kommen aber irgendwelche Bedingungen ins Spiel, von denen die Abfrage abhängig sein sollte, empfehle ich eine andere Herangehensweise.

AJAX mit eigenem Seiten-Typ

Wer schon einmal ein TYPO3-Projekt erstellt hat, kennt die Seiten-Typen vermutlich von der Druckansicht. Oftmals wird mit typeNum=98 ein Page-Objekt für die Druckansicht definiert, dass sich dann mit einem angehängten Parameter (z.B. http://www.example.com/index.php?id=1&type=98) aufrufen lässt und eine völlig andere Ansicht der Webseite offenbart.
Genau dieses Feature lässt sich auch nutzen, um ein z.B. ein eigenes Extension-Plugin mit einem definierten Seiten-Typ zu verknüpfen. Hier im Beispiel erzeugen wir mit myajax ein neues Objekt vom Typ PAGE. Mit typeNum = 789 wird dann eine alternative Typ-Nummer vergeben. Und nach ein paar Beispielkonfigurationen wird dann noch das Plugin als einziger Content eingebunden.

Unser Plugin ist dann direkt über http://www.example.de/index.php?id=23&L=1&type=789 erreichbar und liefert automatisch die korrekten Ergebnisse, abhänig vom gesetzten Sprachparameter, der gewählten Seite und den aktuellen Berechtigungen des Benutzers. (Die Parameter id und L im Beispiellink sind natürlich variabel und hier nur als Beispiel gesetzt.)

	# prepare alternative page type
myajax = PAGE
myajax.typeNum = 789
myajax.config {
	disableAllHeaderCode = 1
	additionalHeaders = Cache-Control: no-cache, must-revalidate, max-age=0|Expires: Mon, 2 Jan 2006 01:00:00 GMT|Pragma: no-cache
	xhtml_cleaning = 0
}
	# register plugin directly as page content
myajax.10 < plugin.user_myajaxplugin_pi1

Der Nachteil dieser Lösung ist, dass bei jeder Anfrage der komplette standardmäßige TYPO3-Overhead mitgeführt wird. Es ist also von Haus aus eher die etwas langsamere Variante im Vergleich zur oben genannten eID-Lösung.

Der enorme Vorteil hingegen ist jedoch, dass sich die AJAX-Serverfunktionalität exakt gleich zur normalen Seite verhält. Alle Spracheinstellungen, die Berechtigungen für irgendwelche Seiten, TypoScript-Conditions, etc. haben auch direkten Einfluss auf die AJAX-Funktionalität und können von einem Angreifer nicht mit einfachen Parameter-Änderungen in der Adresse ausgehebelt werden.

Fazit

Grundsätzlich würde ich keine der beiden Varianten als “besser” oder “schlechter” bezeichnen. Für einfache AJAX-Abfragen ohne Einschränkungen wie z.B. Sprache, Berechtigung, etc. würde ich die kleinere Schlankere Variante mit dem eID-Mechanismus wählen. Sobald aber Inhalte nur für eine bestimmte Besuchergruppe sichtbar sein sollen, oder in verschiedenen Sprachen verfügbar, rate ich zweifellos zur Variante mit dem eigenen Seiten-Typ.

In den Seiteneigenschaften verbirgt sich unter dem Reiter “Optionen” die kleine unscheinbare Checkbox “Ist Anfang der Web-Site” (engl.: “Is root of website“). Diese Checkbox muss auf der Root-Page wirklich gesetzt sein – und natürlich die Root-Page auch in der realurl-Konfigurationsdatei korrekt gesetzt sein – uns schon klappt der Seitenübergreifende Link auch wunderschön mit realurl.

Tipp: Wenn Ihr die Checkbox “Ist Anfang der Web-Site” nicht sehen könnt, blendet einfach die zweite Optionspalette ein.

Mit einem kleinen Eingriff in die .htaccess-Datei lässt sich der SWF-Uploader aber auch zum Laufen bringen, ohne den Passwort-Schutz vom ganzen Projekt zu nehmen. Dazu müssen einfach folgende Zeilen in die .htaccess-Datei eingefügt werden.

<Files ajax.php>
Allow from any
Satisfy any
</Files>

Die erste und vierte Zeile bewirken, dass die Anweisung nur für Dateien mit dem Namen ajax.php gelten soll. Zeile 2 besagt, dass ein Zugriff von jeder IP-Adresse aus möglich ist und Zeile 3 bewirkt, dass entweder die User-Authentifizierung via Passwort oder die IP-Adresse des Besuchers stimmen muss. Und da der Besucher jede beliebige IP-Adresse besitzen darf (Zeile 2), ist die Zugriffsbeschränkung für die Datei ajax.php aufgehoben und der SWF-Uploader funktioniert wieder tadellos.

Zu den offensichtlich erkennbaren neuen Features gehören z.B. der Papierkorb (Recylcer), Planer (Scheduler) oder die Übersicht der kürzlich verwendeten Dokumente. Doch auch die zunächst unsichtbaren Features versprechen Erleichterungen und Anpassbarkeit des TYPO3-Projekts. Eine großartige Neuerung ist wohl der “New Content Element Wizard”. Dieser ist jetzt Seite für Seite via pageTS konfigurierbar. Welche Möglichkeiten sich hierbei bieten, beschreibt Steffen Kamper in seinem Artikel auf buzz.typo3.org.

Selbstverständlich kann man dazu in die Datenbank gehen und Cache-Tabelle manuell leeren – aber was wenn ein Redakteur ohne Datenbankzugriff den Cache leeren will oder muss? TYPO3 bietet im Backend einen Button zum einfachen Löschen aller Caches. Und genau dort bietet sich eine Möglichkeit, unsere Cache-Tabelle mit leeren zu lassen.

Beim Aufruf von “Alle Caches löschen” wird (mit Einschränkungen, auf die ich gleich eingehen werde) alle Tabellen geleert, die im globalen PHP-Array $TYPO3_CONF_VARS['SC_OPTIONS']['t3lib/class.t3lib_tcemain.php']['clearAllCache_additionalTables'] registriert sind. Um also Cache-Tabellen der eigenen Extension mit leeren zu lassen, könnte die Datei ext_localconf.php so aussehen:

<?php
$TYPO3_CONF_VARS['SC_OPTIONS']['t3lib/class.t3lib_tcemain.php']['clearAllCache_additionalTables']['user_mydemoextension_pdfcache'] = 'user_mydemoextension_pdfcache';
$TYPO3_CONF_VARS['SC_OPTIONS']['t3lib/class.t3lib_tcemain.php']['clearAllCache_additionalTables']['user_mydemoextension_xlscache'] = 'user_mydemoextension_xlscache';
?>

Damit werden die beiden Tabellen “user_mydemoextension_pdfcache” und “user_mydemoextension_xlscache” automatisch bei Klick auf “Alle Caches löschen” mit geleert. Die Einschränkung, die ich oben angedeutet habe, ist die Syntax der Tabellennamen. Diese müssen mit mindestens einem alphanumerischen Zeichen beginnen und mindestens einen Unterstrich enthalten, was aber sowieso der TYPO3-Syntax für Extension-Tabellen entspricht (z.B. “tx_myextensiontable”,”user_myextensiontable”) – und darüber hinaus mit der Zeichenkette “cache” enden. Eine Tabelle mit Namen “user_mydemoextension_pdf” kann also nicht automatisch mit dem TYPO3-Cache mit geleert werden, eine Tabelle mit Namen “user_mydemoextension_pdfcache” dagegen schon.

TYPO3 4.3-RC1 kann wie immer von der TYPO3-Downloadseite herunter geladen werden. Eine Liste von Änderungen und Features kann hier eingesehen werden.

Eine ausführliche Übersicht, welche Hooks einen Eingriff zu welchem Zeitpunkt des Frontendrenderings ermöglichen, gibt es in diesem PDF-Dokument. Ich habe mich für meine Extension für den Hook contentPostProc-output entschieden.

Die Datei ext_localconf.php sieht wie folgt aus:

<?php
if (!defined ('TYPO3_MODE')) {
	die ('Access denied.');
}

// hook
$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tslib/class.tslib_fe.php']['contentPostProc-output']['user_myext'] = 'EXT:user_myext/class.user_myext_hook.php:&user_myext_hook->contentPostProc_output';
?>

Mein Versuch, die Angabe zum Hookaufruf in die Datei ext_tables.php zu schreiben, scheiterte kläglich. Diese Angabe muss also scheinbar zwingend in der Datei ext_localconf.php stehen.

Die Datei class.user_myext_hook.php könnte dann wie folgt aussehen:

<?php
class user_myext_hook {

	function contentPostProc_output(&$params) {
		$feobj = &$params['pObj'];
		str_replace('foo', 'bar', $feobj->content);
	}
}
?>

Die Datei ENABLE_INSTALL_TOOL, welche benötigt wird um das Install-Tool zu aktivieren, wird von TYPO3 automatisch nach 1 Stunde gelöscht. So lange man mit dem Install-Tool arbeitet, wird die Dateizeit immer wieder aktualisiert, liegt die Dateizeit jedoch über eine Stunde zurück, wird die Datei automatisch gelöscht und das Install-Tool ist deaktiviert.

Für die Sicherheit des TYPO3-Auftrittes ist das ein enormer Sicherheitsvorteil, da vergessene Install-Tools automatisch unbrauchbar werden und somit keine Angriffsflächen mehr darstellen. Für die Entwicklung wäre das jedoch eher lästig, da man evtl. immer wieder Änderungen vornehmen möchte und das immerwährende automatische Löschen der Datei eher lästig wäre.

Doch die neue Version bringt für Administratoren, die ein deaktiviertes Install-Tool aktivieren möchten – egal ob Entwicklungs-Auftritt oder Live-Auftritt – genau das richtige Feature mit. Die Aktivierung kann von einem Admin aus dem Backend vorgenommen werden.

Das neue Feature verbirgt sich hinter “Benutzerwerkzeuge > Benutzerenistellungen”. Hier wurde ein Button integriert, mit dem der Administrator die Datei ENABLE_INSTALL_TOOL aktivieren oder deaktivieren kann.

Damit mit diesem neuen Feature kein Unfug angestellt wird, steht es selbstverständlich nur Administratoren zur Verfügung. Bei normalen Backend-Usern ist der Button zum erzeugen/löschen der Datei selbstverständlich nicht sichtbar:

Ich finde diese Änderungen wirklich sinnvoll und freue mich darüber. Erstens muss ich nicht mehr unbedingt daran denken beim Launch eines Projektes die Sicherungsdatei zu entfernen. Zweitens werden dadurch TYPO3-Projekte in aller Welt, die von unbedarften Administratoren betreut werden, deutlich sicherer. Und drittens kann ich das Install-Tool mit wenigen klicks aktivieren, wenn ich es brauche und muss nicht den umständlichen Weg über FTP oder SSH gehen, um die ENABLE_INSTALL_TOOL-Datei anzulegen.