TYPO3-Backend anpassen in fünf Minuten

In der Entscheidungsphase zur Wahl eines Content Management Systems hört man zu TYPO3 oft, dass das Backend für den Redakteur nicht intuitiv und viel zu überladen ist. Dass es zu viele Optionen und Felder gibt, die man beim Erstellen von Inhalten gar nicht verwenden würde und zu einer Überforderung der Redakteure führen.

Auch habe ich schon viele Backends gesehen, in denen für die Redakteure das Backend nicht angepasst oder sogar gar keine Benutzergruppen mit entsprechenden Rollen verwendet wurden. Und somit alle Benutzer mit Adminstrationsrechten im Backend unterwegs waren.

Das hat in meinen Augen mit der steilen Lernkurve von TYPO3 zu tun, die dem Anfänger entsprechende Steine in den Weg legt. Wenn man aber das Konzept der Konfiguration von TYPO3 verstanden hat, stehen einem alle Türen offen, das Backend so einfach wie möglich zu gestalten. Und zwar lediglich mit den Feldern und Optionen, die man zum Erstellen von Inhalten benötigt.

Um das zu erreichen gibt es einen ziemlich einfachen Weg: das Ausblenden von Feldern mittels TCEFORM, dem Setzen von Default-Werten für Felder mit TCAdefault und dem konsequenten Einsatz von Benutzergruppen. Administratoren sind wirklich nur Administratoren und nicht für das Erstellen von Content zu verwenden. Bei einem ordentlich aufgesetzten TYPO3 sollte man sich also eigentlich nie mit einem Administrator-Account anmelden müssen. ;-)

Und zwar blendet man auch für Administratoren alle Felder und Feldwerte aus, die nicht gebraucht werden. Wenn ein Feld keinen Einfluss auf das Verhalten des Elements hat, warum sollte es auch im Backend sichtbar sein?

Das fängt dann schon im Seitenbaum an, dass dort nur Seitentypen sichtbar sind, die verwendet werden können. Gut, dass kann man leider nur auf Userbasis einstellen, so dass ein Administrator alle Seitentypen der Installation sieht, aber für die Benutzergruppen ist das ja noch weiter einschränkbar und dann sollte man lieber für eine Multidomain-Installation, bei der sich diese Konfiguration zwischen den Seiten fundamental unterscheidet, mit verschiedenen Redakteuren/Redakteursgruppen arbeiten.

Per

options.pageTree.doktypesToShowInNewPageDragArea

kann man die UIDs der doktypes angeben, die dort sichtbar sind. Im Fall des Screenshots wären das die UIDs 1 (Standardseite) und 137 (Blog post). In den Seiteneigenschaften kann man dies auf einem etwas anderen Weg für das Feld doktype erreichen:

TCEFORM {
    pages {
        doktype {
          removeItems := addToList(3,4,6,7,138,199,254,255)
        }
    }
}

Hier werden alle UIDs angegeben, die man nicht mehr im Auswahlfeld haben möchte.

In einem weiteren Schritt werden systemweit alle nicht benötigten Content-Elemente und Plugins ausgeblendet, die zwar Bestandteil einer installierten Extension sind, aber nicht gebraucht werden. Zum Beispiel wird man niemals alle Menü-Elemente in einer Installation verwenden. Somit müssen diese auch nicht von einem Admin gesehen werden und in in den Benutzergruppen schränkt man die pflegbaren Content-Elemente ja sowieso noch einmal ein.

Auch hier hilft wieder die Konfiguration über TCEFORM, diesmal verwenden wir ein paar Einträge für die Tabelle tt_content:

TCEFORM {
    tt_content {
        CType {
            removeItems := addToList(header, text, image, textpic, bullets, table, uploads)
            removeItems := addToList(menu_abstract, menu_categorized_content, menu_categorized_pages, menu_pages, menu_subpages, menu_recently_updated, menu_related_pages, menu_section, menu_section_pages, menu_sitemap, menu_sitemap_pages)
            removeItems := addToList(html, div, hortcut, form_formframework)
        }

        list_type {
            removeItems := addToList(blog_latestposts, blog_authors, blog_authorposts, blog_tag, blog_archive, blog_demandedposts, blog_commentform, blog_comments, blog_footer, blog_header, blog_metadata, blog_relatedposts, blog_sidebar)
        }
    }
}

 

In einem weiteren Schritt werden erstmal für die pages-Tabelle die ganzen Felder in den Seiteneigenschaften ausgeblendet.
Das erreicht man ziemlich schnell, indem man die disabled-Property für das entsprechende Feld auf 1 setzt:

TCEFORM {
    pages {
        nav_title.disabled = 1
        subtitle.disabled = 1
        sitemap_changefreq.disabled = 1
        sitemap_priority.disabled = 1
        og_title.disabled = 1
        og_description.disabled = 1
        og_image.disabled = 1
        ...
    }
}

Das Ganze verfeinert man dann über die Benutzergruppen. In größeren Marketing-Abteilungen oder Redaktionen mag es die SEO-Abteilung geben, die dann vielleicht nur die SEO-relevanten Felder der Seiten bearbeiten dürfen usw.

Das gleiche Spiel veranstaltet man dann auch mit den Feldern der Content-Elemente, die man systemweit einschränkt und dann wieder mittels dedizierter Benutzergruppen noch weiter verfeinert.

TCEFORM {
    tt_content {
        colPos.disabled = 1
        header_position.disabled = 1
        date.disabled = 1
        header_link.disabled = 1
        subheader.disabled = 1
        imagewidth.disabled = 1
        imageheight.disabled = 1
        imageborder.disabled = 1
        imageorient.disabled = 1
        ...
    }
}

Eine weitere wichtige Konfiguration dreht sich um den CKEditor. Dieser sollte nur die notwendigen Stile und Elemente wie Listen usw. zulassen, die auch im Stylesheet vorhanden sind. Gleiches gilt für den Linkhandler-Assistenten oder die Optionen beim Einfügen einer Tabelle im CKEditor. Aber das ist ein komplettes Kapitel für sich...

Und TYPO3 wäre nicht TYPO3, wenn es für oben aufgeführte Vorschläge nicht noch mindestens einen anderen Weg geben würde. Denn es wird keiner davon abgehalten, die ganze Konfiguration über TCA-Overrides zu implementieren. Viel Spaß dabei!

Kommentare

Keine Kommentare

Kommentar schreiben

* Diese Felder sind erforderlich