Anwenderfreundliche Individualisierungen des TYPO3-Backends

“TYPO3 ist zu kompliziert!” – das haben wir alle schon irgendwann gehört oder gelesen. Und ja, in manchen Punkten mag die Kritik durchaus berechtigt sein. Oft haben Redakteure aber schlechte Erfahrungen gemacht, die eher auf ein stiefmütterlich behandeltes TYPO3-Backend zurückzuführen sind.

Wir haben leider schon (zu) oft TYPO3-Installationen übernommen und gesehen, bei denen viel Wert auf ein stylisches Frontend gelegt wurde, aber keinerlei Anpassungen im Backend vorgenommen wurden.

Der Kunde wird mit einem überfrachteten System alleine gelassen, wobei viele Standard-Funktionen des TYPO3-Core im Frontend keinerlei Auswirkungen haben. “Layout 1” im Inhaltselement? Das gehört entfernt (oder umbenannt, sofern es denn wirklich genutzt wird).

Lasst uns daher einmal anschauen, was wir im TYPO3-Backend alles konfigurieren und verbessern können.

• Nutzt Backend-Benutzergruppen, um Zugriffsrechte sinnvoll zu definieren und zu beschränken. Kein Redakteur sollte Administrationsrechte besitzen.
• Installiert die Backend-Sprachen, die eure Redakteure sprechen. Und liefert Übersetzungen für eure projektspezifischen Elemente und Felder.

Manche Felder sind wohl nur noch aus historischen Gründen in TYPO3 enthalten, andere werden nur in Ausnahmefällen benötigt. Die vier Felder aus den Seiteneigenschaften sind hier exemplarisch genannt:

TCEFORM {
    pages {
        layout.disabled = 1
        keywords.disabled = 1
        author.disabled = 1
        author_email.disabled = 1
    }
}

Felder lassen sich bei Bedarf auch nach Element-Typ (z.B. dem CType) deaktivieren oder anpassen. Hiermit wird das Subheader-Feld für alle Inhaltselemente außer “Überschrift” und “Text” ausgeblendet:

TCEFORM {    
    tt_content {
        subheader.disabled = 1

        subheader.types {
            header.disabled = 0
            text.disabled = 0
        }
    }
}

Auch die verfügbaren Inhaltselemente lassen sich per Page TSconfig konfigurieren. Wir bevorzugen an dieser Stelle keepItems (statt removeItems). So haben wir eine bessere Kontrolle und Übersicht darüber, welche Inhaltselemente am Ende verfügbar sind.

Zudem gruppieren wir uns die Elemente anhand ihrer Quelle bzw. ihres Typs:

TCEFORM {
    tt_content {
        CType {
            # TYPO3 Core:
            keepItems = header, text, uploads, list, form_formframework, menu_sitemap_pages, shortcut
            # Container:
            keepItems := addToList(container_1col, container_2col_50_50, container_3col)
            # Sitepackage:
            keepItems := addToList(hero, quote, card_group, timeline, accordion)
            # Third-party extensions:
            keepItems := addToList(news_pi1, news_newsdetail)
        }
    }
}

Ihr habt eine Seite vom Typ “Ordner” angelegt, in denen Redakteure Veranstaltungen zentral pflegen können. Warum sollte er dort auch Glossareinträge anlegen können? Beschränkt die Erstellung neuer Elemente in den Seiteneigenschaften mit Page TSconfig:

mod.web_list {
   allowedNewTables = tx_myextension_domain_model_event, sys_note
}

Generell gilt: Globale Konfigurationen gehören ins Sitepackage (dateibasiert und versionierbar). In einzelnen Bereichen des Seitenbaums angewendete TSconfig-Einstellungen dürfen hingegen durchaus in den Seiteneigenschaften (also in der Datenbank) gesetzt werden. Conditions im Sitepackage sind auch möglich – den besten Lösungsweg könnt ihr fallabhängig wählen.

Bleiben wir beim oben genannten Beispiel der Veranstaltungen. Diese sind im Projekt umfangreicher, daher habt ihr jetzt für jede Veranstaltungsart (Webinar, Workshop, Messe, …) einen eigenen Ordner erstellt.

In jedem Ordner könnt ihr mit Page TSconfig nun individuelle Standardwerte für Veranstaltungen setzen: den Typ, die Workshop-Sprache – alles, was für die Veranstaltungsart mehrheitlich gilt.

TCAdefaults.tx_myextension_domain_model_event.event_type = webinar
TCAdefaults.tx_myextension_domain_model_event.workshop_language = de

So schnell habt ihr euren Redakteuren wieder etwas Arbeit abgenommen.

Generell gilt: Der Texteditor sollte auf das jeweilige Projekt zugeschnitten werden. Die notwendigen Textstile und alle weiteren Optionen lassen sich per YAML konfigurieren.

Es gibt aber schnell Anwendungsfälle, bei denen der “große” RTE zu viele Freiheiten bietet. Im Textfeld eines Teaser-Elements werden vielleicht Fettschreibung und das Soft-Hyphen benötigt. Eine Tabelle eher nicht.
In einigen Fällen sind auch Links im Richtext-Feld nicht sinnvoll – etwa, wenn das gesamte Element im Frontend bereits durch ein separates Linkfeld verlinkt wird.

Daher sollte für solche Fälle immer eine separate RTE-Konfiguration erstellt und dem Element zugewiesen werden (Dokumentation). Der so reduzierte Texteditor entlastet den Redakteur, vermeidet Fehler und Missverständnisse.

Die hier präsentierten Konfigurationen zeigen längst nicht alle Möglichkeiten. Blättert daher einfach mal durch die TSconfig-Dokumentation und installiert euch die Styleguide-Extension. Ihr werdet dort viele Anregungen finden, wie ihr euer TYPO3-Projekt für Redakteure einfacher, logischer und ansprechender gestalten könnt. Eure Kunden werden es euch danken.