The display layer: zero-code frontend display, block bindings, a safe shortcode, real REST exposure

[AllTerrainDeveloper]

Why

Every plugin in this category stores values, then leaves "and how do visitors see it?" to the theme, a paid views builder (MB Views), or a shortcode the market leader now disables by default because of how it handled escaping. That's the gap to win, not match: this PR makes display a built-in, free, escaped-by-default feature — four paths, from no code at all to full theme control.

What ships

1. Zero-code display — the differentiator

A per-group "Show on the front end" setting (toggle, before/after placement, optional heading — all in the builder's settings pane). Switched on, the group renders on the post's own page:

• Theme override hierarchy first: allterrain-fields/group-{key}.php, then allterrain-fields/group.php, via locate_template() — the template sees $group, $post, and $fields with values pre-loaded, so the common case is a foreach and an echo.
• Otherwise a built-in renderer draws an accessible definition list: repeaters and flexible content as nested rows, galleries as images, files and links as anchors, choices as their labels, tables as tables. Empty fields take no space; an empty group renders nothing.
• A small stylesheet ships only when a section actually renders — quiet by design, inheriting the theme's type and color.

ACF free has nothing like this; Meta Box sells it as MB Views; only Pods has a cousin of it.

2. Block bindings (WordPress 6.5+)

The source allterrain-fields/field binds core paragraphs, headings, buttons, and images to field values — value in meta, layout in blocks, edits propagate. URL-shaped attributes resolve to URLs (image field → attachment file, link field → its target, post field → permalink only when public); text resolves at the wp_kses_post() ceiling. Registration is guarded against duplicate-init warnings.

3. A shortcode that is safe by default

[atcf field="price" post="" default=""] renders through the same per-type renderer, so what ACF's shortcode got wrong is structurally impossible here:

• escaped per type, always;
• password fields refuse to render — the default text included, since a fallback would still confirm the secret exists;
• reading another post requires that post to be publicly viewable — the front door is exactly as strict as the REST API.

4. REST exposure that actually exists

The group setting "Expose in the REST API" was normalized, stored, documented… and consumed nowhere. It now does what it always promised: covered post types gain a read-only atcf object of formatted values in their REST response (password fields excluded). Writes stay on this plugin's own routes, where the per-object capability checks live.

The rule that runs through all four

This is a public surface, and every path treats it as one: output escaped per type even when a meta row was written past the save-time sanitizers, passwords never rendered anywhere, related posts linked only when is_post_publicly_viewable(), users rendered as display names — never email addresses. Every refusal has a test.

Surface & docs

• New filters, documented as Experimental in docs/hooks-reference.md (with a bindings markup example): atcf_display_groups, atcf_display_markup, atcf_display_value_html (one filter serves both the zero-code display and the shortcode), atcf_rest_field_values.
• readme.txt: a "Showing values without touching a template" section and a "How do I show a field on the site?" FAQ.
• Builder: new "On the front end" settings section; schema gains settings.frontend with safe normalization.

Tests

Eleven new PHP tests (tests/phpunit/tests/display.php): renders-after-content with a raw <script> planted straight into the meta row (output escaping must hold even when input sanitizing didn't), placement/heading settings, empty-value skipping, nested repeater rows, the refusals (private posts, user emails, passwords), shortcode escaping + cross-post gate + default behavior, bindings resolution incl. URL attributes and the password refusal, REST exposure on and off, and settings normalization.

• PHPUnit: 206 tests, 1215 assertions, green (was 195)
• Vitest: 369 green · tsc clean · PHPCS 0 errors · bundles rebuilt reproducibly

🤖 Generated with Claude Code

https://claude.ai/code/session_01HLZL6dY61BkPPmGyy6F9Us

[AllTerrainDeveloper]

Added: the "Products" starter template — the display layer's worked example.

It's deliberately the only template that ships with Show on the front end already switched on, because the fastest way to teach the display layer is the moment it teaches itself: apply the template, fill in a post, view the post — the spec sheet is simply there, no template edit, no block, no shortcode.

Every field maps onto one of the new surfaces: a spec table (rendered as a real table — the renderer also gained the header row the field declares), a gallery, a manual as a download link, an oembed video that renders as the player, a buy link a core Buttons block can bind to, a VAT-inclusive computed price ([atcf field="price_incl_vat"] drops it into content), a conditional restock note, an in-the-box repeater, and related products that only link when publicly viewable.

The end-to-end test walks the exact promised path — template applied, meta written, the real the_content filter run — and asserts the spec sheet, its header row, and the computed price (100 × 1.21 → 121) all arrive. 213 PHP tests green (was 206 on this branch), PHPCS clean.

[AllTerrainDeveloper]

Follow-up from visual review: the spec table's "no columns yet" message uncovered a pre-existing data-loss bug — fixed here.

The two halves of the codebase read table columns in different spellings, each blind to the other's:

• the builder's column editor and the client control speak value/label;
• the PHP sanitizer read only key — so every table configured through the builder UI sanitized against an empty column list, which blanked every cell on every save. Silent data loss on the main save path, hidden until the Products template (written in the key dialect: visible to PHP, invisible to the client) exposed the split as "This table has no columns yet."

Now every layer reads every dialect: the sanitizer accepts key, value, or a plain string; normalizeChoices (one normalizer, both renderers) accepts key as well as value; the template writes the builder's own spelling. Regression tests on both sides — PHP proves a builder-dialect table keeps its cells through the sanitizer across all three spellings, and a new vitest suite pins normalizeChoices' full dialect tolerance.

Also rebalanced the template's media row: the two tall drop zones (Photos, Manual) now pair at 50/50 and Video takes the full width — pairing a one-line URL input with a tall drop zone left a column of dead air that read as a layout bug.

373 JS / 214 PHP tests green. The sanitizer fix stands alone and is worth cherry-picking even if the rest of this PR waits.