← Garchi CMSCONTENT HISTORYWHAT CHANGED · RULE-BASED ANALYSIS
Update to Garchi CMS
Snapshot Sep 30, 2026 · 22:55 UTC · version 4.0.0
Collection source: not recorded for this historical snapshot.
First saved snapshot
No earlier snapshot is available to establish a change.
Compare saved observations
Download comparison JSONFull technical diff · 0 changed fields
Full snapshot data
{
"name": "garchi-render-content",
"description": "Write the application code that fetches and renders Garchi CMS content — the server-side Garchi client, page and section renderers, nested sections, data items (blogs/products), item metadata, assets, SEO metadata and draft/preview mode — in Next, Nuxt, Laravel, SvelteKit or any other stack, via the Node SDK, PHP SDK or REST API. Use when implementing or fixing the frontend/server integration for Garchi content. Code only — to create or edit the content itself use garchi-manage-content; to plan a whole project or pick a starter kit use garchi-build-site.",
"included_files": [
{
"relative_path": "references/code-snippet.md",
"size_in_bytes": 22368
},
{
"relative_path": "references/garchi-cms-doc.md",
"size_in_bytes": 12644
},
{
"relative_path": "references/garchi-sdk-node.md",
"size_in_bytes": 22334
},
{
"relative_path": "references/garchi-sdk-php.md",
"size_in_bytes": 19427
}
],
"skill_md_contents": "---\nname: garchi-render-content\ndescription: Write the application code that fetches and renders Garchi CMS content — the server-side Garchi client, page and section renderers, nested sections, data items (blogs/products), item metadata, assets, SEO metadata and draft/preview mode — in Next, Nuxt, Laravel, SvelteKit or any other stack, via the Node SDK, PHP SDK or REST API. Use when implementing or fixing the frontend/server integration for Garchi content. Code only — to create or edit the content itself use garchi-manage-content; to plan a whole project or pick a starter kit use garchi-build-site.\n---\n\n# Skill: garchi-render-content\n\n## Scope\n- ✅ Build or improve the code needed to **fetch and render** Garchi CMS content (pages, sections, data items).\n- ✅ Integrate Garchi CMS into an existing codebase without breaking conventions.\n- ❌ Do not manage CMS content (create pages/sections/assets/templates) here — that is `garchi-manage-content`, over MCP.\n- ❌ Do not choose or bootstrap a starter kit here — that is `garchi-build-site`.\n\n## Quick start: choose your path\n1. **Fresh project → a starter kit is probably right.** Hand back to\n `garchi-build-site`, or read\n [starter-kits.md](../garchi-build-site/references/starter-kits.md). Kits ship\n the SDK, env config, a section renderer and example components.\n2. **Existing project, Node or PHP backend → use the SDK** (`@garchicms/garchi-node-sdk` or `garchicms/garchi-sdk-php`).\n3. **Existing project, any other backend → use the REST API** via the OpenAPI spec.\n4. **Always render from the server** (SSR / server runtime). The API/SDK is **server-side only** and does not support client-side calls.\n\n## Configuration contract\nConfirm these exist before writing fetch code (starter kits create them for you):\n\n| Env var | Purpose | Required |\n| --- | --- | --- |\n| `GARCHI_API_KEY` | Account API key used to authenticate all API/SDK calls. Account-level, not space-level: one key covers every space the account owns | Yes |\n| `GARCHI_SPACE_UID` | Target space UID passed to most calls | Yes |\n| `GARCHI_API_URL` | API base, `https://garchi.co.uk/api/v2` | Yes |\n| `GARCHI_PREVIEW_TOKEN` | Enables draft/preview mode. Per space (Space Settings → Preview Token) | Only if preview is needed |\n\nNuxt keeps these values in `runtimeConfig` in `nuxt.config.ts` rather than in a\n`.env` file. Match whatever the project already uses rather than introducing a\nsecond convention.\n\n**Rule:** the API key is **server-side only**. Never expose it to the client, never\nprefix it with `NEXT_PUBLIC_`/`VITE_`/`PUBLIC_`, never commit it, and never call\nthe Garchi API from the browser.\n\n## Always (non-negotiable rules)\n1. **Preserve Visual Editor attributes**\n - For every section component, forward unknown/extra props/attributes to the **root element** (outermost wrapper).\n - Framework-agnostic rule: \"Unknown attributes must not be dropped; attach them to the root/host element.\"\n - Patterns:\n - React/Preact/Solid: spread `...other` on root\n - Vue: `v-bind=\"$attrs\"` on root (if `inheritAttrs: false`, re-bind manually)\n - Svelte: spread `...$$restProps` on root\n - Angular: preserve/pass through host attributes; do not strip unknown attrs\n - Web Components: keep attrs on host or forward to outer wrapper\n - Laravel Blade: ensure attributes are passed to the root element of the section component `{{ $attributes->merge() }}`\n\n2. **Content belongs in Garchi, not in components**\n - Copy, headings, image URLs and list contents come from section props or data-item fields. Do not hard-code them, and do not \"temporarily\" inline content that the CMS should own.\n - If a value has nowhere to live in the CMS yet, add the prop or template through `garchi-manage-content` rather than baking the value into code.\n - Components own layout, styling and behaviour. They should not encode which page they appear on.\n\n3. **Do not modify reference snippets/docs**\n - Treat [code-snippets](./references/code-snippet.md) and provided examples as reference. Do not rewrite them unless asked.\n - The reference code is React/Next. Adapt the same logic to the target stack using its native primitives (component resolution, attribute forwarding, HTML sanitization).\n\n4. **Keep codebase conventions**\n - Follow existing linting, formatting, naming, and folder conventions.\n - Reuse existing components (Markdown/HTML sanitizer, typography atoms) instead of adding new ones or new dependencies.\n - Avoid large refactors unless requested.\n\n## Reference resources — load on demand\nRead only what the current task needs. Do **not** fetch the full OpenAPI spec upfront.\n\n| When you need to… | Load |\n| --- | --- |\n| Understand entities & hierarchy (space, page, section, data item, meta) | [garchi-cms-doc.md](./references/garchi-cms-doc.md) |\n| Copy-adaptable rendering code (React reference) | [code-snippet.md](./references/code-snippet.md) |\n| Node backend call signatures & types | [garchi-sdk-node.md](./references/garchi-sdk-node.md) |\n| PHP backend call signatures & types | [garchi-sdk-php.md](./references/garchi-sdk-php.md) |\n| Which starter kit ships what | [starter-kits.md](../garchi-build-site/references/starter-kits.md) |\n| Exact request/response shapes, or an endpoint not in the SDK | [OpenAPI spec](https://garchi.co.uk/docs/v2.openapi) |\n\n## Recommended implementation workflow\n### A) Choose access method\n- Prefer starter kits for fresh projects (see Quick start).\n- Prefer SDKs where available (Node / PHP).\n- If using the raw API, create a small server-side service layer (DRY/SOLID, typed, reusable). Raw API calls must be made from the server. Use the OpenAPI spec for reference.\n\n### B) Build the rendering pipeline\n1. Fetch page/data item from server-side (SSR/server runtime).\n2. Render sections via a single section renderer (mapper) — `GarchiComponent`.\n3. Each section maps to a reusable component (resolved from the section `description`, falling back to `name`).\n4. Support nested sections (`subsections`) if present — the renderer is reused recursively.\n\n### C) Quality + safety\n- Sanitize HTML before rendering (XSS). Reuse the project's sanitizer/Markdown atom if present.\n- Handle errors gracefully (notFound, fallback UI).\n- Use stable keys (prefer section id/uid over array index).\n- Add a consistent \"missing component\" fallback that fails gracefully and logs what's missing.\n- Cache/revalidate page fetches appropriately; fetch lists (assets/templates) once and reuse.\n- Prefer typed section props; validate critical CMS payload shape at boundaries where helpful.\n\n## Definition of Done\n- Pages/data items render correctly in the chosen stack.\n- Visual Editor attributes are preserved on all section components.\n- Preview/draft mode works (if required).\n\n**If a page or item renders empty in `live`, check whether it is published before\ndebugging the code.** Garchi serves published content only: page content writes put the\npage back into draft, and data items are created unpublished, so freshly authored content\nis missing from `live` by design until the user publishes it in the dashboard. Fetch the\nsame content in `draft` mode to confirm it exists.\n- Errors are handled without infinite retries/loops.\n- HTML content is sanitized where applicable.\n- No content that belongs in Garchi is hard-coded in components.\n\n## Loop prevention (stop conditions)\n- Do not retry the same failing operation more than 2 times.\n- After an update/fetch, verify state once; if still incorrect, stop and report what's missing.\n"
}SHA-256: bc230e09b456b722e3f06f15d9e166eea2b7731698e57907ff006ae6fa6f4857