Auswahl- und Dateifelder im TYPO3-Backend mitwachsen lassen

Eigene Extensions lassen sich schnell mit dem Extension Kickstarter erstellen. Dabei lassen sich die Feldkonfigurationen schnell zusammen klicken und die entsprechende Tabellen-Konfiguration (TCA) wird automatisch erstellt. Allerdings sind über den Kickstarter nicht alle theoretisch verfügbaren Einstellungen auswählbar. Will man z.B. ein automatisch mit der Anzahl der Inhalte mitwachsendes Feld, muss man manuell nachhelfen.

Anpassen eigener Extensions

Ein Ausschnitt der Tabellen-Konfigurations-Datei tca.php, die mit dem Kickstarter erstellt wurde, könnte beispielsweise so aussehen:

$TCA['tx_myextension_table1'] = array (
	'columns' => array (
		'related' => array (
			'exclude' => 1,
			'label' => 'LLL:EXT:z7_ideaskgf/locallang_db.xml:tx_myextension_table1.related',
			'config' => array (
				'type' => 'select',
				'foreign_table' => 'tx_myextension_table2',
				'size' => 5,
				'minitems' => 0,
				'maxitems' => 100,
			)
		),
	)
);

Dabei wurde als Größe im Kickstarter der Wert 5 angegeben und als Anzahl der erlaubten Inhalte der Wert 100. Mit dieser Konfiguration können 100 Elemente ausgewählt werden, die Feldgröße bleibt jedoch bei einer Höhe von fünf Einträgen bestehen. Werden mehr als diese fünf Einträge gewählt, bleibt die Höhe trotzdem fix und die Auswahlbox erhält eine Scrollleiste.

Dieses Verhalten ist natürlich völlig in Ordnung und kann durchaus Sinn machen. In anderen Fällen kann es aber besser sein, die Auswahlbox an die Anzahl der Einträge anzupassen, um somit ohne Scrollleiste sofort alle gewählten Elemente sichtbar zu machen. Das lässt sich mit der Konfigurations-Option autoSizeMax bewerkstelligen. Diese wird in die Konfiguration des Tabellefeldes eingetragen und mit dem gewünschten Wert versehen:

$TCA['tx_myextension_table1'] = array (
	'columns' => array (
		'related' => array (
			'exclude' => 1,
			'label' => 'LLL:EXT:z7_ideaskgf/locallang_db.xml:tx_myextension_table1.related',
			'config' => array (
				'type' => 'select',
				'foreign_table' => 'tx_myextension_table2',
				'size' => 5,
				'minitems' => 0,
				'maxitems' => 100,
				'autoSizeMax' => 100,	// neu eingefügt
			)
		),
	)
);

Der Wert kann zwar beliebig gesetzt werden, er macht allerdings nur Sinn wenn er höher ist, als der bei size gesetzte Wert. Außerdem macht es Sinn, den Wert identisch mit maxitems zu setzen.

Anpassen fremder Extensions

Selbstverständlich kann diese TCA-Einstellung nicht nur auf eigene Extensions angewandt werden. Es ist auch völlig irrelevant, ob eine Extension mit dem Extension Kickstarter erstellt wurde oder nicht. Die autoSizeMax-Option kann für jedes Feld hinterlegt werden.

Dazu müssen folgende einfache Zeilen in die Datei typo3conf/extTables.php eingetragen werden. Tabellen- und Feldname, sowie der autoSizeMax-Wert sind natürlich individuell anzupassen.

t3lib_div::loadTCA('tablename');
$GLOBALS['TCA']['tablename']['columns']['fieldname']['config']['autoSizeMax'] = 20;

Grid View im TYPO3-Backend

Ende Januar wurde TYPO3 Version 4.5 veröffentlicht. Diese neue Version trägt nicht nur erstmals den Titel LTS im Namen, sondern bringt auch einige nette neue Features mit. Eines davon ist „Grid View“ – damit lassen sich die bisherigen Inhaltsspalten im Backend beliebig anordnen, wodurch die Inhaltspflege erheblich vereinfacht wird. Schließlich befinden sich die Content-Elemente im Backend an den gleichen Positionen wie im Frontend.

