Stacks

Stacks are the reusable building system inside Chinaski’s block editor. A stack is a named, ordered group of blocks that you assign once and reuse across pages and posts — a hero section, a feature grid, a set of calls-to-action that should live on every product page. In Chinaski they are stacks, with nesting, inheritance, per-language content, and revision history. This page explains how to build and manage them.

Building a stack

Create a stack under Stacks in the admin area:

• Give it a name (unique among stacks that haven’t been deleted), a description, and its language.
• Add blocks to it from the Blocks editor, in the order they should render.
• Optionally give the stack a Layout JSON wrapper — {"tag":"section","class":"my-cta"}-style markup configuration that wraps the rendered block group once.

Stacks can also include other nested stacks, each with its own sort order. A stack can also extend another: the child prepends the parent’s blocks ahead of its own, so a shared site section can be assembled once and extended per case. If the parent stack is deleted, the child’s link is cleared automatically.

A note about editors and stacks: stacks are deliberately gated. If an editor’s allowed-entities list excludes stacks, they can neither see nor modify any stacks screens — the gate applies to read and write alike.

Assigning stacks to content

Stacks attach from the Blocks editor to a page or a post. When assigning a stack, per-pairing knobs exist: the order the stack appears in, per-instance overrides, and (advanced) an availability-rules JSON. Each attached stack is tracked by the build, so the site’s signed build manifest records which stacks were used per page.

Each block in the stack can carry per-instance overrides, so the same block can appear with different content in different stacks. And a page can’t render the same block twice via stack resolution: a block already surfaced by one stack is skipped wherever else it appears during that page’s build.

Per-language stacks

Stacks are language-aware two ways:

• The stack itself carries a language field, so parallel stacks for different languages can exist. Block references inside resolve per language, falling back to a language-empty (site-wide) block when that language has no block with the referenced name.
• A stack translation (defined per stack + language) supplies an alternative block list for that language only. When a translation exists for the serving language, it fully replaces the base block sequence for that language by replacing each listed block’s overrides. No translation row — base ordering wins.

Nesting and inheritance

• Nested stacks let a stack embed other stacks, each with sort order. The builder resolves them recursively and guards against infinite loops and silly deep chains (more than five levels of depth), so misconfiguration can’t wedge a build.
• Extending is for reusable structure: make a stack that extends another (a parent with others prepended); deletion of the parent clears the child’s link gracefully rather than corrupting it.

Where it’s used and what changed

The Stacks dashboard shows where each stack is used: the “used on” list names pages and posts (with a first-N cap and note when the list is longer). Edit screens show stacks of recent changes; every change is captured in the stack’s revisions, so you can compare any two revisions and restore an earlier configuration to a live stack.

Behind-the-scenes quality and audits

Every stack render is part of the build’s quality scan — stack renders contribute to the site-wide accessibility and broken-link counts shown in the build guard, and each stack restore/update/change logs to the audit trail (“stack restored to selected revision” entries are audited). When a build report flags a degradation, sorted stacks contribute and are part of the per-stack stats from the same data used to block a bad promote.