Talk:Known Site Issues & Fixes

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.

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)

Update, 2026-07-14: Confirmed the identical failure on a second template — Template:Subpage Hub-Linked Transparency — tested directly on a `Template:` namespace page, same symptom (links fail to resolve correctly). This template uses the same `Known Site Issues & Fixes` pattern as `Standalone Transparency`, reinforcing that the root cause is likely shared across any template using `Known Site Issues & Fixes`-family functions when placed in `Template:` namespace — not something unique to one template's specific code. Both templates now carry an explicit "do not use on `Template:` pages" warning. Root cause still not identified. Project owner has a possible lead to investigate later.

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)

Cargo Field Type Mismatch: String vs. Page for Dependency Lists

Status: Resolved

Symptom: A Cargo list field (`Has_dependency`, declared as `List (;) of String`) correctly matched via `HOLDS` in queries filtering *by* the field, but failed to render as separate, clickable, linked items when the field's own values were *displayed* — output either merged into one unclickable string, or rendered as raw unlinked text depending on the display method attempted.

Root cause: The field was declared as `List (;) of String`, not `List (;) of Page`. Cargo auto-links fields of type `Page` (the same mechanism that auto-links `_pageName` in every query); a `String`-type field, list or not, is treated as plain text with no page-linking behavior, regardless of query format used.

Fix attempts before root cause found (all logged for future reference, none worked):

1. `#arraymap` to manually split and link each value — failed consistently across three separate attempts, confirmed the extension does not reliably split on `;` in this wiki's configuration (see prior entry above for the original discovery of this).
2. A helper template (Template:Wikilink Wrapper) combined with `format=template` in `#cargo_query` — `format=template` was found to call the wrapper once per query result row, not once per list item within a field, so the entire delimited string was passed as a single value regardless of the wrapper's own logic.
3. Various `#ask`/SMW-based attempts, prior to switching to Cargo entirely for this field (see earlier "SMW Cannot Reliably Split Multi-Value Fields" entry).

Working fix: Changed the field declaration in Template:Admin Page Status's `#cargo_declare` from `Has_dependency = List (;) of String` to `Has_dependency = List (;) of Page`, then ran "Recreate data" on `AdminPageStatus` via `Special:CargoTables`. With the correct type, `format=ul` in `#cargo_query` correctly split and auto-linked each value with no wrapper template or manual splitting needed.

Remaining cosmetic limitation: Attempting to display this field as a `format=table` (matching the style of the separate, working Template:Calibration Dependent query) did not produce one row per list item — it returned the whole list crammed into a single cell. Root cause not further investigated; resolved by accepting `format=ul` (inline bulleted links) as the final display format instead of pursuing a table layout. The two resulting templates — Template:Calibration Dependent (table) and Template:Calibration Dependencies Display (inline list) — are used together and are considered visually complementary, not a mismatch requiring further fixing.

Found by: Sovereign, 2026-07-14, while building the auto-generated Calibration Dependencies display.

Next steps: None outstanding. If a genuine table format for this specific query shape is ever needed, revisit Cargo's list-field-expansion documentation directly rather than the format variations already tried here. Sovereign (talk) 09:12, 16 July 2026 (EDT)

Update, 2026-07-14: Confirmed a third instance — `{ {Standalone Transparency}}` also fails on `Template:New Page Seed`, same symptom as the two prior instances. Removed rather than left broken; this page currently has no transparency footer at all. Root cause still not identified across all three instances. Also noted during the same investigation: a separate, unrelated Cargo data anomaly (duplicate stored rows for a single page, likely from repeated saves) was found and worked around via `limit=1` on the affected query — logged separately in the page's own Calibration Report, not believed related to this transparency bug. Sovereign (talk) 06:37, 19 July 2026 (EDT)

SMW Job Queue Backlog: Properties Never Actually Stored

Status: Root cause identified — active, ongoing risk until confirmed resolved

Symptom: Admin Page Status (and other) fields displayed correctly on the page itself, with no visible error, but did not appear when queried via `#ask`, Special:Browse, or `Template:Calibration Dependent`. The page content was correct; the underlying SMW property data was simply absent from the database.

Root cause: SMW writes property data to its own tables via the job queue, not synchronously at page save. If the job queue backs up, or a `#set` call fails silently for any reason (a type mismatch, a malformed value, or simply queue lag), the page still saves and displays normally — but the actual semantic fact never lands in the database until the job queue processes it. This was confirmed by running `runJobs.php` manually: previously-invisible property data appeared immediately afterward, with a large "page propagation" warning shown by the wiki during processing, confirming a substantial backlog existed.

This finding likely explains, and supersedes, two previously "root cause unknown" entries on this page: Template:Standalone Transparency and Template:Subpage Hub-Linked Transparency, both logged earlier as failing on `Template:` namespace pages with no identified cause. Both should be re-tested now — the failure may have been job-queue backlog rather than a namespace-specific bug at all.

An earlier, related but distinct finding — some SMW properties were typed `Page` when they should have been `Text` — is a real and separate issue (Page type expects the value to resolve as a page-link target; free text doesn't fit that type) and was also found and partially corrected during this investigation. Both issues may have been compounding: a `Page`-type mismatch could itself cause a `#set` call to fail silently, contributing to the job queue never receiving valid data to process in the first place.

Current mitigation: Run `runJobs.php` (or trigger job queue processing through whatever mechanism is available) periodically, and specifically after any batch of page creation/edits, until automated queue processing is confirmed to be running on a real schedule.

Not yet done, tracked as ongoing: A full audit of which SMW properties are typed `Page` vs. `Text`, correcting mistyped fields one at a time. Project owner has confirmed this will be done incrementally, not all at once — do not assume all properties are correctly typed until each has been individually checked. Any query returning unexpectedly empty or incomplete results should be treated as possibly affected by this issue until the audit is complete.

Found by: Sovereign, 2026-07-14, while investigating why "on closer inspection" and dependency-related fields appeared to work via Cargo but not consistently via SMW `#ask`.

Next steps: Confirm whether job queue processing runs on an automated schedule (cron) or only manually. Re-test Standalone Transparency and Subpage Hub-Linked Transparency against this finding. Continue the incremental Page-vs-Text property audit. Sovereign (talk) 11:45, 17 July 2026 (EDT)

Calibration Report — Known Site Issues & Fixes — 2026-07-20 (Structural Pre-Cal)

• **Page:** Known Site Issues & Fixes
• **Summary:** Structural pre-calibration pass. Four nonconformances found and corrected.
• **Reviewer:** Sovereign
• **Review Type:** Self-Assessment (Structural only)

• • Summary of Changes:**
• Changed to canonical `| Calibration Type =`.
• Added required inline HTML comments on all fields.
• Added the three missing mandatory templates.
• Corrected template order to the required sequence.

• • Process Note:**

Nonconformances were logged before fixes were applied.

• • What This Report Does NOT Claim:**

No content calibration was performed.

See the Game. Refuse the Game. Build Better. Sovereign (talk) 09:25, 20 July 2026 (EDT)