Skip to content

Inline Codex icons in PageNetworkOptions and fix Title Icon URL#98

Merged
alistair3149 merged 1 commit into
masterfrom
inline-codex-icons
May 8, 2026
Merged

Inline Codex icons in PageNetworkOptions and fix Title Icon URL#98
alistair3149 merged 1 commit into
masterfrom
inline-codex-icons

Conversation

@alistair3149
Copy link
Copy Markdown
Member

@alistair3149 alistair3149 commented May 8, 2026

image

Summary

Fixes default group icons (and OOUI Title Icons) 404'ing on wikis with pretty article URLs (/wiki/Foo). The root cause was the same in both call sites: bare relative paths handed to vis-network, which the browser then resolved against the document URL.

  • PageNetworkOptions defaults switch to canonical Codex icon namescdxIconArticle, cdxIconArticleNotFound, cdxIconLinkExternal. A new PHP unit IconResolver looks each name up in MediaWiki's bundled resources/lib/codex-icons/codex-icons.json and emits an inline SVG data: URI in data-options. The lookup tolerates all three icon shapes that the JSON ships (plain string, {ltr, ...}, and {default, langCodeMap, ...}); unknown names log a warning and fall through. Absolute URLs and data: URIs pass through unchanged. Other relative paths get prefixed with $wgScriptPath for backward-compat with users who configured MW-relative paths in LocalSettings.php.
  • OOUI Title Icon URL is prefixed with mw.config.get('wgScriptPath') in resources/js/ApiPageConnectionRepo.js (defaulting to '' when unset) so the URL is absolute regardless of article URL style. Title Icon's catalogue is OOUI-style; a Codex migration would need a name-mapping table and per-page user data — out of scope.

The resolver runs after the defaults+user-options merge in NetworkUseCase::getVisJsOptions(), so user-provided per-call options receive the same treatment. Extension::getFactory() reads paths via MainConfigNames::BaseDirectory and MainConfigNames::ScriptPath, no static-analysis suppressions needed.

Test plan

  • composer phpunit — 36/36 (was 19; 17 new in IconResolverTest)
  • vendor/bin/phpcs -p -s — clean
  • vendor/bin/phpstan analyse (level 1) — No errors
  • vendor/bin/psalm (errorLevel 2) — No errors found
  • Runtime smoke against the local dev wiki — confirmed data-options contains valid data:image/svg+xml;base64,… URIs that decode to real Codex SVGs; icons render in the browser
  • CI: all five PHPUnit matrix rows + static-analysis + code-style pass

Out of scope

  • Per-group icon colour / theme adaptation. The bundled Codex SVGs render with their default fill (black). Wikis can override per group in LocalSettings.php. Worth a follow-up if the white-card-on-dark-theme look bothers anyone.
  • Migrating Title Icon's OOUI icon names to Codex (per-page user data + name-mapping table).
  • Refactoring the existing MediaWikiServices::getInstance() service-locator usage in NetworkConfig.

Previously, the default group images and Title Icon-resolved
icons were emitted as bare relative paths, e.g.
  resources/lib/ooui/themes/wikimediaui/images/icons/article-rtl-progressive.svg
The browser resolves these against the document URL: works on
query-string article URLs (/w/index.php?title=Foo) but 404s on
pretty article URLs (/wiki/Foo), the typical production setup.

PageNetworkOptions defaults switch to canonical Codex icon names
(cdxIconArticle, cdxIconArticleNotFound, cdxIconLinkExternal).
A new PHP unit, IconResolver, looks each name up in MediaWiki's
bundled codex-icons.json and emits an inline SVG data URI in the
data-options HTML attribute. The lookup tolerates all three icon
shapes that the JSON ships (plain string, {ltr, ...}, and
{default, langCodeMap, ...}). Unknown names emit a logger warning
and fall through unchanged. Absolute URLs and data: URIs pass
through unchanged. Other relative paths are prefixed with
$wgScriptPath for backward-compat with users who configured
MW-relative paths in LocalSettings.php.

The resolver runs after the defaults+user-options merge in
NetworkUseCase::getVisJsOptions(), so user-provided per-call
options receive the same treatment. Extension::getFactory() reads
the codex-icons.json path and script path from MainConfigNames
via the main config service.

The OOUI Title Icon URL in resources/js/ApiPageConnectionRepo.js
is also prefixed with mw.config.get('wgScriptPath') (defaulting to
the empty string when unset) so its URL is absolute regardless of
article URL style. Title Icon's icon catalogue is OOUI-style; a
Codex migration there would need a name-mapping table and per-page
user data, out of scope here.
@alistair3149 alistair3149 force-pushed the inline-codex-icons branch from e1e73ee to 8a4fbe7 Compare May 8, 2026 20:32
@alistair3149 alistair3149 merged commit d2acb2b into master May 8, 2026
7 checks passed
@alistair3149 alistair3149 deleted the inline-codex-icons branch May 8, 2026 20:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant