User-friendly customization of the TYPO3 backend

“TYPO3 is too complicated!” – we've all heard or read that at some point. And yes, in some respects the criticism may well be justified. However, in many cases editors just had bad experiences that can be traced back to a neglected TYPO3 backend.

Unfortunately, we have (too) often taken over or seen TYPO3 installations where a lot of time was spent on a stylish frontend, but no adjustments were made to the backend.

The client is left alone with an overwhelming system, containing many standard options of the TYPO3 core that have no actual effect on the frontend. “Layout 1” in content elements? That should be removed (or renamed properly, if it is actually used).

So let's take a look at what we can configure and improve in the TYPO3 backend.

• Use backend user groups to define and restrict access rights properly. No editor should have administration rights.
• Install the backend languages that your editors speak. And provide translations for your project-specific elements and fields.

Some fields in TYPO3 are probably only still included for historical reasons, while others are only needed for special use cases. The four fields from the page properties are listed here as an example:

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

You can also disable or customize fields per element type (e.g. the CType), if required. The following configuration will hide the subheader field for all content elements except “Header” and “Text”:

TCEFORM {    
    tt_content {
        subheader.disabled = 1

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

You can also configure the available content elements via Page TSconfig. We prefer to use keepItems over removeItems for this. It gives us better control and an overview of which content elements will be available in the end.

We also group the elements according to their source or type:

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)
        }
    }
}

Imagine you have created a page of type “Folder” in which editors can maintain events in a central place. Why should they also be able to create glossary entries there? Restrict the creation of new elements in the page properties with Page TSconfig:

mod.web_list {
   allowedNewTables = tx_myextension_domain_model_event, sys_note
}

As a general rule, global configurations belong in the sitepackage (file-based and versionable). However, TSconfig settings applied in individual parts of the page tree may be set directly in the page properties (that is, in the database). Conditions in the sitepackage are also possible – you can choose the best solution depending on the scenario.

Let's stick with the example of the events mentioned above. These are more extensive in the given project, so you have now created a separate folder for each type of event (webinar, workshop, exhibition, …).

In each folder, you can now set individual default values for events using Page TSconfig: the type, the workshop language – everything that applies to the majority of this event type.

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

You've just eased your editors' workload again.

In general, the text editor should always be adapted to the specific project. The necessary text styles and all other options can be configured via YAML.

However, there are often use cases where the “ large” RTE offers too much liberty. The text field of a teaser element may require bold text and soft hyphens. A table is probably not needed, though.
In some cases, links in the richtext field are also not suitable. For example, if the entire element in the frontend is already linked through a separate link field.

Therefore, you should always create separate RTE configurations for such scenarios and assign them to those elements (documentation). The simplified text editor relieves the editor and avoids errors and misunderstandings.

The configurations presented here do not cover all the possibilities. We encourage you to explore the TSconfig documentation and install the Styleguide extension. You will find many valuable suggestions on how to make your TYPO3 project simpler, more logical and more appealing for editors. Your clients will appreciate it.