Wer schon mal ein TYPO3-System für einen Kunden aufgesetzt hat, kennt das Problem: TYPO3 läuft, nur die Inhalte fehlen noch. Trotz Schulung verstehen die Redakteure nicht, wie die Eingaben zu erfolgen haben. Also erstellt man im Nachgang Handbücher und Screencasts, aber das System wird dadurch nicht einfacher. Die Inhaltspflege geht nicht voran und der geplante Live-Termin naht. Die Stimmung kippt und der pünktliche Launch steht auf der Kippe. Dadurch leidet die Kundenzufriedenheit, manchmal bis zur Eskalation. Und das bei einem technisch voll funktionsfähigem TYPO3-System.

Leider sind solche Projektverläufe nicht fiktiv, sondern Realität. Dabei bietet TYPO3 als leistungsfähiges Framework genügend Möglichkeiten, Funktionen so zu realisieren, dass Redakteure diese einfach nutzen können.

Die Ursachen für einen derartig unglücklichen Projektverlauf sind vielfältig. Oftmals berücksichtigt eine ausführende Agentur bei der Entwicklung die Pflege der Inhalte nur unzureichend – oder stellt sie hinter die technische Lösung. Entwickler haben eine andere Perspektive und gewöhnlich wenig praktische Erfahrung in der redaktionellen Arbeit. Später im Test begutachten sie die Funktionen und Features sowie eventuell die Usabilty im Frontend. Die Bedienbarkeit des Backends steht jedoch oft hinten an – solange man alle Daten per Admin-Account einpflegen kann, ist alles im grünen Bereich. Die Probleme bei der Pflege treten somit erst bei der redaktionellen Arbeit beim Kunden auf. Doch das ist häufig zu spät.

Dabei kann man viele Eingaben für den Redakteur vereinfachen, ohne langsamer oder komplizierter zu entwickeln, wenn man nur mitdenkt. Wer einige Regeln und Lösungen berücksichtigt, kann ein TYPO3-System so aufsetzen, dass Anwender besser mit der Benutzung des Backends zurecht kommen.

Viele Konfigurationen und Erweiterungen eines TYPO3-Systems realisieren Entwickler aufgrund spezieller Projektanforderungen. Wichtig ist, was der Kunde damit bezweckt, und wie die Pflege aus Sicht der Redaktion erfolgen soll. Häufig überlagert die Betrachtung von Datenmodellen und Features diese Projektanforderungen.

What you see is what you get: Ein Rich-Text-Editor mit richtigem Stylesheet erspart unnötiges Hin- und Herschalten zwischen Front- und Backend.

Möchte der Kunde beispielsweise Ansprechpartner zu Veranstaltungen zuordnen, sollte er an der Veranstaltung die Zuordnung zu der Person pflegen und nicht anders herum. Bei der Verwaltung von Mitarbeiterdaten ist beispielsweise die Zuordnung zu einer Abteilung gegebenenfalls in der Pflegemaske der Person sinnvoller.

Die Möglichkeiten sind so vielfältig und individuell wie die Anforderungen. Hier sollte man bei der Definition der technischen Lösung im Sinne des Anwenders planen. Erkennt der Redakteur im TYPO3-System seinen Anwendungsfall wieder, dann versteht er auch, wie die Pflege funktioniert – findet er ihn nicht wieder, entsteht Verwirrung.

Vielleicht die banalste Regel, aber leider besteht genau hier am häufigsten ein Problem: die Sprache. Grundsätzlich sollte man die Sprache der Redakteure verwenden, zum Beispiel Deutsch statt Englisch. Und dies sollte man dann auch konsequent umsetzen, sodass kein Sprachwirrwar im Backend entsteht. Wenn aus technischen Gesichtspunkten englische Texte bereitgestellt werden sollen, dann muss man zwingend die deutsche Übersetzung mit anbieten.

