Felder im TYPO3-Backend gruppieren

Mit der TYPO3-Extension Extension Kickstarter lassen sich Extensions incl. der dazu gewünschten Tabellen recht einfach anlegen. Allerdings werden alle Felder nur simpel nacheinander aufgelistet und eine echte Zusammengehörigkeit ist nicht sofort zu erkennen.

Um dem Redakteur zumindest eine kleine Hilfestellung zu geben, könnte man die Feldbeschriftungen anpassen. Dadurch lässt sich zumindest auf den zweiten Blick eine Zusammengehörigkeit erkennen.

Mit ein klein wenig Kenntnis über das „Table Configuration Array“ (TCA) kann man Felder jedoch auch sinnvoll und unverkennbar gruppieren. Wie das geht wird im Folgenden vorgestellt.

Zunächst öffnen wir die vom Extension Kickstarter angelegte Datei tca.php und suchen dort die Konfiguration für die entsprechende Tabelle. Diese sieht in stark vereinfachter Darstellung in etwa so aus:

$TCA['tx_myextension_demo'] = array (
	'types' => array (
		'0' => array('showitem' => 'hidden;;1, name, x, y, isbranch')
	),
	'palettes' => array (
		'1' => array('showitem' => 'starttime, endtime')
	)
);

Im Feld [types][0] sind alle Felder in der Reihenfolge aufgelistet, wie sie im Backend-Formular zu sehen sein werden. Im Feld [palettes][1] ist die zweite Optionspalette definiert, die dem Feld hidden über den Index 1 zugeordnet ist. Genau eine solche Optionspalette wollen wir uns, in angepasster Form, zu Nutzen machen. Zu diesem Zweck verlagern wir die Felder x, y, isbranch in eine eigene Palette.

$TCA['tx_myextension_demo'] = array (
	'types' => array (
		'0' => array('showitem' => 'hidden;;1, name, --palette--;Flash-Weltkarte;worldmap')
	),
	'palettes' => array (
		'1' => array('showitem' => 'starttime, endtime'),
		'worldmap' => array('showitem' => 'x, y, isbranch')
	)
);

Dieser geben wir der Übersichtlichkeit halber keine Zahl als Index, sondern den Namen worldmap. Zusätzlich platzieren wir in der normalen Liste aller Felder ([types][0]) ein neues Feld, das ebenfalls einer kleine Erklärung bedarf: --palette--;Worldmap;worldmap. Diese Konfiguration wird durch Semikolon in drei Bereiche unterteilt:

  • Der erste Wert --palette-- bedeutet, dass das kein reguläres Eingabefeld ist, dessen definition sich ebenfalls im TCA befindet, sondern ein Spezialfeld als Platzhalter für eine Palette.
  • Der dritte Wert worldmap ist der Index für die Palette, wie er auch im Array [palettes] auftaucht.
  • Der Zweite Konfigurations-Wert ist der angezeigte Name der Palette.

Als letzten Feinschliff geben wir der Palette noch ein Attribut canNotCollapse. Das bedeutet, dass sie nicht mit der Option „Zweite Optionspalette anzeigen“ erscheint und verschwindet, sondern immer noch zu sehen ist. Zusätzlich machen wir den Namen Übersetzbar. Das geschieht, indem wir den vorher fest eingetragenen Wert Flash-Weltkarte durch einen Verweis auf die Local-Lang ersetzen. Selbstverständlich muss in der Datei locallang_db.xml dann auch der entsprechende Eintrag vorhanden sein.

$TCA['tx_myextension_demo'] = array (
	'types' => array (
		'0' => array('showitem' => 'hidden;;1, name, --palette--;LLL:EXT:myextension/locallang_db.xml:tx_myextension_demo.worldmap;worldmap')
	),
	'palettes' => array (
		'1' => array('showitem' => 'starttime, endtime'),
		'worldmap' => array('showitem' => 'x, y, isbranch', 'canNotCollapse' => 1)
	)
);

TYPO3-Tabellen nur auf der root-Ebene

In TYPO3 ist in der Regel jeder Datensatz einer konkreten Seite zugeordnet. Das hat seinen Sinn, um Ordnung zu schaffen. Allerdings kann es in einigen Fällen auch von Nachteil sein, wenn Datensätze dadurch evtl. schwerer auffindbar sind. Abhilfe kann geschaffen werden, indem eine Tabelle nur noch für die root-Ebene (pid = 0) erlaubt wird.

Das geht ganz einfach mit einem Eintrag in der TCA der entsprechenden Tabelle, z.B. in der Datei typo3conf/extTables.php

$TCA[<tablename>]['ctrl']['rootLevel'] = 1;

Es ist aber dabei zu beachten, dass nur Backend-Benutzer mit Administrator-Rechten auf der root-Ebene arbeiten dürfen.

Tabellen nur für TYPO3-Administratoren

Im TYPO3-Backend lassen sich Tabellen mit einer simplen Zusatzkonfiguration für normale Redakteure sperren. Tabellen sind dann nur noch für Administratoren sichtbar und die Inhalte können auch nur von Administratoren bearbeitet werden.

$TCA[<tablename>]['ctrl']['adminOnly'] = 1;

Read-Only-Felder im TYPO3-Backend

In manchen Fällen ist es wünschenswert, in TYPO3 Tabellenfelder für einen BE-User bzw. Administrator zwar sichtbar zu machen, aber nicht bearbeitbar. Das funktioniert mit einer kleinen Anpassung im Table Configuration Array (TCA) der entsprechenden Tabelle.

$TCA[<tablename>]['columns'][<fieldname>]['config']['readOnly'] = 1;

Das Attribut kann auf die unterschiedlichsten Feldtypen angewendet werden. Hier ist außer einem einzeiligen und einem mehrzeiligen Textfeld sogar ein Datei-Feld auf „readOnly“ gesetzt:

Die Sinnhaftigkeit dieses Vorgehens muss natürlich in jedem Fall individuell geprüft werden. Der oben gezeigte Screenshot zeigt einen Ausschnitt aus einer Extension, die über Fronten-User-Eingaben befüllt wird. Den Backend-Usern ist es dann noch gestattet, zusätzliche Dateien anzuhängen.

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.

TYPO3-Backend-Modul für mm_forum anpassen

Die Extension „mm_forum“ ist eine mächtige Forum-Extension mit einer großen Zahl an Features. Um das Forum richtig verwalten zu können, sollte man dem Kunden einen Zugriff auf das Forum-Backend-Modul gewähren. Allerdings verbergen sich dort auch kritische Einstellungsmöglichkeiten, mit denen man schnell die Funktionalität ausbremsen oder Sicherheitslöcher aufreisen kann.

Wenn man einmal weiß wie es geht, lassen sich aber alle Submodule, Kategorien und Felder je nach Benutzergruppe ausblenden. Auf diesem Weg ist es möglich, dass der Kunde sein Forum selbst verwalten kann, ohne Angst haben zu müssen aufgrund von Unkenntnis gefährliche Konfigurationen vorzunehmen.

Die Bereiche des Backend-Moduls werden dynamisch auf Grundlage der TSconfig-Konfiguration generiert. Die Standard-Konfiguration befindet sich in der Datei EXT:mm_forum/res/ts/tx_mmforum_pagetsconfig.ts. Die einzelnen Submodule stehen dabei in mod.web_txmmforumM1.sections, die Kategorien des Submoduls „Installation“ stehen in mod.web_txmmforumM1.submodules.installation.categories und die Definition der Felder in mod.web_txmmforumM1.submodules.installation.categories.<categoryname>.items. Das Schema ist dabei stets das gleiche: Ein Hauptpunkt bekommt einen Typ zugewiesen (Bsp.: MMFORUM_SECTION_ITEM, MMFORUM_CONF_CATEGORY, MMFORUM_CONF_ITEM) und enthält eine Konfiguration zu Darstellung und Inhalt in den Kindelementen.

Um ein Element auszublenden, ist es also einfach nur nötig, den zugewiesenen Typ zu überschreiben, bzw. zu entfernen. Idealerweise kann das in der User TSconfig eines Backendbenutzers oder eine Backendbenutzer-Gruppe vorgenommen werden.

### section "TEMPLATE"
mod.web_txmmforumM1.sections.30 =

### section "TOOLS"
mod.web_txmmforumM1.sections.40 =

### section "IMPORT"
mod.web_txmmforumM1.sections.50 =

### section "USER FIELDS"
mod.web_txmmforumM1.sections.60 =

### section "INSTALL"

# category "GENERAL"
mod.web_txmmforumM1.submodules.installation.categories.general.items.storagePID =
mod.web_txmmforumM1.submodules.installation.categories.general.items.userPID =
mod.web_txmmforumM1.submodules.installation.categories.general.items.userGroup =
mod.web_txmmforumM1.submodules.installation.categories.general.items.adminGroup =
mod.web_txmmforumM1.submodules.installation.categories.general.items.realUrl_specialLinks =
mod.web_txmmforumM1.submodules.installation.categories.general.items.disableRootline =
mod.web_txmmforumM1.submodules.installation.categories.general.items.userNameField =

