Come build with us.
Stacks API v13 for Stacks 5.0
Theme API
Schema: Parent-theme templates are loaded first. A child theme overrides a parent template by supplying another template with the same frontmatter id.
<key>parent</key>
<string>com.yourhead.stacks.theme.base</string>
Base’s plist comments describe the same model:
parent to com.yourhead.stacks.theme.base.For example, a child can provide id: body while continuing to use Base’s page, head, foot, css and js templates.
The template ID performs the override:
---
id: body
---
Do not assume that copying the parent’s filename is sufficient if the frontmatter ID is missing or different.
The schema accepts inheritsFrom as an optional string. Sample includes both:
<key>parent</key>
<string>com.yourhead.stacks.theme.base</string>
<key>inheritsFrom</key>
<string>com.yourhead.stacks.theme.base</string>
Blank uses parent without inheritsFrom and still demonstrates parent-template inheritance.
Unconfirmed: The independent effect of theme-level inheritsFrom is not explained by the theme schema or comments. In the normal Stack API, inheritsFrom imports controls and properties from another stack. It may perform an analogous property role for themes, but this should not be treated as confirmed theme behaviour without a focused test.
Authoring tools must preserve both keys independently. They must not rewrite one as the other or silently add/remove either key.
The available files do not specify loader behaviour when the parent identifier cannot be resolved. A distributed child theme should therefore avoid depending on a third-party parent unless that dependency is installed with it and versioned carefully.
Use Base as the parent when the theme only needs to replace selected presentation units. Build a fully independent document only when the theme deliberately needs control over the complete HTML structure and has tests for all standard insertion points.