---
title: "Breaking: The plugins call different repository finders"
manual: "Academic Profiles"
version: "main"
source: "Changelog/3.0/Breaking-ProfileAndContractFinderSignatures.rst"
rendered: "2026-09-22T18:32:44+00:00"
---

# Breaking: The plugins call different repository finders {#breaking-profile-and-contract-finder-signatures}

> [!NOTE]
> **See also**
>
> [Upgrading from 2.4 to 3.0.0](../../Upgrade/Index.html#upgrade) is the order in which the 3.0 changes have to be applied.

## Description {#description}

The plugins hand the context they render in to the repositories, so that a
listener of [the new query events](Feature-ProfileAndContractQueryEvents.html#feature-profile-and-contract-query-events)
knows which plugin asked. Three finders are involved:

| Method | 3.0 |
| --- | --- |
| `ProfileRepository::findByDemand()` | takes an optional trailing `?PluginControllerActionContextInterface $context = null` |
| `ProfileRepository::findByUids()` | unchanged, and no longer called by the selected-profiles plugin |
| `ContractRepository::findByUids()` | unchanged, and no longer called by the selected-contracts plugin |

The two uid lookups keep their signature deliberately. Their callers now use
`findByUidsWithContext()` next to them, which differs in nothing but the
context it passes on; `findByUids()` delegates to it without one.

The context is
`\FGTCLB\AcademicBase\Domain\Model\Dto\PluginControllerActionContextInterface`
of **academic_base**, not the interface of the same name this extension
ships. The latter is the former minus `getContentObjectRenderer()` and is
the one that goes away in a later major version, so new API is typed against
the shared one. The events of the controller actions are untouched.

## Impact {#impact}

**A subclass or XCLASS that overrides** `ProfileRepository::findByDemand()`
**is a fatal error until it adds the parameter.** PHP refuses an override with
a narrower signature, so the installation breaks on the first request after the
update rather than silently.

**An override of either** `findByUids()` **keeps loading and stops being
asked.** The method is still there and still does what the override makes it
do, but the selected-profiles and selected-contracts plugins do not go through
it any more. Nothing reports this: the plugins simply render what the
repository would have returned without the override.

Callers of the three finders that do not override them are unaffected — the
new parameter has a default, and the two uid lookups did not change at all.

## Affected Installations {#affected-installations}

Installations whose own code extends `ProfileRepository` or
`ContractRepository`, by a subclass registered as an Extbase repository or
by an XCLASS. That is the shape the customizations of 2.x used to narrow what
the plugins show, and it is what the query events replace.

## Migration {#migration}

1.  Add the parameter to an override of `findByDemand()`:

    ```php
    public function findByDemand(
        DemandInterface $demand,
        ?PluginControllerActionContextInterface $context = null,
    ): QueryResultInterface {
    ```
1.  Move what the override does to a listener of
    `ModifyProfileQueryEvent` or `ModifyContractQueryEvent`, and drop
    the override. A condition an override added to the query is a constraint
    the listener adds, and it then applies to every plugin instead of only the
    ones that happen to call the overridden method — pagination included.
1.  An override of `findByUids()` has no other way back into the
    plugins. Either move it to a listener, or accept that it only serves the
    callers of that method.