Feature: Records of any table in a seed definition 

Description 

A seed definition can now declare records of any table on a page, through the structural key records. Until now a definition expressed pages (children), content elements (content) and the children of a relation (inline) — so the page tree of a development instance could be seeded, but not the data a plugin on it reads.

A record under records declares the table it belongs to itself, exactly as an inline child does:

pages:
  - identifier: persons-storage
    title: 'Persons'
    doktype: 254
    records:
      - identifier: profile-doe
        table: tx_academicpersons_domain_model_profile
        first_name: 'Jane'
        last_name: 'Doe'
        inline:
          contracts:
            - identifier: contract-doe
              table: tx_academicpersons_domain_model_contract
              position: 'Professor'

The structural keys of the format are therefore identifier, uid, children, content, records, files and inline, plus table on an inline or records child.

A record declared this way is a record like any other: it may declare a uid, carry files and carry inline children, and its pid is the page that declares it. Declaration order is kept per table, so records of several tables on one page do not disturb each other's sorting.

Relations to seeded records 

A relation is expressed by declaring the uid of the target and writing it into the relation field. DataHandler resolves the rest, including MM relations, whose rows go into a table the seeding never names:

records:
  - identifier: category-news
    table: sys_category
    uid: 4711
    title: 'News'

categories: 4711

Where records may appear 

records is structure on a page and an ordinary field everywhere else. tt_content has a column of that name — the one the Insert records element writes tt_content_<uid> into — so the key is decided per level, exactly as table is. Declaring records on a content element therefore writes a field and nests nothing.

Impact 

Existing seed definitions are unaffected: the key is new, and on the level where it could collide with a column it keeps being a column. A development instance can now be rebuilt from nothing including its records, rather than including only the pages around them.