[BUG] Error when moving Metadata records in Backend List

[fschoelzel]

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:

1. add default Metadata records with the "New Tenant" Module
2. Click on the Arrow "Move up in list" / "Move down in list"
3. see TYPO3\CMS\Core\Error\Exception
4. 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

[beatrycze-volk]

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

[beatrycze-volk]

Generally the problem disappears after adjustment in TCA:

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

[fschoelzel]

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:

[beatrycze-volk]

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?

[michaelkubina-subhh]

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.

[sebastian-meyer]

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.