[BUG] Error when moving Metadata records in Backend List

Description

The Error occur in Kitodo.Presentation Backend, when moving Metadata records "up" or "down" in the list.
Although the action works in the End and the Item moves in List, the Error shows up.

(1/1) #1476107295 TYPO3\CMS\Core\Error\Exception

PHP Warning: Undefined array key "l18n_parent" in /var/www/html/vendor/typo3/cms-core/Classes/DataHandling/DataHandler.php line 2822

Reproduction

Steps to reproduce the behaviour:

add default Metadata records with the "New Tenant" Module
Click on the Arrow "Move up in list" / "Move down in list"
see TYPO3\CMS\Core\Error\Exception
Exit the page -> the action works and the Item has moved

Expected Behavior

No Exception Page

Screenshots and Examples

Environment

Kitodo.Presentation main Branch (older Commit d692d7 and newer w. v13 support 771880)
RDBMS version: MariaDB 10.11
TYPO3 version: 12.4.36
PHP version: 8.2

The error comes directly from TYPO3 Framework.

The variable $this->checkValue_currentRecord is an empty array. I have traced all assignments to this array and during the move operation it is not assigned, only accessed:

if (($GLOBALS['TCA'][$table]['columns'][$field]['l10n_mode'] ?? '') === 'exclude') {
    $transOrigPointerField = $GLOBALS['TCA'][$table]['ctrl']['transOrigPointerField'];
    $l10nParent = (int)$this->checkValue_currentRecord[$transOrigPointerField];
     if ($l10nParent > 0) {
        // Current record is a translation and l10n_mode "exclude" just copies the value from source language
        return $value;
    }
}

Generally the problem disappears after adjustment in TCA:


index_name' => [
            'exclude' => 0,
            'l10n_mode' => '',

@beatrycze-volk

Hello @beatrycze-volk,
now i have the same Problem as before, when i changed the 'l10n_mode'.
It don't accept that the translation field has the same index_name as the l10n_parent.
So it changes the index_name of the translated child if i move a field in the Backend. I think this is not how it supposed to be.
(excuse the non translated labels)
See Screenshot:

It should not be so, I have tested solution on the system without translations. Do you have some idea how it can be solved differently?

We were looking at translations as well, but in another context....and also came across the issue with the index_name. I believe the issue is more, how Kitodo.Presentation handles translations in general. From my observation we kind of hard-code localization for a subset of tables, resulting in these issues.

Not that far with actual testing yet, but what i did experiment with, was to setup a page-translation for the storage folder:

After that, records can be localized via a click of a button:

When doing this for a metadata record for example, this does not result in a `index_name0` but we get a shared `index_name`

Moving the entry up, does result in an exception at the moment:

But within the hierarchy it actually does get moved, without the `index_name` being an issue:

The entry in the database looks ok to me at first glance:

Creating entries with via New Tenant does still work this way, and moving them does not result in the index_name issue anymore, but only said exception. Also this way has the benefit, that we can actually localize any table...which we now would not...or at least, which would not be possible without a page-localization of the storage folder. This means, we wold also be able to localize collections (and their descriptions!!), or library names and everything else.

So, from what i believe, its partially a configuration / usage error...but we also dont provide instructions, on how to properly set up the Host, in order to utilize translations well.

Maybe we can find a way to resolve the localization not being resolved to the fullest (collections & libraries not being translated at the moment), by instructing the usage of a storage-folder localization and working with it throughout our portal..this would require some bug-fixing, adjustments to the TCA's and a clear instruction on how to setup a multilingual site.

Maybe we can find a way to resolve the localization not being resolved to the fullest (collections & libraries not being translated at the moment), by instructing the usage of a storage-folder localization and working with it throughout our portal..this would require some bug-fixing, adjustments to the TCA's and a clear instruction on how to setup a multilingual site.

Great observations! And yes, I think that's exactly the way it's intended by TYPO3.

@michaelkubina-subhh

The Description of @michaelkubina-subhh is exactly the behavior as i initially opened this Issue.

Before Bugfix (2026-01-20T15:12:22): I had the Exception Error - but Element got moved without updating the index_name
After Bugfix from @beatrycze-volk, see: [BUGFIX] Fix moving metadata in backend #1801 , the Element is moved but with the problem updating the index_name (now without the Exception Error)

@michaelkubina-subhh I'm curious, do you tested the behavior on the latest version of the main branch?

@fschoelzel

@fschoelzel hi, yes, i have tested the behaviour with the latest version of the main branch. i was not aware, that you have had setup a site languages as well... but now, that i think of it...how else could the index_name have been duplicated.

Sorry, if i cause confusion here... i think we are all on the same page now.

datahandler issue

@beatrycze-volk has identified the datahandler as being an issue and that there seems to be no l18n_parent being retrieved. I believe this is actually a typo3 bug and has nothing to do with our configuration ... forcing the retrieval of the parent from the database makes the exception go away:

$schema = $this->tcaSchemaFactory->get($table);
        $tcaField = $schema->getField($field);
        if ($tcaField->getTranslationBehaviour() === FieldTranslationBehaviour::Excluded && $schema->isLanguageAware()) {
            $transOrigPointerField = $schema->getCapability(TcaSchemaCapability::Language)->getTranslationOriginPointerField()->getName();

// TEST: load 'l18n_parent' from db
            if (!isset($this->checkValue_currentRecord[$transOrigPointerField]) && $id > 0) {
                $record = BackendUtility::getRecord($table, $id, $transOrigPointerField);
                if ($record && isset($record[$transOrigPointerField])) {
                    $this->checkValue_currentRecord[$transOrigPointerField] = $record[$transOrigPointerField];
                }
            }
// END TEST

            $l10nParent = (int)$this->checkValue_currentRecord[$transOrigPointerField];
            if ($l10nParent > 0) {
                // Current record is a translation and l10n_mode "exclude" just copies the value from source language
                return $value;
            }
        }

uniqueInPid's role

Also, simply removing uniqueInPid from eval (without any changes to the original datahandler), makes the exception go away as well! So, its simply not possible to use 'l10n_mode' => 'exclude' and 'eval' => 'uniqueInPid' at the same time - even more evidence, that it might be a typo3 bug.

what now?

Setting the l10n_mode of index_name to exclude, is the right way to do it. Because we (should) want the index_name to stay the same for translations no matter what. Without it multilingual setups run into issues of index_name copies with appended counter. Also handling these index_name copies in code is bad practice...as its happending in the translate() helper, which also would fail for sites with more then two languages as it only looks at index_names with a 0 (zero) appended.
We could remove uniqueInPid temporarily to make the exception go away. But this way users can potentially create index_name collisions. But we could then also at least provide a 'description' => 'some statement, that the index_name must be unique per folder' to soften the risk.
I will file an issue in the typo3 bugtracker, describing the problem with both configurations not being possible at the same time as well as how the datahandler is missing the localization parent. Maybe their response can help, wether we are doing something fundamentally wrong or if the assumption is correct, that theres an actual bug in typo3.

Filed an issue on the Typo3 bugtracker:
https://forge.typo3.org/issues/108994

Thank you!

Navigation Menu

[BUG] Error when moving Metadata records in Backend List #1715

Description

Reproduction

Expected Behavior

Screenshots and Examples

Environment

Not that far with actual testing yet, but what i did experiment with, was to setup a page-translation for the storage folder:

After that, records can be localized via a click of a button:

When doing this for a metadata record for example, this does not result in a `index_name0` but we get a shared `index_name`

Moving the entry up, does result in an exception at the moment:

But within the hierarchy it actually does get moved, without the `index_name` being an issue:

The entry in the database looks ok to me at first glance:

datahandler issue

uniqueInPid's role

what now?

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[BUG] Error when moving Metadata records in Backend List #1715

Description

Description

Reproduction

Expected Behavior

Screenshots and Examples

Environment

Activity

beatrycze-volk commented on Sep 4, 2025

beatrycze-volk commented on Sep 4, 2025

fschoelzel commented on Jan 29, 2026

beatrycze-volk commented on Jan 29, 2026

michaelkubina-subhh commented on Jan 30, 2026

Not that far with actual testing yet, but what i did experiment with, was to setup a page-translation for the storage folder:

After that, records can be localized via a click of a button:

When doing this for a metadata record for example, this does not result in a index_name0 but we get a shared index_name

Moving the entry up, does result in an exception at the moment:

But within the hierarchy it actually does get moved, without the index_name being an issue:

The entry in the database looks ok to me at first glance:

sebastian-meyer commented on Jan 30, 2026

fschoelzel commented on Feb 2, 2026

michaelkubina commented on Feb 11, 2026

datahandler issue

uniqueInPid's role

what now?

michaelkubina commented on Feb 17, 2026

sebastian-meyer commented on Feb 17, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

When doing this for a metadata record for example, this does not result in a `index_name0` but we get a shared `index_name`

But within the hierarchy it actually does get moved, without the `index_name` being an issue: