---
title: "Important: The select item helper passes an empty row"
manual: "Academic Base"
version: "main"
permalink: "https://docs.typo3.org/permalink/fgtclb/academic-base:important-select-item-helper-passes-an-empty-row@main"
source: "Changelog/2.4/Important-SelectItemHelperPassesAnEmptyRow.rst"
rendered: "2026-10-17T08:47:46+00:00"
---

# Important: The select item helper passes an empty row {#important-select-item-helper-passes-an-empty-row}

## Description {#description}

`\FGTCLB\AcademicBase\Event\ModifyTcaSelectFieldItemsEvent` declared the
parameter `row` as always present. In the backend form it is, because
TYPO3 hands the record being edited to every `itemsProcFunc`.

`GetSelectItemsForTcaManagedTableFieldMethodTrait::getSelectItemsForTcaManagedTableField()`
calls the `itemsProcFunc` of a field outside the backend form, and the
job form of [`fgtclb/academic-jobs`](https://packagist.org/packages/fgtclb/academic-jobs) builds the options of its fields
**Job Type** and **Employment Type** with it. There is no
record there, and the helper passed no `row` at all. A listener of the
event that read `$parameters['row']` without a fallback raised the
warning `Undefined array key "row"` in the job form, and the job form failed
where warnings are turned into exceptions, as with the debug preset.

Two changes resolve that:

-   The helper passes `row` as an empty array.
-   The event, and the item providers `TypeItems` and
    `EmploymentTypeItems` of [`fgtclb/academic-jobs`](https://packagist.org/packages/fgtclb/academic-jobs), declare
    `row` optional in their parameter shape, `row?:`, so static
    analysis reports a listener that reads it without a fallback.

## Impact {#impact}

A listener that reads `$parameters['row']` itself gets an empty array in
the job form now instead of a warning. A listener that reads a field of the
row, such as `$parameters['row']['pid']`, still raises a warning there,
`Undefined array key "pid"`, because the empty row has no fields. Read the
row and every field of it with a fallback:

```php
$row = $parameters['row'] ?? [];
$pageId = (int)($row['pid'] ?? $parameters['effectivePid']);
```

The backend form passes the record as before. Nothing changes for a listener
that reads the row with a fallback already, unless it tells the job form apart
by a missing row, with `isset($parameters['row'])`,
`array_key_exists('row', $parameters)` or
`($parameters['row'] ?? null) === null`. Such a check takes the backend
branch in the job form now. Check for an empty row instead:

```php
$isJobForm = ($parameters['row'] ?? []) === [];
```

A project that runs static analysis over its listeners may see a new report
about the offset `'row'` where a listener reads the row without a
fallback. That report points at the code that failed in the job form.

## Affected Installations {#affected-installations}

Installations with a listener of
`\FGTCLB\AcademicBase\Event\ModifyTcaSelectFieldItemsEvent` that reads
`$parameters['row']`, and that use the job form of
[`fgtclb/academic-jobs`](https://packagist.org/packages/fgtclb/academic-jobs) or call the helper in an own controller.