fix(publish): wire the existing seoTitle field into the document <title> - #370
fix(publish): wire the existing seoTitle field into the document <title>#370asachs01 wants to merge 1 commit into
Conversation
seoTitle is already a fully-built post-type field — declared in the
default field set, seeded by the DB migrations, and editable in the
Content Settings panel's SEO field — but the publish and preview render
paths never consumed it: `renderPublishedDataRowTemplate` and
`handleRowPreview` both set `merged.title` unconditionally from
`row.cells.title`, so the meta-tag `<title>` always fell back to the
plain entry title even when an author filled in a distinct SEO title.
Add `resolveEntryDocumentTitle()` (prefers seoTitle, falls back to
title) and use it at both call sites. The on-page H1 binding
(`{currentEntry.title}`) is unaffected — it resolves from the loop
item's cells directly, never from `merged.title` — so this only
changes what feeds the `<title>` tag / meta description pipeline.
|
Thanks for this, @asachs01. You found a real bug that had been sitting in plain sight: Landing it took a different layer, so this went in as #419 (merged in a0b1e4e) with you as co-author, and I am closing this one. Two things surfaced while verifying:
The merged version gives Also added |
2 participants
Summary
seoTitleis already a fully-built post-type field — declared inbuildPostTypeDefaultFields(), seeded by both DB migration paths, editable via the Content Settings panel's SEO field, and even exposed to the token/binding picker ({currentEntry.seoTitle}) and the AI content tool — but the publish and preview render paths never actually consume it.renderPublishedDataRowTemplate()(server/publish/publicRenderer.ts) and its preview twinhandleRowPreview()(server/handlers/cms/data/preview.ts) both setmerged.titleunconditionally fromrow.cells.title/draftCells.title. Thatmerged.titleis whatbuildDocumentMetaTags()uses for the<title>tag (src/core/publisher/render.ts), so an author who fills in a distinct SEO title today sees zero effect on the actual<title>output — the field silently does nothing at publish time.Change
resolveEntryDocumentTitle(cells)helper insrc/core/data/cells.ts: prefersseoTitlewhen set (non-empty string), falls back totitle, returnsnullwhen neither is present (preserving today's exact fallback-to-template behavior for rows with no title at all).publicRenderer.ts:182,preview.ts:99) now use this helper instead of the inlinetitle-only check, so publish and preview stay in parity.{currentEntry.title}binding is completely untouched — traced the actual data flow and confirmed it resolves frompublishedDataRowToLoopItem(row)'s spread ofrow.cellsdirectly into the template's entry-stack frame, never throughmerged.title. So this change only ever affects the<title>meta tag, never the visible headline.Test plan
src/__tests__/server/publicRendering.test.ts: a realpostTypes-targeted entry template (not the existing null-early-return fixture) provingseoTitleset →<title>uses it while the H1 binding still renders plaintitle;seoTitleunset → byte-identical fallback.resolveEntryDocumentTitleinsrc/core/data/__tests__/cells.test.ts.bun test).tsc -bclean,eslint .clean.Noticed while working on the trusted-host iframe-embed fix (#369) — same investigation trail, unrelated bug though, so opened as a separate PR for independent review.