cms-core/Documentation/Changelog/14.0/Feature-107628-ImprovedBackendModuleNamingAndStructure.rst

..  include:: /Includes.rst.txt

..  _feature-107628-1729026000:

===============================================================
Feature: #107628 - Improved backend module naming and structure
===============================================================

See :issue:`107628`

Description
===========

TYPO3 Core's backend module structure has been modernized with clearer,
more intuitive naming conventions that better align with industry
standards used by enterprise content management systems.

Module names should immediately convey their purpose to editors and
administrators. This series of renamings improves clarity,
discoverability, and reduces the cognitive load for both new and
experienced users.

Clear and consistent naming is fundamental to good user experience.
When comparing TYPO3 Core with other enterprise CMS platforms, it became
evident that some of TYPO3 Core's module names were either too technical,
ambiguous, or did not clearly communicate their purpose.

To summarize, the goals of this restructuring are:

*   **Improved clarity**: Module names immediately convey their purpose.
*   **Industry alignment**: Adopt naming conventions familiar to users of
    other enterprise CMS platforms.
*   **Better discoverability**: Help new users find functionality without
    extensive training.
*   **Reduced cognitive load**: Minimize confusion when navigating the
    backend.

Module renamings
================

The following modules have been renamed.

Top-level modules
-----------------

Web => Content
~~~~~~~~~~~~~~

The top-level :guilabel:`Web` module has been renamed to
:guilabel:`Content`.

**Rationale:** TYPO3 is a **content** management system. The primary
workspace where editors create and manage content should be clearly
labeled as such. The term "Web" was ambiguous and did not communicate the
module's purpose. Users outside the TYPO3 ecosystem often did not
understand what "Web" meant in this context.

**Migration:** Update module parent references from :php:`'web'` to
:php:`'content'`:

..  code-block:: php

    return [
        'my_module' => [
            'parent' => 'content',  // Previously: 'web'
        ],
    ];

File => Media
~~~~~~~~~~~~~

The top-level :guilabel:`File` module has been renamed to
:guilabel:`Media`.

**Rationale:** The term "Media" clearly indicates the module's purpose of
managing digital media files (images, videos, documents, audio files,
etc.) within the CMS. The term "File" was too generic and technical,
while "Media" is widely understood and commonly used in content
management systems to refer to digital content assets.

**Migration:** Update module parent references from :php:`'file'` to
:php:`'media'`:

..  code-block:: php

    return [
        'my_module' => [
            'parent' => 'media',  // Previously: 'file'
        ],
    ];


Site Management => Sites
~~~~~~~~~~~~~~~~~~~~~~~~

The top-level :guilabel:`Site Management` module has been renamed to :guilabel:`Sites`.

**Rationale:** The former label "Site Management" was long and formal, and did
not align with TYPO3’s evolving, concise module naming strategy. The
simplified name "Sites" improves scanability in the module menu and matches
the naming of other top-level modules. It also better reflects the purpose
of the module: providing an overview entry point for all configured (web)sites.

**Migration:** The top-level module identifier :php:`site` is kept. No migration
is necessary.

Admin (tools) <=> System
~~~~~~~~~~~~~~~~~~~~~~~~

The top-level module formerly known as :guilabel:`Admin tools` is now
called :guilabel:`Administration`.

The purpose of this top-level module has changed. It now contains those
modules useful to backend administrators, such as user and permission
management, the Scheduler, and Integrations.

Most modules formerly found in :guilabel:`Admin tools` are now located in
:guilabel:`System`.

**Rationale:** The top-level module :guilabel:`Administration` now
contains modules that are used by backend administrators in their daily
work. Modules that require system maintainer permissions are found in the
module named :guilabel:`System`.

**Migration:** Modules generally accessible to backend administrators
should be moved to the top-level module with the identifier `admin`.
Modules that require system maintainer permissions or are mainly useful
to system maintainers and DevOps should be moved to `system`.

..  code-block:: php

    return [
        'my_administration_module' => [
            'parent' => 'admin',  // Previously: 'system'
            'access' => 'admin',
        ],
        'my_maintainer_module' => [
            'parent' => 'system',  // Previously: 'tools'
            'access' => 'systemMaintainer',
        ],
    ];

Second-level modules
--------------------

For modules, where the module identifier changed, the upgrade wizard
"Migrate module permissions" migrates module level group and user permissions.

