DayRecordService sets incorrect `l10n_parent` for translated day records

[SvenJuergens]

hi @sfroemkenjw

seems i had found a bug in last 10.0.6 Version. Made a TYPO3 update from 12 (with events 9) to 13 (with events2 10).
After the update, some editor saved an event in the backend and the problems came 🙈

At first, I thought it was due to our extensions for events2, but in this case, it seems to be a bug in events2. The problem was that when I opened the page in English and then clicked on an entry in the event list, only the German version of the event was displayed.

I searched for a while and then got some help from AI, and this is what I found. And yes, the report here is AI-generated. 🙈

Description

When generating day records for translated events, the l10n_parent field is set incorrectly. This causes the language overlay mechanism in TYPO3/Extbase to fail, resulting in the default language content being displayed on translated pages instead of the translated content.

TYPO3 / events2 Version

• TYPO3: 13.4
• events2: 10.0.6

Steps to Reproduce

1. Create a new event in default language (e.g., German, uid=1)
2. Save the event → Day records are generated correctly
3. Create a translation of the event (e.g., English, uid=2)
4. Run the CLI command typo3 events2:rebuild OR save the original event again
5. Check the l10n_parent value of the translated day record in the database

Expected Result:

The translated day record should have l10n_parent pointing to the corresponding default language day record.

Day uid=7 (German): l10n_parent=0, event=1, def_lang_event_uid=1
Day uid=8 (English): l10n_parent=7, event=2, def_lang_event_uid=1  ← CORRECT

Actual Result:

The translated day record has an incorrect l10n_parent value that points to an unrelated day record.

Day uid=3582 (German): l10n_parent=0, event=568, def_lang_event_uid=568
Day uid=3583 (English): l10n_parent=1, event=570, def_lang_event_uid=568  ← WRONG!

The l10n_parent=1 points to a day record of a completely different event instead of l10n_parent=3582.

Impact

When viewing the detail page of a translated event, TYPO3's language overlay fails because l10n_parent points to the wrong record. As a result:

• The default language content is displayed on translated pages
• The translation appears to not exist from TYPO3's perspective

Root Cause Analysis

The bug is located in Classes/Service/Record/DayRecordService.php in the method createVersionRecords().

Problematic Code (lines 122-131):

$dayRecordsInDefaultLanguage = [];
if ($languageUid > 0) {
    $dayRecordsInDefaultLanguage = $connection->select(
        ['*'],
        self::TABLE,
        [
            'sys_language_uid' => 0,
            't3ver_wsid' => $this->getWorkspaceUidFromBackendUser(),
        ],
    )->fetchAllAssociative();
}

This query fetches ALL day records in the default language from the entire database, not just the ones belonging to the current event ($eventUid).

Then in enrichNewDayRecords() (lines 211-216):

$l10nParent = array_key_exists(
    $newDayRecordKey,
    $dayRecordsInDefaultLanguage,
) ? (int)$dayRecordsInDefaultLanguage[$newDayRecordKey]['uid'] : 0;

The $newDayRecordKey is the array index (0, 1, 2, ...) of the new day records being created. This index is used to look up the l10n_parent from $dayRecordsInDefaultLanguage. Since this array contains ALL default language days (not filtered by event), it returns the wrong UID.

Example scenario:

• Database has 100 events with day records
• Event uid=568 has 1 day record (uid=3582 in default language)
• When creating translated day records for event 568:
  • $dayRecordsInDefaultLanguage contains ALL ~200 default language days
  • $newDayRecords has index 0 for the single day
  • $dayRecordsInDefaultLanguage[0] returns uid=1 (first day in DB, belongs to different event!)
  • Result: l10n_parent is set to 1 instead of 3582

Proposed Fix

Filter the query by def_lang_event_uid to only fetch day records belonging to the current event:

$dayRecordsInDefaultLanguage = [];
if ($languageUid > 0) {
    $dayRecordsInDefaultLanguage = $connection->select(
        ['*'],
        self::TABLE,
        [
            'sys_language_uid' => 0,
            't3ver_wsid' => $this->getWorkspaceUidFromBackendUser(),
+           'def_lang_event_uid' => $eventUid,
        ],
    )->fetchAllAssociative();
}

This ensures that only day records for the current event are considered when setting the l10n_parent value.

Workaround

Until a fix is released, affected installations can repair the l10n_parent values with this SQL query:

UPDATE tx_events2_domain_model_day d_translated
JOIN tx_events2_domain_model_day d_default
    ON d_default.def_lang_event_uid = d_translated.def_lang_event_uid
    AND d_default.sys_language_uid = 0
    AND d_default.day_time = d_translated.day_time
SET d_translated.l10n_parent = d_default.uid
WHERE d_translated.sys_language_uid > 0;

Additional Notes

• The bug only manifests when there are multiple events in the database
• Fresh installations with only one event may not notice the issue initially
• The bug affects the events2:rebuild CLI command as well as saving events in the backend