Talk:Known Site Issues & Fixes

SMW Silently Ignores #set on Template: Namespace Pages

Symptom: Admin Page Status fields display correctly and store correctly in Cargo, but never appear in Special:Browse or SMW queries — specifically and only on pages in the Template: namespace (e.g. Template:Admin Page Status/doc, Template:GameModule/doc).

Cause: SMW's `$smwgNamespacesWithSemanticLinks` configuration excludes the Template namespace by default. `#set` calls are silently no-ops there — no error, no warning, just nothing stored.

Fix: Set `$smwgNamespacesWithSemanticLinks[NS_TEMPLATE] = true;` in LocalSettings.php, then purge affected pages.

How it was found: Bisection — confirmed the template itself worked (fresh test page, main namespace, succeeded), then narrowed by testing the identical block across pages in different namespaces until the pattern (Template: fails, everywhere else works) became visible. Content length, field names, and phrasing were all red herrings ruled out along the way. Sovereign (talk) 05:10, 16 July 2026 (EDT)

Calibration Report - 2026-07-14

Reviewer: Sovereign Review Type: Self-Assessment

Summary of Changes

• Changed `Known Site Issues & Fixes` to `Talk:Known Site Issues & Fixes` in both links, attempting to fix a known failure on `Template:` namespace pages (where `PAGENAME` strips the namespace prefix, causing links to resolve incorrectly).
• This fix did not work. Root cause remains unidentified after this attempt.
• Added an explicit, permanent warning: this template must not be used on pages in the `Template:` namespace.
• Added a breadcrumb pointing to Known Site Issues & Fixes for tracking and future investigation.

instrument_grade / validation

No change to overall page rating from this pass — this is a known, disclosed limitation, not a hidden defect. Rated per standing Admin Page Status block; this specific issue is tracked separately as an open technical item, not folded into content confidence.

Open Items

• Root cause of `Template:` namespace failure remains unknown. See Known Site Issues & Fixes for the tracked entry.
• Do not attempt further fixes without first checking whether this is related to the earlier-resolved SMW namespace issue, or something distinct.

See the Game. Refuse the Game. Build Better.

Sovereign (talk) 05:11, 16 July 2026 (EDT)

Standalone Transparency Fails on Template: Namespace Pages

Status: Open — unresolved

Symptom: Template:Standalone Transparency's Talk-page links do not resolve correctly when the template is used on a page in the `Template:` namespace.

Root cause: Not yet identified. May or may not be related to the earlier-resolved SMW namespace exclusion bug (`$smwgNamespacesWithSemanticLinks` not including `NS_TEMPLATE`) — that fix addressed semantic data storage, not link resolution, so the underlying mechanisms are likely different even though both manifest on the same namespace.

Fix (or attempted fix): Replaced `Known Site Issues & Fixes` with `Talk:Known Site Issues & Fixes` in both link targets, on the theory that the failure matched the known pattern where `PAGENAME` silently strips the namespace prefix. This did not resolve the issue.

Current mitigation: `

Page Transparency & Calibration

• Calibration Log & Decision Records (via Talk Page) — This page uses Talk-only calibration tracking. Full history of reviews, version changes, calibration decisions, and any governance reasoning behind structural decisions all live on the same Talk page, per Calibration Log: When to Create One and Decision Records: Governance Memory. Not every Calibration Log entry is a Decision Record — scan the Talk page's headings for entries specifically marked as decisions; the link itself being active only confirms this page has calibration history, not that a formal decision was ever recorded.
• View Current Page History — Complete edit history.

This page is under continuous calibration in line with the Permanent Beta principle.

---

Public Discussion Welcome

Questions, suggestions, feedback, disagreement, and proposed improvements are welcome on the Talk page.

Light rules:

• Prefer evidence and concrete examples over slogans.
• Apply Diagnostic Inversion Test when criticizing — the same standard to this page that you would apply elsewhere.
• Distinguish observation from conclusion.
• Calibration entries and Decision Records are maintenance records; public discussion belongs in ordinary Talk threads.
• This framework remains in Permanent Beta. Better calibration is always in scope.

` is marked "do not use on `Template:` pages." No workaround currently exists for templates needing a transparency footer in that namespace. Template:Doc Page Transparency may be a safe alternative but has not been separately verified against this same failure mode.

Found by: Sovereign, 2026-07-14, during general template cleanup pass.

Next steps: Not yet investigated further. Worth checking whether Template:Doc Page Transparency has the identical bug before assuming it's a safe alternative. Sovereign (talk) 05:23, 16 July 2026 (EDT)

SMW Cannot Reliably Split Multi-Value Fields (depends_on)

Status: Resolved (via workaround — switched storage/query mechanism from SMW to Cargo)

Symptom: A page's `depends_on` field, when containing multiple semicolon-separated page names, was only ever recognized by `` as matching one of the listed values — typically the last one set — rather than all of them independently. This meant the "Calibration Dependent" auto-generated section silently missed most real dependents on any page whose `depends_on` field contained more than one entry.

Root cause: SMW was storing the full `depends_on` string as a single value rather than splitting it into multiple independent stored values, despite the field being intended as a delimited list.

Fix attempts (in order, all failed before the working fix was found):

1. Added `|+sep=;;` inline to the `#set` call in Template:Admin Page Status (per Copilot's suggestion to use double-semicolons as the separator). Did not work.
2. Attempted declaring the separator at the property level, on `Property:Has dependency`, using `` to match the existing single-semicolon data format used across the wiki. Did not work.
3. Attempted using `{{#arraymap:...}}` to manually split the string and generate one `#subobject` per value. Multiple syntax variations tested; `#arraymap` consistently failed to split on `;` correctly, instead passing the entire unsplit string through as a single iteration. Did not work.

Working fix: Abandoned SMW's `#set`/`+sep` mechanism for this field entirely. Changed the field's declared type in Template:Admin Page Status's `#cargo_declare` block from `Has_dependency = String` to `Has_dependency = List (;) of String`, then ran "Recreate data" on the `AdminPageStatus` table via `Special:CargoTables`. Queries against this field were switched from `#ask` (SMW) to `#cargo_query` (Cargo), using Cargo's `HOLDS` operator to match individual list values — e.g. `|where=Has_dependency HOLDS "PageName"`. This worked immediately, including correctly on pages with multiple dependencies.

Practical implication: Cargo's native list-field support (`List (delimiter) of Type`) is more reliable than SMW's `+sep`/subobject-based approach for this wiki's setup. For any future multi-value field, default to declaring it as a Cargo list type and querying with `#cargo_query`, rather than attempting SMW's list mechanisms first.

Found by: Sovereign, 2026-07-14, while building the "Calibration Dependent" auto-generated dependency-lookup section for Core-priority pages.

Next steps: None currently outstanding — issue considered resolved via the Cargo-based workaround. If SMW's native list handling is ever revisited (e.g. after a version upgrade), this entry documents exactly what was tried and failed, so it isn't retested blind. Sovereign (talk) 06:52, 16 July 2026 (EDT)