Welcome to the Example Page
This is example.html, the third page in this demonstration. Notice how the same 📝welcome token resolves to this content, which is unique to the example page.
How This Works
The SSI engine looks for markdown-texts/example/welcome.md when processing example.html, finds this file, and includes it here!
This is SSI’s killer feature: the same template structure, but different content based on the page being processed.
Page-Specific Content
This demonstrates page-specific variable resolution:
Current Page Variables
- Page Title: Page-Specific Includes [Example]
- Page Description: This is the example page demonstrating per-page resolution
- Demo Focus: See how the same tokens resolve differently per page
Global Variables (Same on All Pages)
- Site Name: [[SITE_NAME]]
- Author: Super-Simple Includes Project
- Global Feature: Global variables work on all pages
- Site Version: 1.0
How Page-Specific Variables Work
- Default Values: Defined in
[_] section of strings.toml
- Page Overrides: Each page can have its own
[pagename] section
- Resolution Order: Page-specific first, then global defaults
- Same Variable Names: Different values per page
Navigate between pages to see how the same variables show different content!
Why Per-Page Context Matters
Per-page content resolution is one of SSI’s most useful features — and it
requires zero configuration beyond directory structure.
The key insight: you can use a shared widget (header, sidebar, nav, footer,
call-to-action) across every page in your site, and each page can supply its
own values for that widget’s tokens. The widget file stays the same; the data
changes per page.
This means:
- Write a nav widget once. Every page supplies its own “current page” label.
- Write a hero section once. Every page has its own headline and subheading.
- Write a metadata block once. Every page fills in its own title and description.
Adding a new page never requires editing any shared widget files. Drop the page
in the right place, add a subdirectory with the page-specific content files, and
the site builds correctly.
How It Scales
As sites grow, this pattern keeps the template layer stable. Compare this to
approaches where each page hardcodes its own copy of shared components — edits
to the shared structure require touching every file. With per-page resolution,
the shared structure lives in one place.
See it in a real context: Example 99 (full-site) uses per-page resolution
throughout its four-page structure, with a shared header and footer receiving
different page context on each page.