---
title: "Important: Contacts sharing a sorting value keep a stable order"
manual: "Academic Contacts for Pages"
version: "main"
permalink: "https://docs.typo3.org/permalink/fgtclb/academic-contacts4pages:important-contacts-sharing-a-sorting-value-keep-a-stable-order@main"
source: "Changelog/2.4/Important-ContactsSharingASortingValueKeepAStableOrder.rst"
rendered: "2026-10-26T19:20:19+00:00"
---

# Important: Contacts sharing a sorting value keep a stable order {#important-contacts-sharing-a-sorting-value-keep-a-stable-order}

## Description {#description}

The contacts of a page were ordered by `sorting` alone. Contacts sharing
a value were therefore returned in whatever order the database chose, and
PostgreSQL, which promises no order without an `ORDER BY`, can hand them
back differently from one request to the next.

The page form does not produce such a tie, it renumbers the contacts of a
page on every save. Ties come from:

-   contacts of one page kept in different storage folders, because a new
    record is numbered within its folder while the query ignores the folder a
    contact lives in,
-   contacts copied along with a contract or a contacts role, which keep the
    value they had,
-   imports,
-   contacts written before the sort columns of
    [Important: Contracts and contacts roles sort their contacts on their own](https://docs.typo3.org/permalink/fgtclb/academic-contacts4pages:important-contract-and-role-sort-their-contacts@main) existed, when saving
    a contract or a contacts role renumbered `sorting` across pages.

`\FGTCLB\AcademicContacts4pages\Domain\Repository\ContactRepository::findByPid()`
now orders by `sorting` with `uid` settling ties.

## Impact {#impact}

The contacts content element and the page contacts data processor show the
same list on every request. Contacts with distinct `sorting` values keep
the order an editor arranged. Only the relative order within a tie is pinned.
SQLite, MySQL and MariaDB return such a tie in `uid` order in practice, so
installations on them are not expected to see a change. Nothing in those
databases promises that order, which is why it is pinned now. TYPO3 v12 and v13
behave alike here.

## Affected Installations {#affected-installations}

Every installation of this extension, observably those on PostgreSQL.