Page => Layout
~~~~~~~~~~~~~~

The second-level :guilabel:`Page` module has been renamed to :guilabel:`Layout`
to better match its scope.

**Rationale:** The previous module name "Page" did not clearly convey the
module’s purpose or workflow. TYPO3 provides multiple ways to interact with
a page (e.g. structure, properties, preview), and the term "Page" alone did
not describe which aspect was being managed. The renamed module "Layout"
more accurately reflects what editors do inside the module: maintain the
page layout, manage content elements, and organize them into the correct
columns and grids. This provides clearer expectations, improves usability
for new editors, and aligns the module name with modern TYPO3 workflows
and terminology.

**Migration:** Since the module is just renamed, there are no migrations
necessary.

List => Records
~~~~~~~~~~~~~~~

The second-level :guilabel:`List` module has been renamed to
:guilabel:`Records` to better convey its purpose and improve clarity.

**Rationale:** The term "List" is too generic and does not adequately
communicate the module's purpose. While "List" could refer to any kind of
enumeration or overview, the module actually provides structured access to
**database records** appearing on a page. The new name "Records" is more
specific and immediately communicates that this module is about working with
data records—viewing, editing, and managing them at the database level.

The term "Records" also aligns with how the module is already described in
its own interface ("List of database records") and better reflects the
technical nature of the module's functionality. For users coming from other
enterprise CMS platforms or database-driven systems, "Records" is a widely
understood term that clearly indicates low-level data management
capabilities.

This renaming reduces ambiguity and helps users—especially those new to
TYPO3—understand that this module provides direct access to the underlying
record structure, distinguishing it from the more content-focused
:guilabel:`Layout` module.

**Migration:** The module identifier has been renamed from `web_list` to
`records`. An alias is in place. However, use the new identifier when referencing.

..  code-block:: diff

   - $this->uriBuilder->buildUriFromRoute('web_list');
   + $this->uriBuilder->buildUriFromRoute('records');

View => Preview
~~~~~~~~~~~~~~~

The second-level :guilabel:`View` module has been renamed to
:guilabel:`Preview` to better match its scope. It has also been moved one
position down after :guilabel:`Records`, as that module is considered more
important for daily work.

**Rationale:** The term "Preview" is more precise, as it triggers a
frontend preview and cannot be misunderstood as "viewing" a page in the
backend context.

**Migration:** Since the module is already internally referred to as
`page_preview`, no changes in referencing modules are required.

Workspaces => Publish
~~~~~~~~~~~~~~~~~~~~~

The second-level :guilabel:`Workspaces` module has been renamed to
:guilabel:`Publish` to better match its current scope.

**Rationale:** The initially introduced "Workspaces administration" tool
has been reworked to move content through a publishing process in past
versions. For this reason, it is now renamed to "Publish" and
is only visible when inside a workspace.

**Migration:** The module has internally been renamed to `workspaces_publish`.
A module alias is in place, so references to the old `workspaces_admin`
identifier keep working as before, but it is recommended to adapt usages.

The upgrade wizard "Migrate module permissions" migrates backend user and
group-level permissions for this module.

Info, Indexing, Check Links => Status
--------------------------------------

The second-level :guilabel:`Info` module has been renamed to :guilabel:`Status`
to better match its scope. It has also been moved into EXT:backend so it is
always available and displayed if it contains at least one module.

**Rationale:** The module was moved to EXT:backend to make it always available
and to provide a common place for page and site status information.

The renaming to :guilabel:`Status` better reflects its purpose and removes
unnecessary dependencies between informational extensions.

**Migration:** The module identifier has been renamed from `web_info` to
`content_status` an alias is in place. Use the new identifier to place custom
modules.

..  code-block:: diff

     return [
         'my_page_information' => [
    -        'parent' => 'web_info',
    +        'parent' => 'content_status',
         ],
     ];

Extensions placing third level modules into the module now called
:guilabel:`Status` do not need to require :composer:`typo3/cms-info` anymore.

Filelist => Media
~~~~~~~~~~~~~~~~~

The second-level :guilabel:`Filelist` module has been renamed to :guilabel:`Media`
to more accurately reflect its current functionality and scope.

