DynamicPageList3 pagelinks compatibility fix

Production remediation log: DynamicPageList3 pagelinks compatibility fix

Date: 2026-06-11

Environment: production (weaponofmusicaldefense.com) and dev mirror (dev.weaponofmusicaldefense.com)

Summary

After cutover to the upgraded MediaWiki stack, many content pages that include DynamicPageList3 (DPL) output began failing with Wikimedia\Rdbms\DBQueryError (HTTP 500). The failure was caused by DPL building pagelinks queries with assumptions incompatible with the active links schema. A targeted compatibility patch was applied in DPL Query.php, then propagated to dev. Affected pages now render normally (HTTP 200), with no immediate recurrence in recent logs.

Problem observed

• Affected behavior:
  • page view returned HTTP 500
  • ?action=edit still returned 200 and showed page source
• Representative failing pages:
  • https://weaponofmusicaldefense.com/thelibrary/Winston_Churchill
  • https://weaponofmusicaldefense.com/thelibrary/Hugh_Fitzgerald
  • https://weaponofmusicaldefense.com/thelibrary/Appeasement
• Error signatures observed during diagnosis:
  • Unknown column 'pl.pl_title' in 'field list'
  • Unknown column 'pl.pl_target_id' in 'on clause'

[upgrades]

Root cause

DPL query construction in DynamicPageList3/includes/Query.php used pagelinks title/namespace assumptions that are not always valid after MediaWiki links schema migration. In the upgraded schema, pagelinks may reference linktarget via pl_target_id rather than storing pl_namespace/pl_title directly for the query path DPL was building. Additionally, one generated SQL shape mixed join styles in a way that caused alias scoping issues, producing an invalid ON clause reference.

Patch applied

Patched methods:

• _linksto(...)
• _notlinksto(...)

Key compatibility changes:

1. Use MediaWiki links migration API to discover correct title fields at runtime:
   • MediaWikiServices::getInstance()->getLinksMigration()->getTitleFields('pagelinks')
2. Detect when query fields are lt_* and therefore require linktarget:
   • needsLinkTarget = strpos($nsField, 'lt_') === 0 || strpos($titleField, 'lt_') === 0
3. In _linksto(...), when needsLinkTarget is true:
   • add linktarget table alias lt
   • relate rows via lt.lt_id = pl.pl_target_id
   • use lt.<field> expressions for namespace/title comparisons and selected aliases (sel_ns, sel_title)
4. In _notlinksto(...), when needsLinkTarget is true:
   • use a subquery joining pagelinks pl_sub to linktarget lt_sub on lt_sub.lt_id = pl_sub.pl_target_id
   • evaluate title/namespace filters against lt_sub.<field>
5. Correct SQL scoping issue in _linksto(...) by applying the lt↔pl relation as a WHERE condition (addWhere('lt.lt_id = pl.pl_target_id')) instead of the prior problematic join-form expression.

Files changed

• mw_data_staging/extensions/DynamicPageList3/includes/Query.php (production-served tree)
• mw_data/extensions/DynamicPageList3/includes/Query.php (dev tree mirror)

Why this patch was needed

Without this patch, DPL generated SQL that referenced columns/aliases not valid for the active links schema and join shape, causing fatal query exceptions and site-visible HTTP 500s on pages using DPL link filters. The patch makes DPL schema-aware at runtime through LinksMigration and uses SQL forms compatible with the current schema.

Validation

• Re-tested previously failing production pages: now HTTP 200.
• Re-tested corresponding dev pages: now HTTP 200.
• Confirmed production and dev DPL Query.php are synchronized.
• Recent production log scan after patch showed no new DBQueryError spikes for this incident pattern.

Follow-up recommendations

• Monitor for additional DPL code paths that may still assume legacy/new-incompatible pagelinks field usage (for example in related link-filter parameters).
• Upstream this compatibility patch (or move to an upstream DPL release containing equivalent links-migration support) to reduce local patch drift.