Learn about page-specific variables
This is the About page! This welcome message is coming from texts/about/welcome.md, which is specific to the about page.
Notice how this page has the same 📜welcome.md include as the Home page, but shows completely different content because of page-specific text resolution.
What Makes This Page Different
This about page uses variables defined in the [about] section of strings.toml, which override the default values from the [_] section.
Page-Specific Text Resolution
This file is located at texts/about/welcome.md. When about.html includes 📜welcome, Super-Simple Includes looks for:
- Page-specific version →
texts/about/welcome.md ← You’re reading this!
- Default fallback →
texts/welcome.md (used if page-specific doesn’t exist)
Both Variables AND Text Files Can Be Page-Specific
- Variables: Same
💬page_title but different values per page
- Text Files: Same
📜filename.md but different content per page
Navigate back to the Home page to see how it shows different content from the same include!
Page-Specific Content
This demonstrates page-specific variable resolution:
Current Page Variables
- Page Title: Page-Specific Includes [About]
- Page Description: This is the about page with different variables
- Demo Focus: Learn about page-specific variables
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.