Template:Category/Project/footer

Footer template for Category:Project pages — paired with Template:Category/Project.

Project pages invoke this template at the end of the page body so the project's build sections (Specifications / Components / Releases) and the cross-content lists (Guides, FAQs, Publications, SOPs) render BELOW any free-form prose the page author has added, not above it.

Why a separate template: The SemanticSchemas dispatcher auto-renders Category/Project at the top of every Project page (via the page's

call). Anything that lives in that template renders above the page's prose. Both the build data and the indexed cross-references read better below the prose — visitor scans the project narrative first, then drops to the data — so they live here in a footer template the page author drops in manually.

Usage:

at the bottom of every Project page. page defaults to Template:Category/Project/footer, which is the right value when the template is invoked from the project's own page (the normal case).

Renders, top to bottom:

Specifications — table of the latest Release's Specification

 subobjects (Name / Value / Unit). Project-level specs:
 in the root wiki.yml land on each Release page as
 subobjects; this section finds the most-recent Release by
 Has release date and surfaces its specs.

Components — table of every Component the latest Release

 links to via Has component (Version / Type /
 Description). Sorted by component name so the rows are stable
 across releases.

Releases — table of every Release tagged for this project

 (Version / Date / Artifact / Changelog), newest first.

Guides — every Category:Guide page tagged with this project.
FAQs — every Category:FAQ page tagged with this project.
Publications — every Category:Publication page tagged with

 this project, newest first.

SOPs — every Category:SOP page tagged with this project.

Each section's h2 renders unconditionally; empty sections show an italic "No X yet." line under the h2. The empty-state noise is intentional — it signals "this project has no guides yet, maybe add one" rather than hiding the affordance.

Why these lists may include admin-namespace pages: The cross-content lists don't filter by namespace, so an admin-namespace guide (e.g. Workshop admin:Setting up a new Workshop) tagged with this project will appear here. The public Guides directory (UI/guides_library) does filter those out row-side, but doing the same here would mean projecting through a row template for each section — more wikitext, more cost. For the typical case (no admin-namespace cross-tagging) the lists are identical to the public view; for the rare case, the admin page surfacing on the Project page is acceptable since the page itself is admin-restricted via the wiki's permissions.

Relation to the auto-backlinks footer: Category:Project carries show_backlinks_for=Has project, so SemanticSchemas's auto-rendered category footer also lists every page that links here. That footer is a flat "Pages linking here" list — it doesn't group by content type and it includes everything (Events, Training records, Stock entries, ...). The sections below target the content types a typical visitor actually wants to find; the auto-footer sits further down for the kitchen-sink view.

Properties read:

Specifications / Components / Releases: finds latest

 Release via  <this>
 sorted by Has release date desc; reads
 Has component off that Release and
 Specification subobjects via -Has subobject.
 Release table reads Has version,
 Has release date, Has artifact url,
 Has changelog.

Parameters:

page — the project page being rendered. Falls back

 to Template:Category/Project/footer.

Visual treatment is shared with Template:Category/Project via Template:Category/Project/styles.css — the .project-related wrapper and .project-related-empty empty-state class both live there.