Inline Codex icons in PageNetworkOptions and fix Title Icon URL#98
Merged
Conversation
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.
e1e73ee to
8a4fbe7
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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.PageNetworkOptionsdefaults switch to canonical Codex icon names —cdxIconArticle,cdxIconArticleNotFound,cdxIconLinkExternal. A new PHP unitIconResolverlooks each name up in MediaWiki's bundledresources/lib/codex-icons/codex-icons.jsonand emits an inline SVGdata:URI indata-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 anddata:URIs pass through unchanged. Other relative paths get prefixed with$wgScriptPathfor backward-compat with users who configured MW-relative paths inLocalSettings.php.mw.config.get('wgScriptPath')inresources/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 viaMainConfigNames::BaseDirectoryandMainConfigNames::ScriptPath, no static-analysis suppressions needed.Test plan
composer phpunit— 36/36 (was 19; 17 new inIconResolverTest)vendor/bin/phpcs -p -s— cleanvendor/bin/phpstan analyse(level 1) — No errorsvendor/bin/psalm(errorLevel 2) — No errors founddata-optionscontains validdata:image/svg+xml;base64,…URIs that decode to real Codex SVGs; icons render in the browserOut of scope
LocalSettings.php. Worth a follow-up if the white-card-on-dark-theme look bothers anyone.MediaWikiServices::getInstance()service-locator usage inNetworkConfig.