Pods Repeater Field — repeatable field groups as a field type (alpha)

[phoenixseo]

Pods can repeat a single value. It cannot repeat a group of fields. I built
the missing piece as a standalone field type, and I am posting it here because
this is the shape of answer the "Repeatable Field Groups" threads have been
missing.

GitHub: https://github.com/phoenixseo/pods-repeater
Release: https://github.com/phoenixseo/pods-repeater/releases/tag/v0.3.0-alpha

What it does

Define a set of sub-fields once, then add, remove and reorder rows of them in the
post editor. Rows are stored as one JSON string in post meta (or the Pods table
column for table-based Pods) — no extra tables, no custom schema, no serialized
PHP.

Read it back with the plain Pods API:

$tracks = pods_repeater_get_rows( 'tracks', get_the_ID(), 'platte' );

or with an ACF-compatible loop, so a theme written against ACF does not have to
be touched (pods_repeater_register_acf_aliases can turn the aliases off):

while ( have_rows( 'tracks', get_the_ID() ) ) {
    the_row();
    echo esc_html( get_sub_field( 'nr' ) . ' — ' . get_sub_field( 'titel' ) );
}

What it looks like

Two repeaters on one Pod — a track list and the pressings of a record, both
rendered in a template:

Status, honestly

0.3.0-alpha. Test site only. 127 tests / 2455 assertions, green on PHP 7.4
and 8.3 against WP 6.8.2 and Pods 3.3.9.1 (GitHub Actions runs both), admin UI
exercised in a real browser. One person, no support promise, no release
schedule.

Known limitations, in the README rather than in a support thread later

• No file / avatar / oembed sub-fields. Those render through Pods'
  React field editor, which does not initialise inside a cloned row — from row
  two on the picker would be dead. Put such a field on the Pod itself.
• No nested repeaters. The server rejects the configuration and strips such
  values on write.
• Field groups are managed in the admin only. No WP-CLI, REST or
  import/export route.
• No ACF data migration. Read compatibility only.
• No block-editor UI. The field renders server-side; Gutenberg sees the
  stored value.

Why I am posting this and not a PR

The open question is the build form: a self-contained field type (what I
built — own input(), pre_save(), value(), registered through
PodsForm::register_field_type(), no core file touched) or an extension of the
existing repeatable mechanism (one row implementation instead of two in the
ecosystem). I have an opinion, not the authority. Comment in
#7238 or here.

If the answer is "not into core" — fine. Then this is a plugin that fills the
gap today, and the thread gets a working implementation to point at.