Migration Express

Key Capabilities

Bengal is a static site generator that produces HTML, CSS, and JavaScript from Markdown content and Kida templates.

What Bengal Does

Content & Authoring

• MyST Markdown — Directives, admonitions, cross-references, tabs, cards
• 50+ Built-in Directives — Code tabs, dropdowns, galleries, video embeds, versioning badges
• Content Collections — Type-safe frontmatter validation with dataclass or Pydantic schemas
• Mixed Content Types — Docs, blog, landing pages, changelogs in one site

Performance

• Kida Templates — 1.81x faster than Jinja2 under concurrent workloads
• Incremental Builds — 35-80ms rebuilds for single-page edits
• Free-Threading — True parallelism on Python 3.14+ (no GIL contention)
• Parallel Rendering — 2-4x speedup on multi-core systems

Developer Experience

• Auto-generated API Docs — From Python source, CLI tools, and OpenAPI specs
• Image Processing — Resize, crop, format conversion (WebP/AVIF), srcset generation
• Zero-Config Deploy — Auto-detects GitHub Pages, Netlify, Vercel
• Theme System — Install themes from PyPI, swizzle templates, 1,100+ CSS tokens

Quality & Validation

• Health Checks — Broken links, missing images, frontmatter validation
• Auto-Fix —bengal fixrepairs common issues automatically
• Site Analysis — Graph visualization, orphan detection, content metrics

Technical Details

Migration Guides

Step-by-step guides to migrate your site from another static site generator to Bengal.

Migration Overview

All migrations follow similar patterns, regardless of your source platform:

Common Migration Steps

1. Install Bengal:pip install bengal or uv add bengal
2. Create new site:bengal new site mysite
3. Copy content: Transfer your markdown files tocontent/
4. Convert syntax: Replace platform-specific syntax with Bengal directives
5. Update configuration: Convert config files tobengal.toml
6. Test and verify: Runbengal build and bengal health linkcheck

Universal Conversions

Most platforms use similar concepts that map to Bengal directives:

What Stays the Same

• Markdown files: Your content files transfer directly
• YAML frontmatter: Frontmatter format is compatible
• Directory structure:content/structure works similarly
• Static output: All generators produce static HTML

What Changes

• Template syntax: Each platform's template language → Jinja2
• Component syntax: Platform-specific components → Bengal directives
• Configuration: Platform config →bengal.toml
• Build process: Platform CLI →bengal build

Common Issues

Template variables not working?

• Check the template variable mapping in your platform's guide
• Hugo users:{{ .Params.x }} → {{ page.metadata.x }}
• Jekyll users:{{ page.custom }} → {{ page.metadata.custom }}

Directives not rendering?

• Ensure you're using triple colons::::{note} not :::note
• Check that directive names match exactly (case-sensitive)
• See the Directives Reference for all available directives

Configuration errors?

• Verifybengal.tomlsyntax (TOML format)
• Check that all required[site]fields are present
• See the Configuration Reference for details

Links broken after migration?

• Runbengal health linkcheckto find broken links
• Update relative paths if directory structure changed
• Check that asset paths use/assets/prefix

Platform-Specific Guides

Bengal for Hugo Users

Bengal's content model matches Hugo's. The main difference: shortcodes become directives.

Quick Wins (5 Minutes)

What Works The Same

The Key Difference

Hugo shortcodes → Bengal directives:

<!-- Hugo -->
{{</* notice warning */>}}
This is a warning
{{</* /notice */>}}

<!-- Bengal -->
:::{warning}
This is a warning
:::

Shortcode → Directive Translation

Callout Boxes

{{</* notice note */>}}
This is a note with **bold** text.
{{</* /notice */>}}

{{</* notice warning */>}}
Be careful!
{{</* /notice */>}}

{{</* notice tip */>}}
Pro tip here.
{{</* /notice */>}}

:::{note}
This is a note with **bold** text.
:::

:::{warning}
Be careful!
:::

:::{tip}
Pro tip here.
:::

Tabs

{{</* tabs */>}}
{{</* tab "Python" */>}}
```python
print("Hello")
```
{{</* /tab */>}}
{{</* tab "JavaScript" */>}}
```javascript
console.log("Hello");
```
{{</* /tab */>}}
{{</* /tabs */>}}