Ebenso sollte man eine klare und verständliche Sprache verwenden. Kunden und Redakteure kennen viele Fachbegriffe der Webentwicklung nicht. Hier können neben der Verwendung von einfacheren Begriffen auch verständliche Erläuterungen Wunder wirken. Wichtig ist dabei, dass der Redakteur die Bedeutung eines Felds oder einer Funktion für seine Zwecke versteht. Ein Klassiker sind die vier Spalten im Backend. Neben der Ausblendung nicht verwendeter Spalten kann man die sichtbaren auch inhaltlich zur Website passend benennen.

$TCA["tt_content"]["columns"]["colPos"]["config"]["items"] = array ( 
 "0" => array ("Inhalt||Inhalt||||||||","0"), 
 "1" => array ("Bühne||Bühne||||||||","1"), 
 "2" => array ("Weiterführende Links||Weiterführende Links||||||||","2") 
);

Die neueren TYPO3-Versionen beschreiben zum Beispiel die Felder „keywords“ und „description“ in den Seiteneigenschaften sinnvoll: „Beschreibung (SEO): Geben Sie eine kurze Beschreibung der Seite ein. Sie wird in den Suchergebnissen von Suchmaschinen angezeigt.“ So weiß der Anwender genau was er tun muss und auch wozu das System die Eingabe verwendet.

Plugin Options, Veranstaltungstipps, Startingpoint: Deutsch und Englisch gemischt sowie unklare Erläuterungen können Redakteure leicht verwirren.

Ein Softwaresystem sollte sich möglichst selbst erklären. Handbücher und Screencasts sind immer ein Umweg. TYPO3 bietet die Möglichkeit, Erläuterungen direkt in die Redaktionsoberfläche zu integrieren. Für Standardfelder finden sich hier auch Texte, wie das Beispiel der Meta-Description zeigt. Bei projektspezifischen Umsetzungen ignorieren Entwickler diese leider fast immer, obwohl hier für den Redakteur besonderer Bedarf besteht. Bietet man auch bei individuellen Erweiterungen sinnvolle Hinweise, sind die CMS-eigenen Hilfefunktionen eine echte Hilfe. In Schulungen kann man sich dann auf den Gesamtüberblick konzentrieren und bei Details auf die integrierte Hilfe verweisen. Die Einbindung ist dabei einfach und unter dem Stichwort „Context Sensitive Help (CSH)“ in der „Core Documentation“ [1] gut erläutert.

Benötigt man bei komplexeren Systemen dennoch ein Handbuch oder Screencasts, kann man diese über ein einfaches Backend-Modul in das TYPO3-System integrieren. So hat der Redakteur immer alle Informationen zur Hand.

Dass die Einrichtung von Redaktionsaccounts sinnvoll ist, steht außer Frage. Diese sollte man zu Beginn einrichten und bereits während der Entwicklung – zum Beispiel zur Pflege von Testinhalten – verwenden. So macht man Probleme frühzeitig sichtbar und kann entsprechende Lösungen finden, bevor die Entwicklung abgeschlossen ist.

Bei der Konfiguration der Redaktionsaccounts und -gruppen sollte man immer eine starke Reduktion der Eingabeoptionen anstreben. Umso weniger Module, Seiten und Felder, desto einfacher fällt die Orientierung im Backend bei den Standardanwendungen. Bei großen Inhaltsmengen bietet sich ein differenzierter Zugriff für Redakteure an.

In größeren Organisationen gibt es in der Regel Redakteure für einzelne Teilbereiche wie Pressemeldungen (PR-Abteilung) oder Job-Angebote (Personalabteilung). Hier kann der Entwickler neben den Funktionen auch den Seitenbaum einschränken. Ebenso kann man Attribute in den Seiteneigenschaften, bei Inhaltselementen und anderen Datenstrukturen ausblenden. Gibt es beispielsweise einen SEO-Redakteur, kann der Entwickler die entsprechenden Felder für diesen ein- und für andere Redakteure ausblenden.

Wie die Konzeption und Einrichtung von Benutzergruppen und -berechtigungen konkret erfolgen, zeigt der Artikel „Benutzerrechte und Rechte im Seitenbaum: Rechtevergabe im TYPO3-Backend“ in t3n Nr. 16 [2].

Manche Seiten haben einen komplexen Aufbau, den man auch durch Optimierungen im Backend nicht vollständig vereinfachen kann. Zum Beispiel eine Seite für eine Case Study, die in einer Vollausprägung Fotos, Zitate, ein Video, Textinhalte und Downloads enthalten kann, in einer kleineren Ausprägung aber auch nur Text- und Bildinhalte umfassen kann. Zur flexiblen Bestückung einer umfangreichen Seite kommt man an mehreren Eingabeschritten nicht vorbei.

Ein einfaches, aber sehr wirkungsvolles Hilfsmittel sind vorbefüllte Seiten, die als Vorlage dienen. In der Vorlage kann man etwa die Maximalausprägung der Seite einpflegen. Als Text setzt man Platzhalter-Texte oder besser Erläuterungen ein. Die Seite stellt man anschließend auf „nicht sichtbar“ und verbietet den Redakteuren, die Seite zu bearbeiten und zu löschen. Redakteure können nun anstatt eine neue Seite anzulegen, diese Seite einfach per Drag & Drop kopieren. So müssen sie nicht alle Elemente neu zusammenstellen, sondern können durch Ändern und Löschen einzelner Elemente schneller zum Ziel gelangen.

Die Seiteneigenschaften in TYPO3 sind sehr umfangreich und sorgen am Anfang fast immer für Verwirrung. Arbeitet man zusätzlich mit verschiedenen Seitentypen und Attributen, verschärft sich das Problem. Spätestens dann ist es sinnvoll, zum einen die Anzahl der Felder stark zu reduzieren und zum anderen die Gruppierungen der Seiteneigenschaften zu hinterfragen sowie gegebenenfalls logisch neu zu gruppieren. Für die Organisation der Eingabefelder gibt es in TYPO3 mehrere Konzepte: Tabs, Paletten und die zweite Optionspalette. Tabs wie „Ressourcen“ oder „Erweitert“ sind wenig aussagekräftig. Dagegen kann ein Tab „Seitenvorschau“ mit Feldern für Teaserbild und Teasertext (abstract) sinnvoll sein. Sinnvoll ist auch ein Tab „SEO“, der Felder für Fenstertitel, Keywords, Description, OpenGraph-Angaben, Alt-Texte von Seitenelementen und das Pfadsegment umfassen könnte.

In Paletten kann man dagegen alle enger zusammengehörigen Felder gruppieren und so beispielsweise den Fenstertitel in die Palette „Meta-Tags“ des Tabs „Metadaten“ integrieren. Die zweite Optionspalette ist sinnvoll für Angaben, die nicht unbedingt nötig sind oder die der Redakteur seltener verwendet. Zum Beispiel kann ein Seitentyp für eine Veranstaltung das Datum und den Ort in einer üblichen Palette enthalten und ein optionales Enddatum sowie Angabe zu Uhrzeit, Raum und Referent in der zweiten Optionspalette. So erhält der Redakteur die Chance, die Paletten und Felder zu überblicken, ohne auf die zusätzlichen Eingabemöglichkeiten verzichten zu müssen. Die Konfiguration neuer Felder in den Seiteneigenschaften mit Angabe der Position funktioniert so:

t3lib_extMgm::addToAllTCAtypes('pages', 'columnname','','before:hidden');

Neue Tabs kann man ebenso einfach einfügen. Im dritten Parameter der Funktion kann man zudem die IDs von Seitentypen angeben, falls die neuen Felder nicht global gültig sind.

t3lib_extMgm::addToAllTCAtypes('pages', '--div--;Tab-Name,columnname','55,56,57','after:description');

Mit der Funktion „addFieldsToPalette“ kann man Felder in bestehende Paletten einfügen. Mit der Funktion „removeDuplicatesForInsertion“ kann man dann sicherstellen, dass die Felder nicht doppelt auftauchen. Grundsätzlich ist alles, was für die Seiteneigenschaften gilt, auch für die Felder bei Inhaltelementen aus tt_content relevant. Hier verstehen Nutzer allerdings erfahrungsgemäß die Standardanordnung der Felder besser.

