---
title: "Breaking: #101948 - File-based AbstractRepository class removed"
manual: "TYPO3 Core Changelog"
version: "main"
permalink: "https://docs.typo3.org/permalink/changelog:breaking-101948-1695118827"
source: "Changelog/13.0/Breaking-101948-FileBasedAbstractRepositoryClassRemoved.rst"
typo3-version: "13.0"
typo3-major: 13
type: "breaking"
issue: 101948
forge: "https://forge.typo3.org/issues/101948"
tags: ["FAL", "PHP-API", "PartiallyScanned", "ext:core"]
rendered: "2026-10-03T08:19:36+00:00"
---

# Breaking: #101948 - File-based AbstractRepository class removed {#breaking-101948-1695118827}

See [forge#101948](https://forge.typo3.org/issues/101948)

## Description {#description}

When the base architecture of File Abstraction Layer (FAL) was introduced in
TYPO3 v6.0, various functionality was based on concepts based on Extbase's
architecture. Some concepts never flourished. One of them being the
`\TYPO3\CMS\Core\Resource\AbstractRepository` class from FAL.

This PHP class served as a basis for 2 PHP classes,
`\TYPO3\CMS\Core\Resource\FileRepository` and
`\TYPO3\CMS\Core\Resource\ProcessedFileRepository`.

Nowadays, it is obvious that some decisions in this area were not useful:

1\. The coupling to Extbase's repository architecture does not work out, as the
manual database queries that return objects should not be bound to Extbase's
QueryRestrictions.

These never worked and were never implemented in the mentioned repository
classes from FAL.

It becomes abundantly clear that the concepts do not match by looking at the
`AbstractRepository` class which even had exceptions for methods that were
not compatible with Extbase.

2\. The concept of inheritance did not work out for Dependency Injection
introduced in TYPO3 v10, and with PHP 8.x which reveals various typing problems
that arose around `AbstractRepository`.

`AbstractRepository` is thus removed, and the implementing classes do not
extend from this class anymore, as they only include the methods required for
their purpose, and are now completely strictly typed.

Additionally, `FileRepository` has been cleaned up by removing
`findFileReferenceByUid()` as it is only a wrapper to
`ResourceFactory::getFileReferenceObject()`

## Impact {#impact}

Code that uses the three classes in a third-party extension might fail as the
implementing PHP repositories `FileRepository` and
`ProcessedFileRepository` have only necessary methods available.

PHP extensions that derive from the `AbstractRepository` will stop working.

Code that used `FileRepository::findFileReferenceByUid()` will break.

## Affected installations {#affected-installations}

As all three PHP classes are low-level in the FAL API, the impact for regular
installations will be rather low. Third-party extensions that extend from the
`AbstractRepository` of FAL, which is a wild use-case will stop working. It is
safe to say, that only edge-case extensions that worked with the FAL API might
be affected, but regular installations will see no difference.

## Migration {#migration}

Only extension authors working with the low-level API of File Abstraction Layer
would need to adapt their code to be type-safe. Extensions that extend from the
`AbstractRepository` class of FAL should implement the necessary methods
themselves and remove the dependency from `AbstractRepository`.

It is highly recommended to not use any of these classes, but rather stick
to high-level API of FAL, such as `ResourceFactory`, `File`
or `ResourceStorage`.

Replace former calls to `FileRepository::findFileReferenceByUid()` like:

```php
$fileRepository = GeneralUtility::makeInstance(FileRepository::class);
$reference = $fileRepository->findFileReferenceByUid($referenceUid);
```

by using the `ResourceFactory` with new code like:

```php
$resourceFactory = GeneralUtility::makeInstance(ResourceFactory::class);
$reference = $resourceFactory->getFileReferenceObject($referenceUid);
```

> [!NOTE]
> Ideally use dependency injection instead of `GeneralUtility::makeInstance()` to
> retrieve the instance for `ResourceFactory`.