You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit eb2ceda
Browse filesBrowse the repository at this point in the historyBrowse files
Fix modal trigger not opening modals on MediaWiki 1.43+
The deferred-content mechanism (ParserOutput::setExtensionData on the
parse side, ParserOutput::getExtensionData in the OutputPageParserOutput
hook) no longer preserves data across the parser hook -> render hook
transition under MediaWiki 1.43's ParserOutputAccess lifecycle changes.
The set-side and get-side operate on different ParserOutput instances,
so the modal container markup never reaches the page. The modal trigger
still renders but has nothing to open.
Switch to inline emission: ModalBuilder::parse() returns the trigger
HTML and the modal container HTML concatenated. The modal container is
position: fixed and addressed via data-target="#id", so its DOM
placement is no longer significant. This works identically on every
supported MediaWiki version because the underlying Bootstrap behaviour
is the same and RemexHtml (default since MW 1.36) cleanly handles a
block element inside a wikitext paragraph.
Removes the now-unused ParserOutputHelper::injectLater() helper and
the EXTENSION_DATA_DEFERRED_CONTENT_KEY constant. Updates the four
parallel test files (ModalBuilderTest, ImageModalTest, ModalTest,
OutputPageParserOutputTest) to assert the new concatenated return
shape and drop the deferred-content mock expectations.
Verified on a MW 1.39 + Vector + BC stack: modal opens identically
pre- and post-patch (no regression on the oldest supported MW
version). PHPUnit unit suite stays green relative to baseline; the
6 pre-existing ImageModalTriggerTest failures are present in both
runs and unrelated to this change.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
0 commit comments