Der Rich-Text-Editor dient als zentrale Eingabemöglichkeit. Zum Teil geben Redakteure hier gesamte Artikel mit Zwischenüberschriften, Formatierungen und Bildern ein. Der Editor bietet dabei in der Regel mehr Funktionen als nötig. Über eine TSconfig-Konfiguration kann man den Umfang der Funktionen auf die Bedürfnisse zuschneiden. Insbesondere die Optionen „showButtons“ und „hideButtons“ sind hier von Bedeutung.

RTE.default {
	hidePStyleItems = h1, h2, h5, h6, pre, address, div, blockquote
	showButtons (...)
	hideButtons (...)
}

Darüber hinaus ist die Anpassung des CSS für den Editor sehr wichtig. Erfolgt im RTE bereits ein Styling der Inhalte, das der Frontendausgabe gleicht, bleibt den Redakteuren ein allzu häufiges Hin- und Herschalten zwischen Eingabe und Vorschau erspart. Das CSS wird ebenfalls per TSconfig angegeben:

RTE.default {
	contentCSS = EXT:extname/static/templatename/css/rtehtmlarea.css
}

Frontend-Plugins sollen auf der Website bestimmte Funktionen oder spezielle Ansichten bereitstellen. Häufig können Redakteure hier Inhalte und Konfigurationen einpflegen – beispielsweise ein Teaser zu einem Ansprechpartner oder ein spezielles Inhaltselement mit zwei Rich-Text-Feldern.

Für die technische Umsetzung gibt es verschiedene Varianten – man kann sie als klassisches Inhaltselement (über tt_content) oder als Plugin mit einem Flexform umsetzen. Der Nachteil von Flexforms besteht darin, dass in den Eingabemasken geschachtelte Tab-Ebenen entstehen. Ein Redakteur wählt das Element aus dem Wizard aus, wechselt in den zweiten Tab „Plugin“ und findet dort die Eingabeoptionen. Bei vielen Eingabeoptionen mit zusätzlichen Tabs innerhalb des Flexforms oder bei gleichzeitiger Nutzung von Standardfeldern aus tt_content wird dies schnell konfus.

Konfuse Eingabemaske mit geschachtelten Tabs.

Bei der Umsetzung als individuelle tt_content-Elemente kann der Entwickler die dem Redakteur bereits geläufigen Elemente wiederverwenden. Sind viele Eingaben möglich, kann man Tabs auf der ersten Ebene (wie bei den Seiteneigenschaften) hinzufügen. Zudem kann der Entwickler diese Felder für den Zugriff einzelner Redaktionsgruppen konfigurieren, was mit Flexforms nicht möglich ist. Neben den Vorteilen für die Redaktion entspricht dieser Ansatz auch eher dem Content-Model von TYPO3. Nicht zuletzt ist der Zugriff auf alle Daten per SQL (Stichworte Suche und Datenmigration) und TypoScript möglich, die Übersetzungsmechanismen lassen sich besser nutzen, und die Inhalte bleiben auch beim Wechsel des Typs erhalten, soweit man für Standard-Attribute die vorhandenen Felder nutzt.

Die Erstellung von tt_content-Elementen ist entgegen der gängigen Meinung sehr einfach. Der Code ist fast identisch zu Plugins mit Flexforms:

t3lib_extMgm::addTCAcolumns('tt_content', $CUSTOM_TCA, 1);
$TCA['tt_content']['types'][$_EXTKEY . '_piname']['showitem'] = '--palette--... [tx_extname_columnname] ...';
if (TYPO3_MODE=='BE') $TBE_MODULES_EXT['xMOD_db_new_content_el']['addElClasses']['tx_extname_wizicon'] =
t3lib_extMgm::extPath($_EXTKEY).'piname/class.tx_extname_piname_wizicon.php';
t3lib_extMgm::addPlugin(array(
	'LLL:EXT:extname/locallang_db.xml:tt_content.CType_pi1',
	$_EXTKEY . '_piname',
	t3lib_extMgm::extRelPath($_EXTKEY) . 'ext_icon.gif'
),'Ctype');

