---
title: "Reading localized records across site boundaries"
manual: "TYPO3 Explained"
version: "main"
permalink: "https://docs.typo3.org/permalink/t3coreapi:extbase-cross-site@main"
source: "ExtensionArchitecture/Extbase/CrossSiteAccess/Index.rst"
rendered: "2026-09-26T10:15:30+00:00"
---

# Reading localized records across site boundaries {#extbase-cross-site}

An Extbase plugin normally reads records that belong to the site displaying
them. The storage folder sits in the site's own page tree, the language comes
from the site being rendered, and the two agree because they describe the same
site.

As soon as the records are stored outside the current site, they might stop
agreeing on their language configuration. A company-wide list of conferences is
maintained once and shown on every brand site. A group of country sites shares
one product catalogue. A campaign site displays the news of the main site
without maintaining its own. In each case a plugin reads records that belong to
a *different* site than the one being rendered.

There is no separate concept to learn for this. A shared storage folder is not
a special kind of folder — **any site becomes a shared storage the moment
another site takes an interest in what it holds.** What changes is only that
the records and the reader no longer come from the same site configuration.

## Why a wider `storagePid` might not be enough {#extbase-cross-site-why-not-storagepid}

The obvious move is to point the
[storagePid](https://docs.typo3.org/permalink/t3coreapi:extbase-persistence-storagepid@main) at the other site's folder.
That part does work: the storagePid is a plain list of page UIDs and nothing
constrains it to the current site's page tree.

Where every site involved uses the same language UIDs and the same
`fallbackType`, cross-site reading needs no special attention at all — point
the storagePid at the folder and you are done. This chapter is about the case
where that assumption does not hold, and about not depending on it silently
when it happens to.

The storagePid is the only part of the query that
follows your instruction. Everything else Extbase adds to that query is taken
from the site being rendered:

-   **The language UID** comes from the rendered site. Language UIDs are
    assigned per site and mean nothing outside it. Language `2` may be Polish
    in one site and Italian in another, while the records in the storage folder
    carry one `sys_language_uid` for every reader.
-   **The \`fallbackType\`** comes from the rendered site too. The same record
    can be visible on one site and hidden on another, purely because their
    language configurations differ.

Extbase follows the site being rendered, which is exactly
what it should do when the records belong to that site. Once they do not, the
extension has to supply what the site configuration can no longer be trusted
to provide.

## What this chapter covers {#extbase-cross-site-what-you-need}

**[Reading records stored in another site](https://docs.typo3.org/permalink/t3coreapi:extbase-cross-site-reading@main)**

Finding the storage pages of another site and querying them,
including the case where the folder lies outside the current site's
page tree entirely.

**[Matching languages between sites](https://docs.typo3.org/permalink/t3coreapi:extbase-cross-site-locales@main)**

Resolving *which language to ask for* when the UIDs differ between
sites, and what to do when the two sites' fallback configurations disagree.

**[Writing records into a shared storage](https://docs.typo3.org/permalink/t3coreapi:extbase-cross-site-writing@main)**

Where a new record lands when a repository reads from more than one
site, and how to pin that target deliberately.

> [!NOTE]
> **See also**
>
> -   [The storagePid: where Extbase looks for records](https://docs.typo3.org/permalink/t3coreapi:extbase-persistence-storagepid@main)
>     — how the storage pages are resolved in the ordinary, single-site case.
> -   [Localization in Extbase](https://docs.typo3.org/permalink/t3coreapi:extbase-localisation@main) —
>     how language handling works before site boundaries complicate it.