When a Special:... page is loaded, MediaWiki::performRequest() will create the corresponding special page object twice. This can cause weird bugs if the constructor does nontrivial work. Introduced in T109724.
Description
Details
Subject | Repo | Branch | Lines +/- | |
---|---|---|---|---|
Don't construct SpecialPages twice | mediawiki/core | master | +15 -10 |
Related Objects
- Mentioned In
- T132545: Multiple special page transclusions all display the same as the first transclusion present
- Mentioned Here
- T132545: Multiple special page transclusions all display the same as the first transclusion present
T109724: A combination of Special:MyPage redirects and pagecounts allows an external site to know the wikipedia login of an user
Event Timeline
Change 281174 had a related patch set uploaded (by Florianschmidtwelzow):
Don't construct SpecialPages twice
Based on T132545, I disagree with "This can cause weird bugs if the constructor does nontrivial work." as caching SpecialPage instances also causes weird bugs, and am in favor of reverting this.
@PleaseStand asks on https://gerrit.wikimedia.org/r/#/c/283326/:
Why are we caching SpecialPage objects? T123995 says that "[creating] the corresponding special page object twice [...] can cause weird bugs if the constructor does nontrivial work." Which special pages are affected? Can they be fixed to work correctly in this case?
Alternatively, can the code in MediaWiki and SpecialPageFactory be refactored to avoid the construction of a separate SpecialPage instance, without resorting to caching in getPage()?
I don't know if any special page is affected at the moment; I worked around the double-creation when I ran into it. IIRC it had to do with registering hooks in the constructor.