TYPO3 "System Management" - The big picture


This document is about the future of “system management” of single TYPO3 instances - a mixture of various backend modules and what is currently known as “install tool”.

The main goal is to introduce a clear distinction between “TYPO3 system management”, “site administration” and “installation process”.

This topic has been started during the TYPO3 User Experience Week 2017 and is currently aligned on and followed by core team members and other contributors: Susi Moog, Benni Mack, Oliver Hader, Mona Muzaffar, Marco Christian Krenn, Christian Kuhn, Philipp Hamid.

Current situation

With the rewrite of the install tool for version TYPO3 v6.2, the install tool has been made an independent application with relatively little dependencies always works, even if the backend breaks down after upgrades. It is an important anchor of the system, enabling install tool administrators to revive the system even if conflicting extensions break other parts of the system.

Apart from that, most functionality from the “old” install tool has been adopted and not too much changed with the “functionality scope” of the install tool. The install tool currently provides:

  • System Maintenance - eg. lowlevel “cache clearing”, processed file cleanup, typo3temp cleanup, …
  • System settings administration - All configuration, Preset handling, …
  • Upgrade helpers - Core updater, TCA migration checker, Change documentation, …
  • Environment analysis - phpinfo, system check, folder structure, image calculation tests, …

Furthermore, some backend modules which are not part of the install tool provide functionality which change main system configuration (write TYPO3_CONF_VARS / LocalConfiguration / PackageStates / …) - obvious examples are the “Extension configuration” within the extension manager and the “Languages” module that handle system languages. Various other modules exist on this level which show, but don’t manipulate system configuration - for instance the “Reports” module and the “Configuration” module. “DB check” is a mixture of both.

The overall state of this is dissatisfying: It is not clear which parts belongs where in the system, the distinction between “Admin tools” and “System” in the main module looks arbitrary, new administrators don’t understand why certain functionality is located at the one or the other place. The need for an “install tool password” does not help and adds additional headaches organizing the password communication within developer groups maintaining an instance. Additionally, the install tool already provides two distinct applications in itself: The “step installer” and the “tool”.


The current mixture of system level administration tasks at various places in the backend and install tool should be disentangled, have a clear distinction and access rights management:

  • Split install tool into two applications: An installer which only takes care of “first installation” and can be removed after initial installation has been completed. It can be extracted to an own extension (or stays as “install” and the other part is extracted to a different extension name) for now, but could later evolve to for instance a .phar based installer or similar.

  • The other part of the current “install tool” evolves to a “system management” module that has all functionality which changes the “system” level of an instance: Everything that changes LocalConfiguration, PackageStates, l10n, main file / folder structure and required low level server infrastructure.

  • The “system management” application is integrated into the TYPO3 backend main module - A current WIP patch brings 4 modules “Maintenance”, “Settings”, “Upgrade” and “Environment” within the “System” main module. Current “System” module is renamed to “Admin tools” and vice versa. The current menu of the install tool (“All configuration” and friends) vanishes. The “system management” application is thus seamlessly integrated into the TYPO3 backend and brings the same look and feel. The “standalone” version of the system management application looks like the backend, just without all the other modules (and some color indicator or similar).

  • The install tool password falls. A new role “system management” for backend admin users is introduced: A LocalConfiguration setting “SYS/SystemManagementUsers” or similar contains a list of backend users who can access system management. This list can be administered only from within the system management itself.

  • Logged in backend administrators who are also system managers do see the system management main module entries and can use them without further login, directly. Admins not in this list don’t see the menu points.

  • The standalone version of the system management (not from within backend application) allows user/password based login as an admin user who has the system management role.

  • The installer is split from “system management” recovery - the recovery checks db and be_user table and communicates a shell based solution on how users could regain access to the system management if needed (similar to the current “forgot install tool password but based on be_users).

We end up with a clean separation of concerns and different user levels in the backend:

  • Editors / editor groups for content administration - no change here

  • Backend admins: Set up instance, manage site, has access to tree root node, sys_domain, sys_language, scheduler, show (!, not change) system configuration, CRUD other BE admins, can not set a be_user as system maintainer.

  • System maintainer: Extension configuration and management, environment, manage LocalConfiguration settings, BE language setup, system maintainer management, recovery.

A clean distinction between system maintenance and “rest of the system / backend” also gives us a significant security advantage: The system management application should have no other code dependency than to the “core” extension in the end, and no other core extension should have a dependency to the system management application. Thus, the “system management” does NOT need to exist on live systems if deployments are set up correctly. Not existing code has no security issues :wink: The ongoing efforts on the “git split of core extensions” plays into our hands here.


Topic Initiator: Susi Moog, Benni Mack, Oliver Hader, Mona Muzaffar, Marco Christian Krenn, Christian Kuhn, Philipp Hamid
Topic Mentor: Christian Kuhn


I really like the idea. because this “colorful mixture” of the install tool always bothered me. And moving the tool into two seperate extensions, which can be removed if not needed, is a very nice idea.
We already talked about that and I am absolut in favor of this project.

As lolli mentioned, this topic was started at the UXW17 and was discussed there with a lot of people.
The summary describes perfectly the current state and the solution, +1 for this project.

I really like the approach of admins, who cannot break everything and system maintainers …
The summery sounds great and the gain of clearness and security is really nice!

I’m a bit worried about that part. I consider instances where the authentication may not happen by the instance itself, but by third party services, like LDAP. If for some reason such a connection is broken, the system management is completely inaccessible.

@Markus: Maybe always have database-based users/authentication but have other providers on top, so in case of a failing LDAP we still have the base-users with a password? (I’m aware that people might not want additional/separate passwords in the database.)

The “recovery” part of the system management should take care of that. Currently, on accessing the install tool first the “step installer” is asked if something needs to be rendered. This will be split into two: The “installer” only used for first installation, and a “recovery” called in front of the “system management”: If for instance the be_users table does not exist, the recovery should present a fallback that relies on some magic token in filesystem to be created to gain access to a recovery step recreating the table and adding a be_user. Similar scenarious exist for “forget password”.

1 Like

Thats a great solution to a problem that is that old, that I didn’t even think ever about it. I love the separation in order to get more fine grained access control to certain settings. Further it would be great to have the installer and system management separated on a extension level. So one could decide to turn both things off e.g. on a production system.

1 Like

“Backend admins” would also have access to TypoScript Template?

So if I have understood, there would be distinction between:
“Backend admin” = Site administrator
"System maintainer" = Superultraadmin with all privileges to configure the environment (something like the current admin+install tool access)

@tmaroschik yes, separation of installer / sys management leads to not needing installer after first install, and clean separation of sys management would mean that ext is not needed on prod in the end anymore if deployment is in place and stuff.
@erredeco exactly

+1 from me! This was long due.

I remember that a feature that sometimes I see people asked for in the past is a sort of semi-admin, that is an user that is somehow more powerful than an editor, but less than an omnipotent admin…


This topic was automatically closed after 28 days. New replies are no longer allowed.