# category "USER"
mod.web_txmmforumM1.submodules.installation.categories.user =

# category "FORUM"
mod.web_txmmforumM1.submodules.installation.categories.forum.items.boardPID =
mod.web_txmmforumM1.submodules.installation.categories.forum.items.moderatedBoard =
mod.web_txmmforumM1.submodules.installation.categories.forum.items.enableRanks =
mod.web_txmmforumM1.submodules.installation.categories.forum.items.enableShadows =
mod.web_txmmforumM1.submodules.installation.categories.forum.items.prefixes =
mod.web_txmmforumM1.submodules.installation.categories.forum.items.polls_restrict =
mod.web_txmmforumM1.submodules.installation.categories.forum.items.rssPID =
mod.web_txmmforumM1.submodules.installation.categories.forum.items.topicIconMode =
mod.web_txmmforumM1.submodules.installation.categories.forum.items.attachment_deny =
mod.web_txmmforumM1.submodules.installation.categories.forum.items.attachment_filesize =

# category "PRIVATE MESSAGING"
mod.web_txmmforumM1.submodules.installation.categories.pm =

# category "SEARCH"
mod.web_txmmforumM1.submodules.installation.categories.search =

# category "FILE PATHS"
mod.web_txmmforumM1.submodules.installation.categories.filepaths =

# category "CRONJOBS"
mod.web_txmmforumM1.submodules.installation.categories.cron =

Hier das komplette und das reduzierte Backend-Modul im Vergleich:

 

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',
        ),
    ),
);

VEYTON: Eigene Navigationspunkte im Admin-Tool

Was in VEYTON die Flexibilität und die Anpassungsmöglichkeiten des Shop-Frontends angeht, bin ich wirklich begeistert. Die Sache mit den Hook-Points ist einfach zu verstehen und extrem flexibel. Doch wenn es an die Anpassung des Admin-Bereichs geht, hört der Spaß auf. Das ist eine extrem undurchsichtige und lästige Angelegenheit. Inzwischen habe ich durch „trial and error“ herausgefunden, wie ich einen eigenen Navigationspunkt im Admin-Backend hinzufügen kann.

Die Lösung liegt in der Tabelle, die intern über die Konstante TABLE_ADMIN_NAVIGATION angesprochen wird. Vermutlich heißt diese Tabelle bei Euch xt_acl_nav oder acl_nav. Wenn nicht, könnt Ihr sie auf jeden Fall über die interne Konstante herausfinden. Bitte beachtet außerdem, dass die Reihenfolge, wie ich auf die Felder eingehen werde, nicht der Reihenfolge in der Datenbank entspricht, sondern für ein besseres Verständnis angepasst wurde.

text
Die eindeutige Bezeichnung des Navigationspunktes. Der Text kann dann selbstverständlich über die Lokalisierungstabelle an die jeweilige Sprache des Admin-Benutzers angepasst werden.

icon
Zu jedem Navigationspunkt gibt es neben dem Text auch das kleine Icon. Der Pfad muss relativ zum Verzeichnis xtAdmin sein und die Grafik sollte 16×16 Pixel groß sein.

navtype
Gibt an, in welche Navigation der neue Punkt integriert werden soll. Mögliche Werte sind N und W. Vermutlich steht das für „North“ und „West“. Denn schließlich kann man mit N einen Button in der oberen Navigationsleiste neben „Handbuch“, „Helpdesk“, etc. ablegen, während man mit W einen Navigationspunkt in der linken Hauptnavigation erzeugt.

type
Wenn navtype=W angegeben wurde, kann der Typ auf den Wert G oder I gesetzt werden. G enthält weitere Unterpunkte und könnte von „Group“ abgeleitet worden sein. I enthält keine weitere Unterpunkte, sondern ist selbst der letzte Unterpunkt einer Gruppe, die Bezeichnung könnte von „inner“ abgeleitet worden sein.
Für navtype=N muss der Wert G eingetragen werden.

parent
Für navtype=W zeigt das Feld an, welchem Elternelement der Navigationspunkt zugeordnet worden sein. Das Elternelement muss vom type=G sein. Wird hier der Wert 0 eingetragen, wird in der Navigation ein komplett neuer Block angelegt. Um das neue Navigationselement in eine vorhandene Gruppe einzugliedern, muss deren bei text eingetragene Bezeichnung hier hinterlegt werden.
Für navtype=N muss der Wert 0 eingetragen werden.

sortorder
Ein einfacher Sortierungswert als Integer. Niedrige Werte werden zuerst dargestellt, höhere Werte danach.