---
title: "Important: Remaining unordered queries now order by uid"
manual: "Academic Profiles"
version: "main"
permalink: "https://docs.typo3.org/permalink/fgtclb/academic-persons:important-remaining-unordered-queries-order-by-uid@main"
source: "Changelog/2.4/Important-RemainingUnorderedQueriesOrderByUid.rst"
rendered: "2026-10-15T10:24:29+00:00"
---

# Important: Remaining unordered queries now order by uid {#important-remaining-unordered-queries-order-by-uid}

## Description {#description}

Besides the profile queries of
[Important: Unordered profile queries now order by uid](https://docs.typo3.org/permalink/fgtclb/academic-persons:important-unordered-queries-order-by-uid@main), five more query paths returned
rows in whatever order the database yielded:

-   `ContractRepository::findAll()`, which builds the contract select
    items in the backend (TCA `itemsProcFunc` and FlexForm) where no
    storage pages restrict them
-   `ContractRepository::findByUids()`, which resolves the contracts of
    the "selected contracts" plugin
-   `ProfileRepository::findByUids()`, which resolves the profiles of the
    "selected profiles" plugin
-   `ProfileRepository::findByFrontendUser()`, which resolves the profiles
    of a frontend user for the frontend editing of
    `EXT:academic_persons_edit`
-   `ProfileRepository::findByDemand()` with a non-empty demanded
    ordering, the **Sort By** option of the list plugin, which carried
    no tiebreaker. Profiles equal in it (two people sharing a last name) had
    no defined relative order.

The first four now order by `uid` ascending. The demanded ordering keeps
winning and gets `uid` ascending appended as a tiebreaker.

## Impact {#impact}

No visible change is expected on SQLite, MySQL and MariaDB: `uid` ascending
is the order they return in practice, and it is guaranteed now rather than
coincidental. PostgreSQL promises no order without one, so an installation on it
may see such a list change once.

For the two uid selection methods the order of the editor's selection is
deliberately **not** reproduced. `in()` does not preserve it, and it was
never delivered before. Honouring the selection order would be a behaviour
change beyond making the lists reproducible.

## Affected Installations {#affected-installations}

Every installation of this extension.