---
title: "Module data object"
manual: "TYPO3 Explained"
version: "main"
permalink: "https://docs.typo3.org/permalink/t3coreapi:backend-module-data-object@main"
source: "ApiOverview/Backend/BackendModules/ModuleDataObject.rst"
rendered: "2026-09-24T12:36:55+00:00"
---

# Module data object {#backend-module-data-object}

The `\TYPO3\CMS\Backend\Module\ModuleData` object contains the user
specific module settings, for example whether the clipboard is shown,
for the requested module. Those settings
are fetched from the user's session. A PSR-15 middleware automatically
creates the object from the stored user data and attaches it to the PSR-7 Request.

The `\TYPO3\CMS\Backend\Module\ModuleData` object is available as
attribute of the PSR-7 Request - in case a TYPO3 backend module is requested -
and contains the stored module data, which might have been overwritten
through the current request (with `GET` / `POST`).

Through the module registration one can define, which properties can
be overwritten via `GET` / `POST` and their default value.

The whole determination is done before the requested route target - usually
a backend controller - is called. This means, the route target can
read the final module data.

The *allowed* properties are defined with their default value in the
[module registration](https://docs.typo3.org/permalink/t3coreapi:backend-modules-configuration@main):

**EXT:my_extension/Configuration/Backend/Modules.php**

```php
'moduleData' => [
    'allowedProperty' => '',
    'anotherAllowedProperty' => true,
],
```

**EXT:my_extension/Classes/Controller/MyController.php**

```php
$MOD_SETTINGS = $request->getAttribute('moduleData');
```

The `ModuleData` object provides the following methods:

| Method | Parameters | Description |
| --- | --- | --- |
| createFromModule() | `$module` `$data` | Create a new object for the given module, while overwriting the default values with `$data`. |
| getModuleIdentifier() |  | Returns the related module identifier |
| get() | `$propertyName` `$default` | Returns the value for `$propertyName`, or the `$default`, if not set. |
| set() | `$propertyName` `$value` | Updates `$propertyName` with the given `$value`. |
| has() | `$propertyName` | Whether `$propertyName` exists. |
| clean() | `$propertyName` `$allowedValues` | Cleans a single property by the given allowed list and falls back to either the default value or the first allowed value. |
| cleanUp() | `$allowedData` `$useKeys` | Cleans up all module data, which are defined in the given allowed data list. Usually called with `$MOD_MENU` in a controller with module menu. |
| toArray() |  | Returns the module data as `array`. |

In case a controller needs to store changed module data, this can still be done
using `$backendUser->pushModuleData('my_module', $this->moduleData->toArray());`.

> [!NOTE]
> It is possible to store and retrieve arbitrary module data. The
> definition of `moduleData` in the module registration only defines,
> which properties can be overwritten in a request (with `GET` / `POST`).

To restrict the values of module data properties, the given `ModuleData`
object can be cleaned, for example, in a controller:

**EXT:my_extension/Classes/Controller/MyController.php**

```php
$allowedValues = ['foo', 'bar'];
$this->moduleData->clean('property', $allowedValues);
```

If `ModuleData` contains `property`, the value is checked
against the `$allowedValues` list. If the current value is valid,
nothing happens. Otherwise the value is either changed to the default
or if this value is also not allowed, to the first allowed value.