Repository navigation
Templates tab persistence #842
Description
Part of #836. Wires the Templates tab. Depends on the Color/foundation PR. Final per-tab PR if scheduled last; can also land before others — order among PRs 2–5 is flexible.
Scope
TemplatePartsPanel→ top-leveltemplatePartsarray.CustomTemplatesPanel→ top-levelcustomTemplatesarray (each entry:{ name, title, postTypes: [...] }).- Update
readme.txtto document the Edit Theme Settings feature (if this PR lands last; otherwise the readme update goes with whichever per-tab PR completes the feature).
Acceptance criteria
- Adding / removing / editing template parts persists.
- Adding a custom template with multiple post types persists with the array intact.
- Removing a template removes the entry only (does not touch template files on disk — that's a separate concern).
- If this is the last per-tab PR:
readme.txtdescribes the feature in the Description and Changelog sections.
Out of scope
- Touching template files on disk when entries are removed.
- WP-CLI.
References
- Tracking issue: [Tracking] Edit Theme Settings: phased implementation #836
Activity
[-]Edit Theme Settings: Templates tab persistence[/-][+]Templates tab persistence[/+]bph commentedon May 7, 2026
UX consideration discovered while smoke-testing the endpoint
WordPress only surfaces a
customTemplatesentry in the post/page editor's Template dropdown if a correspondingtemplates/<name>.htmlfile exists in the active theme. Registering an entry intheme.jsonwithout the file is a silent no-op for the user — the entry is persisted but invisible.Confirmed via smoke test against #837: the endpoint correctly wrote
customTemplates: [{name: "page-wide", ...}]totheme.json, but the dropdown didn't show the option becausetemplates/page-wide.htmldidn't exist.This affects how this PR should handle the Custom Templates UI. Three options:
templates/<name>.htmlin the Site Editor to make this template selectable"). Non-destructive, transparent.templates/<name>.htmlon save. Forces existence; risks creating files the user didn't intend.Recommendation for v1: Option 1 (warn-only). Consistent with the modal's role as a settings editor (not a file generator), and matches how we expect users to flow between the Site Editor (file creation) and Edit Theme Settings (registration metadata).
Worth surfacing in the help text on the Custom Templates panel so this isn't a surprise.