:::{tab-set}
:::{tab} Python
```python
print("Hello")
```
:::{/tab}
:::{tab} JavaScript
```javascript
console.log("Hello");
```
:::{/tab}
:::{/tab-set}

Code Highlighting

{{</* highlight python "linenos=table,hl_lines=2" */>}}
def hello():
    print("Hello!")  # highlighted
    return True
{{</* /highlight */>}}

```python
def hello():
    print("Hello!")  # use comments to draw attention
    return True
```

Figure / Image

{{</* figure src="/static/images/photo.jpg" title="My Photo" caption="A description" */>}}

:::{figure} /images/photo.jpg
:alt: My Photo
:caption: A description
:align: center
:::

YouTube Embed

{{</* youtube dQw4w9WgXcQ */>}}

:::{youtube} dQw4w9WgXcQ
:title: Video Title (required for accessibility)
:::

All Media Embed Directives

Bengal includes built-in directives for common media embeds:

Note: All iframe-based directives require:title:for accessibility.

Template Variable Mapping

Page Variables

Site Variables

Variable Substitution in Content

Bengal supports variable substitution in markdown content:

---
title: Release Notes
version: "2.5.0"
release_date: "2025-01-15"
---

# {{ page.title }}

**Version {{ page.metadata.version }}** released on {{ page.metadata.release_date }}.

Current site: {{ site.config.title }}

Configuration Mapping

Basic Site Config

baseURL = "https://example.com"
title = "My Site"
languageCode = "en-us"
theme = "docsy"

[params]
  description = "My awesome site"
  github_repo = "https://github.com/user/repo"

[site]
baseurl = "https://example.com"
title = "My Site"
language = "en"
theme = "bengal"

[site.params]
description = "My awesome site"
github_repo = "https://github.com/user/repo"

Menu Configuration

[[menu.main]]
  name = "Docs"
  url = "/docs/"
  weight = 10

[[menu.main]]
  name = "Blog"
  url = "/blog/"
  weight = 20

[[site.menu.main]]
name = "Docs"
url = "/docs/"
weight = 10

[[site.menu.main]]
name = "Blog"
url = "/blog/"
weight = 20

Directory Structure Comparison

Additional Features

:::{cards}
:columns: 3

:::{card} Feature 1
:icon: rocket
:link: /docs/feature1/

Quick description
:::{/card}

:::{card} Feature 2
:icon: package
:link: /docs/feature2/

Another feature
:::{/card}

:::{/cards}

:::{steps}

:::{step} Install
```bash
pip install bengal
```
:::{/step}

:::{step} Create Site
```bash
bengal new site mysite
```
:::{/step}

:::{step} Start Server
```bash
bengal serve
```
:::{/step}

:::{/steps}

:::{data-table}
:source: data/products.yaml
:columns: name, price, stock
:sortable: true
:filterable: true
:::

<!-- Define in data/glossary.yaml -->
<!-- Use in any page: -->
:::{glossary}
:tags: api, authentication
:::

<!-- Auto-generate cards from section children -->
:::{child-cards}
:columns: 2
:::

<!-- Show sibling pages in the current section -->
:::{siblings}
:::

<!-- Prev/Next navigation links -->
:::{prev-next}
:::

<!-- Breadcrumb navigation -->
:::{breadcrumbs}
:::

<!-- Related pages by tag -->
:::{related}
:tags: api, authentication
:::

Differences and Limitations

Template Syntax Differences

Template Functions vs Filters

Bengal distinguishes between functions (called directly) and filters (used with|). Hugo mixes both concepts.

Hugo's Approach:

Hugo uses both functions and methods:

{{ len .Pages }}                    {# Function #}
{{ .Pages.GetMatch "*.md" }}        {# Method #}
{{ .Title | upper }}                {# Filter #}

Bengal's Approach:

Bengal separates them clearly:

Filters (transform values):

{{ page.title | upper }}
{{ site.pages |> where('draft', false) }}

Functions (standalone operations):

{{ get_page('path') }}
{{ get_data('file.json') }}

Migration Pattern:

Rule of thumb:

• Hugo functions that transform values → Bengal filters
• Hugo functions that retrieve/lookup → Bengal functions

See Functions vs Filters for complete explanation.

Migration Steps

Migration Checklist

Quick Reference Card

Common Questions

{# Resize and crop to exact dimensions #}
{% let processed = image.fill("800x600 webp q80") %}
<img src="{{ processed.rel_permalink }}" width="{{ processed.width }}">

{# Fit within dimensions (preserve aspect ratio) #}
{% let thumb = image.fit("400x400") %}

{# Generate responsive srcset #}
<img srcset="{{ 'hero.jpg' | image_srcset([400, 800, 1200]) }}"
     sizes="(max-width: 640px) 400px, 800px">

Related Migration Guides

• From Jekyll - Similar shortcode-to-directive conversion patterns
• From Docusaurus - MDX component migration
• Migration Overview - Common migration patterns across all platforms

Next Steps

• Directives Reference - Complete directive reference
• Configuration Reference - Full config options
• Cheatsheet - Quick syntax reference
• Theme Variables - Customize themes

Bengal for Sphinx/RST Users

You're 80% there. Bengal uses MyST-compatible syntax that mirrors what you already know.

Quick Wins (5 Minutes)

Your Directives Work (Almost)

The only syntax change:.. name:: becomes :::{name}.

Side-by-Side Example

.. note:: Important

   This is a note with **bold** text.

.. code-block:: python
   :linenos:
   :emphasize-lines: 2

   def hello():
       print("Hello, World!")

:::{note} Important
This is a note with **bold** text.
:::

```python
def hello():
    print("Hello, World!")
```

Complete Feature Mapping

Admonitions

Code Blocks

File Inclusion

Example: Literalinclude Usage

:::{literalinclude} ../examples/hello.py
:language: python
:lines: 5-15
:caption: Hello World Example
:::

Cross-References

Bengal uses[[label]]syntax for intelligent cross-references that automatically resolve page titles and paths.

Example: Cross-Reference Examples

<!-- Basic cross-reference (uses page title automatically) -->
[[docs/getting-started]]

<!-- Cross-reference with custom text -->
[[docs/getting-started|Get Started Guide]]

<!-- Link to heading anchor -->
[[#installation]]
[[docs/getting-started#installation]]

<!-- Link by custom ID (if page has id: in frontmatter) -->
[[id:install-guide]]

<!-- Standard markdown links also work -->
[Configuration Guide](../reference/configuration.md)
[Config Options](../reference/configuration.md#options)

Table of Contents

Bengal auto-generates navigation from your directory structure. Useweightfrontmatter to control order:

---
title: Installation
weight: 10  # Lower = appears first
---

Configuration

Example: Minimal bengal.toml

[site]
title = "My Documentation"
baseurl = "https://docs.example.com"
language = "en"
theme = "bengal"

Directory Structure

What Bengal Adds (Sphinx Doesn't Have)

:::{cards}
:columns: 3

:::{card} Quick Start
:icon: rocket
:link: quickstart

Get started in 5 minutes
:::{/card}

:::{card} API Reference
:icon: book
:link: api/

Complete API docs
:::{/card}

:::{/cards}

:::{tab-set}

:::{tab} pip
```bash
pip install mypackage
```
:::{/tab}

:::{tab} conda
```bash
conda install mypackage
```
:::{/tab}

:::{/tab-set}

:::{steps}

:::{step} Install Dependencies
```bash
pip install bengal
```
:::{/step}

:::{step} Create Site
```bash
bengal new site mysite
```
:::{/step}

:::{/steps}

:::{dropdown} Click to expand
:icon: info

Hidden content here. Supports **full markdown**.
:::

---
title: My Page
version: "2.0"
---

# Welcome to version {{ page.metadata.version }}

The current page is: {{ page.title }}

Site name: {{ site.config.title }}

bengal serve
# Live preview at http://localhost:5173
# Auto-reloads on file changes

What's Different (Honest Gaps)

autodoc Alternative

Bengal has a built-in autodoc system that generates API documentation from Python source. Configure it in eitherbengal.toml or config/_default/autodoc.yaml:

[autodoc.python]
enabled = true
source_dirs = ["src/"]
output_prefix = "api"  # Pages appear under /api/

autodoc:
  python:
    enabled: true
    source_dirs: ["src/"]
    output_prefix: "api"  # Pages appear under /api/

This generates virtual pages during the build process, unlike Sphinx's runtime introspection. Runbengal buildto generate API documentation from your Python source.

Migration Checklist

Quick Reference Card

Common Questions

Next Steps

• Writer Quickstart - Full markdown reference
• Directives Reference - All available directives
• Configuration Reference - Full config options
• Cheatsheet - Quick syntax reference

Bengal for Docusaurus/MDX Users

Great news: You get the same rich components without React, JSX, or npm. Bengal's directives provide similar functionality in pure Markdown.

Quick Wins (5 Minutes)

Admonition Syntax Is Almost Identical

Side-by-Side

:::note
This is a note
:::

:::tip Pro Tip
This is a tip with a title
:::

:::{note}
This is a note
:::

:::{tip} Pro Tip
This is a tip with a title
:::

The only difference::::note → :::{note}(add curly braces).

Component → Directive Translation

Tabs

import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';

<Tabs>
  <TabItem value="js" label="JavaScript">
    ```javascript
    console.log("Hello");
    ```
  </TabItem>
  <TabItem value="py" label="Python">
    ```python
    print("Hello")
    ```
  </TabItem>
</Tabs>

:::{tab-set}
:::{tab} JavaScript
```javascript
console.log("Hello");
```
:::{/tab}
:::{tab} Python
```python
print("Hello")
```
:::{/tab}
:::{/tab-set}

Code Blocks

import CodeBlock from '@theme/CodeBlock';

<CodeBlock language="python" title="hello.py" showLineNumbers>
def hello():
    print("Hello!")
</CodeBlock>

```python title="hello.py"
def hello():
    print("Hello!")
```

Cards / Feature Grid

import {Card, CardGrid} from '@site/src/components/Card';

<CardGrid>
  <Card title="Quick Start" href="/docs/quickstart">
    Get started in 5 minutes
  </Card>
  <Card title="API Reference" href="/docs/api">
    Complete API documentation
  </Card>
</CardGrid>

:::{cards}
:columns: 2

:::{card} Quick Start
:link: /docs/quickstart/

Get started in 5 minutes
:::{/card}

:::{card} API Reference
:link: /docs/api/

Complete API documentation
:::{/card}

:::{/cards}

Collapsible Sections

<details>
  <summary>Click to expand</summary>

  Hidden content here with **markdown** support.
</details>

:::{dropdown} Click to expand
:icon: info

Hidden content here with **markdown** support.
:::

Live Code Editor

```jsx live
function Hello() {
  return <div>Hello World!</div>;
}
`

<!-- Option 1: Use embed directives (recommended) -->
:::{codesandbox} sandbox-id
:title: Interactive Example
:::

<!-- Option 2: Link to external playground -->
[Try it on CodeSandbox](https://codesandbox.io/s/example)

<!-- Option 3: Static code example -->
```jsx
function Hello() {
  return <div>Hello World!</div>;
}
```

:::{codesandbox} sandbox-id
:title: My CodeSandbox Example
:::

:::{stackblitz} project-id
:title: StackBlitz Demo
:::

:::{codepen} user/pen-id
:title: CodePen Example
:::

What You Don't Need Anymore

Configuration Comparison

Basic Config

module.exports = {
  title: 'My Site',
  tagline: 'Documentation made easy',
  url: 'https://example.com',
  baseUrl: '/',

  presets: [
    [
      '@docusaurus/preset-classic',
      {
        docs: {
          sidebarPath: require.resolve('./sidebars.js'),
        },
        theme: {
          customCss: require.resolve('./src/css/custom.css'),
        },
      },
    ],
  ],
};

[site]
title = "My Site"
description = "Documentation made easy"
baseurl = "https://example.com"
theme = "bengal"

Sidebar Configuration

module.exports = {
  docs: [
    'intro',
    {
      type: 'category',
      label: 'Getting Started',
      items: ['quickstart', 'installation'],
    },
    {
      type: 'category',
      label: 'Guides',
      items: ['guide1', 'guide2'],
    },
  ],
};

<!-- Bengal auto-generates sidebar from directory structure -->
<!-- Control ordering with weight frontmatter: -->

<!-- content/docs/getting-started/_index.md -->
---
title: Getting Started
weight: 10
---

<!-- content/docs/getting-started/quickstart.md -->
---
title: Quickstart  
weight: 10
---

<!-- content/docs/getting-started/installation.md -->
---
title: Installation
weight: 20
---

Feature Comparison

What Bengal Has (No React Required)

What's Different (Trade-offs)

MDX-Specific Migration

Imports Don't Work (You Don't Need Them)

// ❌ MDX - Won't work in Bengal
import MyComponent from '@site/src/components/MyComponent';

<MyComponent prop="value" />

<!-- ✅ Bengal - Use built-in directives instead -->
:::{card} Title
:link: /path/

Content here
:::

Export/Props Don't Work (Use Frontmatter)

// ❌ MDX - Won't work
export const data = { version: '2.0' };

Current version: {data.version}

<!-- ✅ Bengal - Use frontmatter -->
---
title: My Page
version: "2.0"
---

Current version: {{ page.metadata.version }}

JSX in Markdown → Use Directives or HTML

// ❌ MDX - Won't work
<div className="custom-box">
  <h3>Custom Content</h3>
  <p>With JSX styling</p>
</div>

<!-- ✅ Bengal - Use directive or HTML -->
:::{card} Custom Content
:class: custom-box

With directive styling
:::

<!-- Or plain HTML (still works) -->
<div class="custom-box">
  <h3>Custom Content</h3>
  <p>With HTML styling</p>
</div>

Directory Structure Comparison

What Bengal Adds

---
title: API Reference
api_version: "3.0"
base_url: "https://api.example.com"
---

# {{ page.title }}

Current API version: **{{ page.metadata.api_version }}**

Base URL: `{{ page.metadata.base_url }}`

# data/glossary.yaml
terms:
  - term: API
    definition: Application Programming Interface
    tags: [api, core]

  - term: Endpoint
    definition: A specific URL path that accepts requests
    tags: [api, http]

<!-- In any page -->
:::{glossary}
:tags: api
:::

<!-- Auto-generate cards from child pages -->
:::{child-cards}
:columns: 3
:::

<!-- Show sibling pages in section -->
:::{siblings}
:::

<!-- Prev/Next navigation links -->
:::{prev-next}
:::

<!-- Breadcrumb navigation -->
:::{breadcrumbs}
:::

<!-- Related pages by tag -->
:::{related}
:tags: api, authentication
:::

:::{data-table}
:source: data/endpoints.yaml
:columns: method, path, description
:sortable: true
:filterable: true
:::

Migration Checklist

Quick Reference Card

Common Questions

:::{codesandbox} example-id
:title: Interactive Example
:::

:::{stackblitz} example-id
:title: StackBlitz Demo
:::

[Try it on CodeSandbox](https://codesandbox.io/s/example)
[Open in StackBlitz](https://stackblitz.com/edit/example)

Related Migration Guides

If you're migrating from multiple platforms or need additional context:

• From Mintlify - Similar MDX component migration patterns
• From Fern - API documentation migration (if using OpenAPI)
• Migration Overview - Common migration patterns across all platforms

Next Steps

• Directives Reference - All available directives
• Writer Quickstart - Full markdown guide
• Configuration Reference - Config options
• Cheatsheet - Quick syntax reference

How Content is Organized

Your folder structure becomes your site structure. No configuration required.

The Three Content Types

content/
└── about.md  →  /about/

content/
└── blog/
    ├── _index.md     →  /blog/ (list page)
    ├── post-1.md     →  /blog/post-1/
    └── post-2.md     →  /blog/post-2/

content/
└── gallery/
    ├── index.md      →  /gallery/
    ├── photo-1.jpg   (co-located asset)
    └── photo-2.jpg   (co-located asset)

Quick Reference

docs/
├── _index.md
├── getting-started/
│   ├── _index.md
│   └── installation.md
└── advanced/
    ├── _index.md
    └── plugins.md

---
title: Docs
cascade:
  type: doc
  toc: true
---

Frontmatter Reference

Complete reference for all frontmatter fields available in Bengal pages.

Required Fields

Common Fields

Taxonomy Fields

Author Patterns

Bengal supports multiple author patterns for flexibility:

Simple string (reference to data registry):

author: lbliii

Nested object (inline):

author:
  name: Lawrence Lane
  github: lbliii
  bio: Technical writer and developer

Multiple authors (list of strings or objects):

authors:
  - lbliii
  - name: Jane Smith
    github: janesmith

Flat author fields (legacy pattern):

author: Lawrence Lane
author_avatar: /images/lawrence.jpg
author_title: Senior Developer
author_bio: Technical writer and developer
author_links:
  - text: GitHub
    url: https://github.com/lbliii

Author Data Registry

Define authors once indata/authors.yamland reference by key:

# data/authors.yaml
lbliii:
  name: Lawrence Lane
  github: lbliii
  bio: Technical writer and developer
  avatar: /images/lawrence.jpg

Then reference in frontmatter:

author: lbliii

Access in templates:

{% let author_info = site.data.authors[page.metadata.author] %}
{{ author_info.name }} — {{ author_info.bio }}

Component Model Fields

Bengal uses a Component Model where every page has three aspects: identity (type), appearance (variant), and data (props).

SEO Fields

Navigation Fields

Advanced Fields

Custom Fields (Props)

Any fields not part of Bengal's standard frontmatter are automatically available as custom props. Add them at the top level of your frontmatter.

Standard fields (extracted to PageCore):

• title, description, date, draft, weight, slug, url, aliases, lang
• tags, categories, keywords, authors, category
• type, variant, layout, template
• canonical, noindex, og_image, og_type
• menu, nav_title, parent
• cascade, outputs, resources, toc

Custom fields (Component Model props):

• Any field not listed above goes intopage.props
• Access in templates viapage.params (includes all frontmatter) or page.props(custom fields only)

Example

---
title: My Page
description: Page description
weight: 10
type: doc
icon: code
card_color: blue
custom_setting: value
---

Access custom fields in templates:

{# page.params includes all frontmatter (standard + custom) #}
{{ page.params.icon }}
{{ page.params.get('card_color', 'default') }}

{# page.props contains only custom fields #}
{{ page.props.icon }}

Note: The props: key is only used in skeleton manifests (bengal project skeleton apply). For regular markdown files, use flat frontmatter (all fields at top level).

Example

---
title: Getting Started with Bengal
description: Learn how to install and configure Bengal for your first site
date: 2025-01-15
draft: false
weight: 10
tags: [tutorial, beginner]
categories: [Getting Started]
authors: [jane-doe]
type: tutorial
variant: wide
cascade:
  type: doc
difficulty: beginner
time_estimate: 15 minutes
---

In this example:

• Standard fields (title, date, weight, etc.) are extracted to PageCore
• difficulty and time_estimate are custom props accessible via page.params
• cascade propagates type: docto all child pages

Cascade Configuration

Thecascadefield applies values to all descendant pages:

---
title: Documentation
cascade:
  type: doc
  variant: docs
  draft: false
---

All pages under this section inherit these values unless they override them. Page-level values always take precedence over cascaded values.

Configuration

Control Bengal's behavior throughbengal.tomland environment-specific settings.

Configuration Methods

Bengal loads configuration from either theconfig/ directory (preferred) OR bengal.toml (legacy/simple). If config/ exists, bengal.tomlis ignored.

Overrides apply in order: Base Config → Environment Overrides → CLI Flags.

Quick Start

# bengal.toml
[site]
title = "My Site"
baseurl = "https://example.com"
language = "en"

[build]
output_dir = "public"

[theme]
name = "default"

Configuration Patterns

# bengal.toml - everything in one place
[site]
title = "My Blog"

[build]
output_dir = "public"

[theme]
name = "default"

config/
├── _default/
│   ├── site.yaml
│   ├── build.yaml
│   └── theme.yaml
└── environments/
    ├── production.yaml
    └── staging.yaml

Environment Overrides

Run with different settings per environment:

bengal build --environment production

# config/environments/production.yaml
site:
  baseurl: "https://example.com"

build:
  minify_html: true
  strict_mode: true

assets:
  fingerprint: true

Build Options Reference

Key[build]configuration options:

Asset Options

Configure asset processing in the[assets]section:

[assets]
minify = true
optimize = true
fingerprint = true

Template Validation

Enablevalidate_templatesto catch template syntax errors early during builds:

[build]
validate_templates = true

When enabled, Bengal validates all templates (HTML/XML) in your template directories before rendering. This provides early feedback on syntax errors, even for templates that might not be used by every page.

[build]
validate_templates = true

[build]
validate_templates = true
strict_mode = true

When to enable:

• During active theme development
• In CI/CD pipelines
• When debugging template issues

What it catches:

• Template syntax errors (unclosed tags, invalid filters) in Kida and Jinja2
• Unknown filter names
• Template assertion errors

Multi-Variant Builds

Build different site variants (OSS vs Enterprise, brand1 vs brand2) from one content tree. Setparams.edition per environment and add editionto page frontmatter to filter content.