Diverse Hintergrundinformationen zum neuen Feature findet man in der offiziellen TYPO3-News. Dort sind auch einige Screenshots zu sehen, wie das Feature in der Praxis eingesetzt werden kann.

Grid-View-Komposition anlegen

Die Kompositionen lassen sich kinderleicht anlegen, mann muss nur wissen wo man sie findet:

1. Backend-Modul „Liste“
2. Neuen Datensatz anlegen
3. Typ „Backend-Layout“

Die Konfiguration kann man dann entweder von Hand erzeugen oder den komfortablen Wizzard benutzen, der sich per Klick auf das „Assistent“-Symbol öffnen lässt.

Grid-View einer Seite zuweisen

Die erstellten Grid-View-Einstellungen lassen sich über die Seiteneigenschaften im Reiter „Erscheinungsbild“ zuweisen. Man hat dabei die Möglichkeit, das Grid nur für die aktuelle Seite zu aktivieren, oder für alle Unterseiten.

Flash-Messages in TYPO3-Backend

Seit einiger Zeit ist es möglich, dem BE-User über so genannte „Flash-Messages“ Feedback zu geben. Dieses Feature lässt sich auch kinderleicht in die eigene Extension integrieren.

Quelle: François Suter, http://buzz.typo3.org/

François Suter erklärt hier in seinem Blog-Beitrag auf buzz.typo3.org, wie sich das Feature integrieren lässt. Die Verwendung läuft dabei recht simpel ab:

  1. Eine Message wird als neues Objekt der Klasse t3lib_FlashMessage angelegt.
  2. Die Message wird der Message-Queue hinzugefügt.
  3. Das Anzeigen der Nachricht erledigt TYPO3 ganz von selbst.

In der Realität könnte Schritt 1 und 2 dann so aussehen:

$msg = t3lib_div::makeInstance('t3lib_FlashMessage', 'Message-Text', 'Title', t3lib_FlashMessage::WARNING);
t3lib_FlashMessageQueue::addMessage($msg);

Zur Einstufung der Meldung stehen die Klassen-Konstanten t3lib_FlashMessage::INFO, t3lib_FlashMessage::OK, t3lib_FlashMessage::WARNING und t3lib_FlashMessage::ERROR zur Verfügung.

Datei-Felder im Backend konfigurieren

In einem älteren Beitrag habe ich bereits erklärt, wie man die Datei-Felder im RTE konfigurieren kann, um ggf. den direkten Upload zu verbieten oder zu erlauben. Hier soll es darum gehen, wie man das Verhalten von allgemeinen Datei-Feldern im Backend steuern kann. Das betrifft sowohl Content-Elemente als auch Listen-Elemente.

Direkten Upload deaktivieren

Grundsätzlich kann jeder User selbst entscheiden, ob er direkte Uploads für Datei-Felder haben möchte oder nicht. Dazu gibt es in „Benutzerwerkzeuge > Einstellungen > Bearbeiten und erweiterte Funktionen“ die Einstellung „Hochladen von Dateien direkt im Web-Modul„. Voraussetzung hierfür ist nur, dass der Backend-Benutzer die entsprechenden Rechte hat, um das „Einstellungen„-Modul zu sehen. Die hier vorgenommene Einstellung betrifft für den jeweiligen Benutzer alle Datei-Felder im Backend.

Darüber hinaus kann die Einstellung dieses Feldes auch vom Administrator vorgegeben werden, so dass der Backend-Benutzer nicht mehr selbst darüber entscheiden darf ob er das Upload-Feld nutzen möchte oder nicht. Einstellbar ist folgende Option via „User TSconfig“:

# disable direct upload
setup.override.edit_docModuleUpload = 0

# enable direct upload
setup.override.edit_docModuleUpload = 1

Selbstverständlich kann der Wert im TSconfig einzelner Benutzer, einzelner Gruppen oder auch global gesetzt werden.


Upload aktiviert


Upload deaktiviert

