Record creation wizard (reduced page tree) for multiple configured pids

[maikschneider]

Summary

Once multiple entry-point pids are supported (#95), the current "new record" UI — a single button plus a <select> dropdown of target directories — scales poorly. This proposes a dedicated record creation wizard, modelled on the "Create new page" wizard introduced in TYPO3 v14: a modal showing a reduced page tree (root pages + the configured storage folders), where clicking a target redirects straight to the new-record edit form.

This is a follow-up to #95 (multiple pids). It only becomes meaningful once more than one entry point can be configured.

Reference: TYPO3 v14 "Create new page" wizard

v14 ships a stepped modal ("Select a position for the new page", step 1 of 4) that renders a trimmed page tree — site root pages with their relevant children — and lets the editor click a position. We want the equivalent for records: a reduced tree showing the root pages of each accessible site and the configured storages (the resolved getRecordSources() from #95), each clickable as a creation target.

Motivation

• With multiple pids across multiple sites, a flat <select> dropdown (Resources/Public/JavaScript/recordlist-doc-new-record.js) is hard to scan — identical folder names across mandants, no hierarchy, no context.
• A reduced page tree gives spatial context (which site, which branch) and matches the mental model editors already know from the v14 page wizard.
• Reuses the site-prefixing work from Support multiple entry-point pids (with subpages) across sites for record aggregation #95 naturally — the tree itself disambiguates by showing each site's root.

Proposed behaviour

• Replace (or augment) the new-record dropdown with a modal that renders a reduced page tree:
  • One node per root page of each site the BE user can access.
  • Under each, only the configured/resolved storage folders (getRecordSources()), not the full subtree.
• Click a node → redirect to the new-record edit form for that pid (same target the current buttons/dropdown produce).
• Respect the same permission filtering (readPageAccess, PAGE_SHOW) and site access already resolved in Support multiple entry-point pids (with subpages) across sites for record aggregation #95.
• Single-site / single-pid setups can keep the current lightweight button (no wizard needed) — the wizard is for the multi-pid case.

Where it lives (current code)

• New-record buttons — addNewButtonToModuleTemplate() (Classes/Controller/AbstractBackendController.php:1912).
• Modal JS — Resources/Public/JavaScript/recordlist-doc-new-record.js (currently builds a <select> from .new-record-in-page.hidden elements).
• Resolved sources — getRecordSources() (to be introduced in Support multiple entry-point pids (with subpages) across sites for record aggregation #95).

Open questions

• Reuse TYPO3 core's page-tree component / PageTreeRepository for rendering, or build a purpose-trimmed tree?
• Is the v14 wizard component reusable directly, or do we need a v13-compatible implementation (this extension targets ^13.4)?
• Single step (pick directory → redirect) vs. a multi-step flow like the v14 page wizard.

Acceptance criteria

• When multiple entry-point pids are configured, "new record" opens a modal with a reduced page tree (site roots + configured storages).
• Clicking a storage node redirects to the new-record edit form for that pid.
• Permission and multi-site access filtering match Support multiple entry-point pids (with subpages) across sites for record aggregation #95.
• Single-pid setups are unaffected (current button retained).
• Tests/QA cover tree rendering for multi-site + multi-pid and the redirect target.

---

Follow-up to #95. Depends on multiple-pid support landing first.