Writing records into a shared storage

Writing across site boundaries is rare. A shared storage folder is usually maintained in the backend by the editors of the site that owns it, and read everywhere else. Where an extension does write — a registration form, a submitted proposal — the question is a narrow one: which page does the new record land on?

Where a new record is stored

Extbase resolves the page for a new record in three steps, and stops at the first that supplies a value:

The `pid` property of the object. If the domain object exposes a readable pid and it is set, that page is used. This overrides everything else, so an object that carries a pid decides its own storage page.
`newRecordStoragePid` for the object's class. The TypoScript setting persistence.classes.<FQCN>.newRecordStoragePid names a fixed page for every new record of one domain class. Note that it is keyed by the fully qualified class name of the model, not by the table.
The first entry of the read `storagePid`. With nothing above set, Extbase takes the storagePid it reads from and uses its first page.

Warning

A repository configured to read from several pages writes to whichever page happens to be listed first. In a cross-site setup this might be the shared folder belonging to another site. If then even the default language does not match, you might end up with a record written to shared storage in the wrong language playing at default language.

Pinning the write target

Wherever a repository reads from more than one page, set the write target explicitly rather than relying on list order:

EXT:my_extension/Configuration/Sets/MyExtension/setup.typoscript

plugin.tx_myextension.persistence {

  # 84 is outside the current site
  # 12 is a folder inside the site

  # Read from the shared folder and from the local one.
  storagePid = 84,12

  # Without the setting below, new conferences would be written to page 84 —
  # the first entry of the list above. Pin the write target explicitly.
  classes {
    MyVendor\MyExtension\Domain\Model\Conference {
      newRecordStoragePid = 12
    }
  }
}

This keeps reading and writing independent: the plugin lists conferences from the shared folder and the local one, while new conferences are always created locally.

Deciding the page in PHP instead means giving the model a pid property and setting it before persisting. That suits a target which varies per record — different for each site, or chosen by the visitor — where a single TypoScript value cannot express it.

Hint

The configuration shown above will not concern itself with the different language configuration the previous page Matching languages between sites with locales covers. If reading in different languages is required out of such a setup, make sure in your record resolving to match the storage pids accordingly.

The language of a record written elsewhere

Resolving a language for reading does not carry over to writing. Extbase creates new records as default language records and cannot create translations. That is true whatever page the record lands on. A record written into another site's folder is a default-language record there.

Writing into a folder you do not own

Extbase persistence writes to the database directly rather than through the DataHandler, so no page permission check takes place at all. The storage page is used as given, and the site boundary does not constrain it.

That makes it worth being deliberate about the target. Where records genuinely belong to another site and have to pass through its editorial process, use the DataHandler instead: it enforces permissions, writes a history entry and respects workspaces.