Subject | Repo | Branch | Lines +/- | |
---|---|---|---|---|
Use WatchedItemStore for SP:RC watchers count | mediawiki/core | master | +2 -8 |
Details
Status | Subtype | Assigned | Task | ||
---|---|---|---|---|---|
Resolved | ifried | T8964 Watch pages for a few days only (add an expiry time) | |||
Resolved | MusikAnimal | T100508 Watchlist expiry: Watch pages for a specified time frame (2013) | |||
Open | None | T129478 Refactor watchlist related code to use WatchedItemStore | |||
Open | None | T132568 [Task] Refactor Special:Recentchanges to use WatchedItemStore |
Event Timeline
Mainly this bit of code which could probably be swapped out for something in WatchedItemStore straight away
$dbr->selectField( 'watchlist', 'COUNT(*)', [ 'wl_namespace' => $obj->rc_namespace, 'wl_title' => $obj->rc_title, ], __METHOD__ . '-watchers' );
Change 283385 had a related patch set uploaded (by Addshore):
Use WatchedItemStore for SP:RC watchers countm
So there is some stuff in there which selects with joins on the RC table.
I still don't know what the best approach there is and it may be worth leaving it
@Addshore I have not looked closely, but my intuition is this: Don't move the compelx queries into WatchedItemStore, but into a separate class, WatchedItemQuery or some such. Also split out the UI bit into RCView or ChagnesView or something. The special page should then just glue the view to the query service, and handle parameters. Not sure whether the form should be defiend by the view or the special page itself though.
Other than the RC watchlist crossover stuff mentioned above this is all done so moving to done.
The RC / watchlist stuff should likely be done seperatly.
T130067 is resolved hence this task is not stalled anymore. (And mediawiki/core/includes/specials/SpecialRecentChanges.php nowadays has the line MediaWikiServices::getInstance()->getWatchedItemStore()->countWatchers().)