[dogfrogfog]

Addresses #210 — the remaining global-blocks gaps (parts 1, 2, 4, 5, 6).

Stacked on #211. #210 is an explicit follow-up to the correctness-fix PR #211 (revalidatePagesUsingGlobalBlock, resolveGlobalBlocks, upsertPageEmbedding, the extractPageText slot case). Those live only on #211's branch, so this PR is based on fix/cms-global-block-integrity and targets it — the diff shows only the follow-up work. Merge #211 first, then this (or retarget to main once #211 lands).

What changed

1. Translation, scheduled publishing and comments for global blocks (src/lib/plugins/index.ts)
globalBlock is now in the translatorPlugin, schedulePublicationPlugin and commentsPlugin collection lists, so a shared block can be AI-translated, scheduled, and commented on — not just the pages that embed it. No migration: scheduling rides on the existing payload_jobs collection, comments injects only admin components, and translator provenance is not enabled.

2. Standalone preview for a global block (GlobalBlock config + new route)
New route /[locale]/preview/global-block/[id] renders the single block, wired to admin.livePreview / admin.preview. The locale prefix follows the as-needed routing policy (default locale unprefixed). Lets an editor see a block before publishing it to every page that embeds it.

4. Inner relationships populated at full depth (GlobalBlockRenderer)
The page query spends one depth level on the slot relationship, so a global block's inner relationships were populated one level shallower than the same block placed directly on a page. The renderer now re-fetches the referenced block at the page render depth (PAGE_RENDER_DEPTH = 3), respecting draft + locale. Extracted into a shared GlobalBlockRenderer used by both the slot block and the preview route.

5. rawHtml indexed for semantic search (RawHtml/extractText.ts + extractPageText)
New rawHtml case strips tags and drops <script> / <style> content (the opening-tag match tolerates > inside quoted attributes) before indexing.

6. Re-index every locale on page and global-block saves (indexEmbedding + revalidatePagesUsingGlobalBlock)
Decision for the open question in part 6: yes, cover every locale, for both page saves and global-block saves — locale fallback means an en edit changes the rendered (and therefore indexable) text of es pages that fall back to en. Both re-index paths now extract at the same depth (PAGE_EMBEDDING_DEPTH = 2, threaded into resolveGlobalBlocks) so neither overwrites the other's embedding with less text, and so a block that reads a relationship (e.g. testimonialsList) is indexed.

Not included — part 3 ("make this block global" action)

Left for a dedicated follow-up. It's an interactive admin-form mutation (create a globalBlock from a page block's data, then swap the block for a globalSectionSlot via Payload's form replaceFieldRow API) that needs live iteration in the admin panel to get right — not something to land unverified in a batch PR. This PR does not close #210 for that reason.

How it was verified

• bun run check-types — passes across the whole repo.
• bun run lint (ultracite check) — 0 warnings / 0 errors on changed files.
• bun run build — compiles successfully (✓ Compiled successfully); the build only stops at "Collecting page data" because this sandbox can't reach the Neon database. CI / the Vercel preview run the full build + migrations.
• Self-review: /code-review and /simplify on the diff; findings addressed (locale-prefix in the preview path, consistent embedding depth across re-index paths, hidden-block parity between render and index, hardened script/style stripping).
• Adversarial unit check of the HTML stripper (incl. > inside a script attribute) — script/style content fully dropped.

Design note for the reviewer (part 4)

The slot renderer re-fetches the referenced block at PAGE_RENDER_DEPTH so inner relationships reach parity with page blocks. An alternative is to resolve slots in the data layer (getPageBySlugQuery → resolveGlobalBlocks with a draft option), which would batch the fetch and ride the page cache. I kept the renderer-side fetch here because resolveGlobalBlocks is request-scoped (req.payload) while the render DAL is payload-client/cache-scoped, so unifying would mean reworking that shared resolver and its draft handling — more surface than I could runtime-verify without a DB. Happy to switch to the data-layer approach if you'd prefer it.

Please test manually (needs the admin + a DB)

• Admin Preview / Live Preview on a Global Block renders the block (draft before publish; both en default-unprefixed and es prefixed URLs).
• Translate / schedule / comment controls appear on a Global Block.
• Editing a global block re-indexes search for every affected page and locale; searching finds rawHtml text and global-block content.

---

Generated by Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
ideal-cms	Ready	Preview	Oct 27, 2026 1:17pm UTC

[dogfrogfog]

Consolidated into #211 (commit 8e611dc), which is why GitHub marks this as merged. Kept: plugins, preview route, render depth, rawHtml search, page-save re-index in every locale. Changed: global block text stays out of page search vectors, so the global block re-index path and resolveGlobalBlocks are dropped; embedding depth is 1; stripHtml also handles quoted > in normal tags and plain </> text; the renderer uses disableErrors instead of .catch(() => null).

[github-actions]

🎉 This PR is included in version 1.1.1 🎉

The release is available on npm package (@latest dist-tag)

Your semantic-release bot 📦🚀

[github-actions]

🎉 This PR is included in version 0.18.1 🎉

The release is available on npm package (@latest dist-tag)

Your semantic-release bot 📦🚀

[github-actions]

🎉 This PR is included in version 1.4.0 🎉

The release is available on npm package (@latest dist-tag)

Your semantic-release bot 📦🚀