Fileadmin-Browser deaktivieren

Auch die Möglichkeit, den Fileadmin zu durchstöbern kann deaktiviert werden. Allerdings geschieht das hier nicht auf der Benutzerebene, sondern pro Feld für alle Benutzer. Die Einstellung hierzu kann über das $TCA vorgenommen werden.

$GLOBALS['TCA']['tx_z7zerosevenhead_item']['columns']['image']['config']['disable_controls'] = 'browser';


deaktivierter Fileadmin-Browser

„Vorhandene Dateien“-Liste deaktivieren

Ebenso wie der Fileadmin-Browser lässt sich auch die Liste der vorhandenen Dateien entfernen. Der Nachteil dabei ist allerdings, dass dann auch gepflegte Bilder nicht mehr entfernt werden können. Aber evtl. hat ja sogar das in manchen Anwendungsszenarien seinen Sinn.

$GLOBALS['TCA']['tx_z7zerosevenhead_item']['columns']['image']['config']['disable_controls'] = 'list';


deaktivierte Liste

Mehrere Kontroll-Elemente ausblenden

Grundsätzlich kann disable_controls als kommaseparierte Liste gepflegt werden. Da jedoch die Option list auch gleichzeitig den Fileadmin-Browser deaktiviert, macht das evtl. wenig Sinn. Soviel also nur noch als allgemeine Anmerkung der Vollständigkeit halber.

$GLOBALS['TCA']['tx_z7zerosevenhead_item']['columns']['image']['config']['disable_controls'] = 'list,browser';

Seite verbergen, wenn keine Übersetzung für die aktuelle Sprache vorhanden ist

Bei mehrsprachigen TYPO3-Projekten kann es manchmal passieren, dass für einige Seiten keine Übersetzungen vorliegen. Beispielsweise kann ein mittelständisches Unternehmen aus Deutschland durchaus einen internationalisierten Webauftritt besitzen, aber Stellenausschreibungen könnten durchaus nur in Deutsch vorhanden sein. In einem solchen Fall wäre es sinnvoll, wenn eine Seite ohne Inhalt erst gar nicht in der Navigation angezeigt wird.

Für dieses Szenario bietet TYPO3 bereits standardmäßig die Einstellung „Seite verbergen, wenn keine Übersetzung für die aktuelle Sprache vorhanden ist“ (engl. „Hide page if no translation for current language exists“) in den Seiteneigenschaften einer jeden Seite.

Um diese Option bei allen neuen Seiten automatisch zu setzen, kann folgende Zeile in das User TSconfig eingetragen werden.

# 1 = erste Option
# 2 = zweite Option
# 3 = beide Optionen
TCAdefaults.pages.l18n_cfg = 2

Das kann je nach Bedarf selbstverständlich entweder pro Backend-Benutzer oder Backend-Benutzergruppe, oder aber auch global in der Datei typo3conf/extTables.php erledigt werden.

Darüber hinaus gibt es Install-Tool die Option $TYPO3_CONF_VARS['FE']['hidePagesIfNotTranslatedByDefault']. Setzt man diese, wird das Standard-Verhalten von TYPO3 umgekehrt. Nicht-übersetzte Seiten sind ab sofort nicht sichtbar und auch die Beschriftung der Checkbox hat sich in „Seite anzeigen, auch wenn keine Übersetzung vorhanden ist“ (engl. „Show page even if no translation exists“) geändert.

Will man den aktuellen Wert der Spracheinstellungen in einer Extension abfragen, bietet sich dazu die Funktion t3lib_div::hideIfNotTranslated() an. Diese wertet den Wert aus den Seiteneigenschaften abhängig von den Einstellungen im Install-Tool aus und gibt einen bool’schen Wert zurück ob die Seite versteckt sein soll wenn sie nicht übersetzt ist.

Integer-Feld durch Selectbox ersetzen