**Rationale:** The former "Filelist" no longer reflected what the module
actually does. Over the years, its scope has evolved from simply listing files
to offering a full set of media-management capabilities. Today, the module is
used to upload and create files and folders, manage metadata, organize assets,
handle online media, and prepare files for use across the CMS.

To make its purpose clearer and more intuitive for editors and integrators,
the module has been renamed to "Media". The new name better represents its
broader functionality, aligns with modern CMS terminology, and makes the
module easier to understand for new users.

**Migration:** Since the module is already internally referred to as `media_management`,
no changes in referencing modules are required.

Sites => Setup
~~~~~~~~~~~~~~~

The second-level :guilabel:`Sites` module has been renamed to :guilabel:`Setup`.

**Rationale:** The old submodule name "Sites" would duplicate the new top-level
name and cause confusion. The new name "Setup" therefore makes the purpose
clearer: It is the place where integrators set up their sites. "Setup"
emphasizes the technical nature of the module and better communicates that
this section defines behavior (languages, domains, routes), not content.

**Migration:** Since the module identifier `site_configuration` is kept, no
changes in referencing modules are required.

Settings => Setup
-----------------

The second level :guilabel:`Settings` module has been integrated into :guilabel:`Setup`.

**Rationale:** Combining the "Setup" and "Settings" gives a more concise view,
since managing sites and site settings are often done as one task.

**Migration:** The module identifier `site_settings` has been removed, the existing
actions :php:`edit`, :php:`save` and :php:`dump` have been renamed to
:php:`editSettings`, :php:`saveSettings` and :php:`dumpSettings` as part of the
`site_configuration` module identifier.

Link Management
~~~~~~~~~~~~~~~

A new second-level :guilabel:`Link Management` module has been introduced
under the :guilabel:`Sites` top-level menu to provide a unified location
for managing URL-related features.

This new module serves as a parent for two third-level modules:

- :guilabel:`Redirects` - The existing redirects module for managing URL redirects
- :guilabel:`QR Codes` - A new module for creating and managing scannable QR codes (see :ref:`feature-107756-1763294102`)

**Rationale:** Grouping these URL management features under a common parent module
creates better organization and discoverability. Both redirects and QR codes deal
with URL handling and link management, making them natural companions in the
module structure. The new parent module provides a logical home for current and
future URL-related functionality.

**Migration:** The existing :guilabel:`Redirects` module, previously a second-level
module under :guilabel:`Site`, has been moved to become a third-level module
under :guilabel:`Sites > Link Management`. The module identifier `site_redirects`
has changed to `redirects`. An alias ensures backward compatibility. Use the new
identifier when registering custom modules.

System > Backend Users => Administration > Users
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The second-level :guilabel:`System > Backend Users` module has been renamed
to :guilabel:`Administration > Users` to better match its scope.

It has also been moved to the top of the to :guilabel:`Administration` top level
menu as it is frequently used by administrators.

**Rationale:** The new name "Users" is shorter and easier to recognize in the
module menu. While "Backend Users" was technically precise, the simpler term
improves readability and usability, making the module easier to find for
administrators performing common user management tasks.

**Migration:** The identifier `backend_user_management` is kept unchanged, no
migration needed.

System > DB Check => System > Database
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The second-level :guilabel:`DB Check` module has been renamed to
:guilabel:`Database` to better reflect its purpose.

**Rationale:** The name "Database" is clearer and avoids the ambiguity of the
abbreviation "DB". The module now focuses solely on search and query
functionality and no longer performs database integrity checks.

**Migration:** The module identifier has changed from `system_dbint` to
`system_database`. An alias ensures backward compatibility. Use the new
identifier when registering custom modules.

..  code-block:: diff

     return [
         'my_database_tool' => [
    -        'parent' => 'system_dbint',
    +        'parent' => 'system_database',
         ],
     ];

.. note::

    The module now exposes its actions "Search query" and "Raw query" through
    the new submodule overview. This gives users clearer, detailed information
    about the purpose of each action.

Impact
======

All renamed module identifiers maintain their previous names as aliases,
ensuring full backward compatibility. Existing code, configurations, and
third-party extensions continue to work without modification.

Developers are encouraged to update their code to use the new identifiers
for consistency and clarity.

The modernized naming improves the overall user experience by making the
backend more intuitive and easier to navigate, particularly for users
familiar with other enterprise CMS platforms.

..  index:: Backend, PHP-API, ext:backend, ext:core