t3lib_extMgm::addPItoST43($_EXTKEY, 'pi1/class.tx_extname_piname.php', '_pi1', 'list_type', 1);

$this->columnname = $this->cObj->data['tx_extname_columnname'];

Es gibt mehrere Varianten, um Inhalte und Daten in TYPO3 zu verwalten. Die gängigsten bestehen in der Verwendung von Seitentypen über die Tabelle „pages“, dem Einsatz erweiterter Inhaltelemente über die Tabelle „tt_content“ oder in der Erstellung eigener Tabellen. Entwickler sollten jeweils die Datenstruktur wählen, die den Anwendungsfall für den Redakteur am besten abbilden und am einfachsten macht.

Manche Entitäten kann man gut als Seitentyp abbilden. Das bietet sich immer dann an, wenn es eine Detailansicht gibt und in dieser flexibel Inhalte platziert werden sollen. Die wesentlichen Vorteile ergeben sich aus der konsistenten Pflege für den Redakteur, denn Seiten anlegen kann jeder. Hinzu kommen zahlreiche technische Vorteile wie bei den Themen Übersetzung, Publizierung, Caching, Suchindizierung und URL-Handling sowie bei der Nutzung anderer Erweiterungen. Alle Funktionen sind beim Einsatz von Seitentypen sofort auch für eigene Entitäten verfügbar.

Für andere Entitäten eignen sich Seitentypen eher nicht. Dies trifft zum Beispiel zu, wenn keine Detailansicht existiert oder kein freier Inhalt möglich sein darf. Beispiele hierfür sind strukturierte Daten wie FAQ, Produktdaten oder Adressdatensätze. Hier bieten sich individuelle Tabellen an.

Handelt es sich weniger um Entitäten als um Elemente, die eine Darstellungsart repräsentieren, kann man sinnvoll tt_content-Elemente einsetzen. Klassiker hierfür sind spezielle Störer oder Testimonials sowie kombinierte Inhaltelemente beispielsweise aus Tabelle und Text.

Relationen zwischen Entitäten müssen Entwickler genau durchdenken – und zwar aus semantischer, aus technischer und redaktioneller Sicht. Bei der Betrachtung des Datenmodells ist dabei insbesondere die Navigierbarkeit zu berücksichtigen beziehungsweise die Definition, wo und wie die Relationen tatsächlich gepflegt werden. Bei normalen 1:n und m:n Relationen muss man sich entscheiden, von welcher Seite die Relation gepflegt werden soll, ob sie auf der anderen Seite sichtbar sein soll oder ob sie bidirektional verändert werden soll.

TYPO3 bietet für Relationen verschiedene Konzepte von Einfach-Selectboxen über Mehrfachauswahlen bis hin zu Auswahlfeldern mit Suchfeld, Seitenauswahl-Wizard und Inline-TCA (IRRE). Alle Varianten haben ihre Vor- und Nachteile, die man bei der Definition der technischen Lösung abwägen sollte. Durch die passende Wahl kann man die Verständlichkeit des Backends und die Anzahl der Klicks bei der Bearbeitung deutlich verbessern.

Wenn man die Perspektive der Redakteure im gesamten Prozess stets im Hinterkopf behält, kann man ein TYPO3-System mit einfachen Mitteln sehr viel komfortabler gestalten. Fast alle genannten Maßnahmen erfordern keinen oder nur geringen Mehraufwand. Redakteure und Kunden werden den Entwicklern ein Mitdenken während des Entstehungsprozess danken.

Der Autor

ist Diplom-Kaufmann (FH) und als freier Onlineberater tätig. Seit 1998 arbeitet er mit Webtechnologien und seit 2003 mit TYPO3. In diesem Rahmen hat er in zahlreichen Projekten die unterschiedlichen Rollen wie Trainer für Redakteure, Technischer Konzepter, Projektleiter und Entwickler einnehmen können.