TYPO3 bietet im Backend einige Felder als normale Integerfelder an, in die nahezu beliebige Werte eingetragen werden können. Zwar gibt es die Möglichkeit über das $TCA den Wertebereich zu beschränken. Allerdings sind dann in diesem Wertebereich noch immer alle Eingaben möglich. Was ist jedoch, wenn man z.B. einem Redakteur für eine Bildbreite nur eine Hand voll unterschiedlicher Werte geben will?

Stellen wir uns vor, Sie haben für ein Webseiten-Layout mühsam ein Raster ausgearbeitet, in das sich auch die Bilder der Content-Elemente „Bilder“ oder „Text mit Bild“ einfügen sollen. Auf der anderne Seite haben Sie einen oder mehrere Backend-Redakteure, die mit möglichst wenig Know-How die Inhalte der Webseite pflegen sollen. Eine Lösung wäre hier, den Wert des Feldes „Bildbreite“ standardmäßig auf einen zum Raster passenden Wert zu setzen und das Feld für die Backend-Redakteure komplett auszublenden. Was tun Sie dann aber, wenn in einem Fall ein Diagramm über die ganze Breite des Inhalts eingeblendet werden soll und in einem anderen Fall ein Porträt einer Person schmal neben dem Text stehen soll? In unserem aktuellen Szenario müsste ein Backend-Benutzer mit weiterführenden Rechten, wie z.B. ein Administrator die Bildbreite anpassen.

Dabei kann die Lösung so komfortabel sein. TYPO3 erlaubt es, die Konfiguration der Felder so zu ändern, dass aus einem Integer-Feld mit freier Werteeingabe eine Selectbox wird. Darin können Sie als Administrator dann jeden Wert explizit erlauben und mit einem kurzen erklärenden Text versehen. Im Beispiel des Feldes „Bildbreite“ der Content-Elemente könnte eine Konfiguration in etwa so aussehen:

t3lib_div::loadTCA('tt_content');
$TCA['tt_content']['columns']['imagewidth']['config'] = array(
    'type' => 'select',
    'items' => array(
        array(
            'Left column, full width (550px)',
            '550',
        ),
        array(
            'Right column, full width (256px)',
            '256',
        ),
        array(
            'Right column, small width (92px)',
            '92',
        ),
    ),
);

Datei-Upload direkt im RTE

Der Rich-Text-Editor (RTE) in TYPO3 bietet dem Redakteur die Möglichkeit, Bilder einzubinden und auf Dateien zu verlinken. Dabei kann der Administrator definieren, ob der Redakteur diese Dateien auch gleich im RTE hochladen darf, oder ob er evtl. nur Dateien benutzen darf, die zuvor schon in das fileadmin-Verzeichnis geladen wurden.

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.

Empfehlung TYPO3-Extension: nc_staticfilecache

TYPO3 ist ein sehr mächtiges Content-Management-System, woraus sich in Bezug auf Flexibilität und Anpassbarkeit sehr viele Vorteile ergeben. Leider hat diese Mächtigkeit auch einen Nachteil: Beim Aufruf einer TYPO3-Seite muss der komplette TYPO3-Source vom Webserver geladen und geparst werden. Dazu kommen noch etliche Datenbankabfragen, bis die Seite aufgebaut ist und an den Browser gesendet werden kann. Mit einem geschickten Einsatz der Extension nc_staticfilecache lässt sich dieser Umweg abkürzen und der komplette Internetauftritt extrem beschleunigen.

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 im TYPO3-Frontend

AJAX ist was feines für den Besucher, alles fühlt sich schneller und flüssiger an. Für den Entwickler kann es manchmal aber eher mühsam sein. Man braucht die Javascript-Funktionalität und die Server-Funktionalität. Hier im Artikel will ich kurz anreißen, wie die Server-Funktionalität elegant in TYPO3 integriert und die Vorteile, die TYPO3 hier mitbringt, genutzt wird.

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.

Saubere realurl-Links über Domains hinweg

In einem früheren Beitrag, habe ich gezeigt wie man in TYPO3 Links über Domains hinweg generiert, hatte damals aber noch keine Lösung wie die Links auch von realurl korrekt geparst werden. Inzwischen weiß ich jedoch, dass die Lösung des Problems unglaublich einfach ist.

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.