Last modified: 2011-05-09 23:29:06 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T30887, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 28887 - Special:Recentchangeslinked: doesn't work with more than one category on the same page.
Special:Recentchangeslinked: doesn't work with more than one category on the ...
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Recent changes (Other open bugs)
1.17.x
All All
: High normal (vote)
: ---
Assigned To: Bawolff (Brian Wolff)
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-05-08 19:43 UTC by Johan
Modified: 2011-05-09 23:29 UTC (History)
2 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Johan 2011-05-08 19:43:58 UTC
See:
http://en.wikipedia.org/wiki/User:Julle/Bug

{{Special:Recentchangeslinked/Category:Science fiction}}
{{Special:Recentchangeslinked/Category:Swedish writers}}
{{Special:Recentchangeslinked/Category:Bridges}}

doesn't list changes in Category:Science fiction, Category:Swedish writers, Category:Bridges, it repeats the listing of changes in the first category.
Comment 1 Bawolff (Brian Wolff) 2011-05-09 05:33:15 UTC
Can confirm the issue is still present on trunk, and it also seems to work with Special:recentchanges:

{{Special:Recentchanges/5}}
-----
{{Special:Recentchanges/1}}

will display 5 entries both time.

However, the issue does not seem to be present with {{special:prefixindex}}
Comment 2 Bawolff (Brian Wolff) 2011-05-09 06:15:09 UTC
Caused because both Special:Recentchange and Special:Recentchangeslinked both store configuration in a member property of the special page objects.

In SpecialPageFactory::getPage there is a line:
 self::getList()->$realName = new $className;
Which causes the special page objects to be re-used if a special page is called multiple times in one request. Thus the same config is kept for both transclusions.

Possible fixes is to not re-use special page objects when they are being transclude, or to make sure the special pages clears the options property in the execute method each time its run.
Comment 3 Bawolff (Brian Wolff) 2011-05-09 06:50:32 UTC
(note as an aside, this is a regression in 1.16 and is not present in 1.15)
Comment 4 Brion Vibber 2011-05-09 21:43:38 UTC
It looks pretty wrong to return the same object for multiple calls here; this might be some old remnant of when the special page objects were just entries for the lookup list and the actual code was handled by a separate function. (A few of them might still do that, but many/most? have been moved to the newer extended class style where the object actually does the work.)
Comment 5 Bawolff (Brian Wolff) 2011-05-09 23:29:06 UTC
Changed the behaviour in r87781. This shouldn't affect the old style special pages (Although i don't think we have any left)

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links