Page MenuHomePhabricator

Deprecate and remove calling ChangesList methods without context
Closed, ResolvedPublic

Description

I was skimming through the uses of RequestContext::getMain() in MediaWiki core a bit to identify sites where it can be easily deprecated or removed.
(One could maybe create a parent task for reducing the use of global context? Maybe a project MediaWiki-Context could be a good idea?)

Specifically, ChangesList::flag and ChangesList::showCharacterDifference optionally take a context, yet have a local context available at each callsite in core and extensions, except for RecentChange::getCharacterDifference, which is unused in all of codesearch.
Therefore, this task suggests to deprecate calling these methods without specifying the context, after adjusting all callers.

Event Timeline

Change #1268107 had a related patch set uploaded (by MGChecker; author: MGChecker):

[mediawiki/core@master] Pass context to ChangesList methods if possible

https://gerrit.wikimedia.org/r/1268107

Change #1268111 had a related patch set uploaded (by MGChecker; author: MGChecker):

[mediawiki/extensions/FlaggedRevs@master] Pass context to ChangesList methods

https://gerrit.wikimedia.org/r/1268111

Change #1268112 had a related patch set uploaded (by MGChecker; author: MGChecker):

[mediawiki/extensions/CollabPads@master] Pass context to ChangesList methods

https://gerrit.wikimedia.org/r/1268112

Change #1268113 had a related patch set uploaded (by MGChecker; author: MGChecker):

[mediawiki/extensions/ArticleFeedbackv5@master] Pass context to ChangesList methods

https://gerrit.wikimedia.org/r/1268113

Change #1268109 had a related patch set uploaded (by MGChecker; author: MGChecker):

[mediawiki/extensions/CheckUser@master] Pass context to ChangesList methods

https://gerrit.wikimedia.org/r/1268109

Change #1268110 had a related patch set uploaded (by MGChecker; author: MGChecker):

[mediawiki/extensions/ORES@master] Pass context to ChangesList methods

https://gerrit.wikimedia.org/r/1268110

Change #1268108 had a related patch set uploaded (by MGChecker; author: MGChecker):

[mediawiki/extensions/Flow@master] Pass context to ChangesList methods

https://gerrit.wikimedia.org/r/1268108

Change #1268111 merged by jenkins-bot:

[mediawiki/extensions/FlaggedRevs@master] Pass context to ChangesList methods

https://gerrit.wikimedia.org/r/1268111

Change #1268112 merged by jenkins-bot:

[mediawiki/extensions/CollabPads@master] Pass context to ChangesList methods

https://gerrit.wikimedia.org/r/1268112

Change #1268110 merged by jenkins-bot:

[mediawiki/extensions/ORES@master] Pass context to ChangesList methods

https://gerrit.wikimedia.org/r/1268110

Change #1268109 merged by jenkins-bot:

[mediawiki/extensions/CheckUser@master] Pass context to ChangesList methods

https://gerrit.wikimedia.org/r/1268109

Change #1268113 merged by jenkins-bot:

[mediawiki/extensions/ArticleFeedbackv5@master] Pass context to ChangesList methods

https://gerrit.wikimedia.org/r/1268113

Change #1268108 merged by jenkins-bot:

[mediawiki/extensions/Flow@master] Pass context to ChangesList methods

https://gerrit.wikimedia.org/r/1268108

I have realized that ChangesList::userCan is a similar case: It optionally takes a performer, falling back to RequestContext, but is never called without one. So I added the deprecation to the change. Once these fallbacks are removed, ChangesList no longer depends on RequestContext.

Change #1268303 had a related patch set uploaded (by MGChecker; author: MGChecker):

[mediawiki/extensions/AbuseFilter@master] Specify performer for ChangesList::userCan

https://gerrit.wikimedia.org/r/1268303

Change #1268303 merged by jenkins-bot:

[mediawiki/extensions/AbuseFilter@master] Specify performer for ChangesList::userCan

https://gerrit.wikimedia.org/r/1268303

Change #1268107 merged by jenkins-bot:

[mediawiki/core@master] Pass context to ChangesList methods if possible

https://gerrit.wikimedia.org/r/1268107

Well. technically I wanted to leave this open for the final change after the 1.46 branch cut, dropping the unused stuff I deprecated in the last few weeks. But in the end it does not matter so much.

@Aklapper Do you think creating a project #MediaWiki-Context would be appropriate, and if so, can I just create it (in this particular case), or would a more extensive discussion be necessary?
The project would be somewhat transitional, as there will be a lot less to talk about once RequestContext is used rarely, but this could well take another decade. I would estimate there to be at least 50 issues (open or closed, and many more in the future) one could associate with such a project.

I’d rather create an Epic task: “don’t use RequestContext::getMain()” is a hopefully closed-ended thing (even if that closed end is far in the future), which is a good fit for a task. I don’t think that extra features of projects, like board columns, would be necessary in this case.

The project would not be limited to that, but also encompass things like

with a project making it significantly easier to keep an eye on this area of code, which do not share any common tag otherwise.
One could complement this with a goal task, but not all IContextSource-related issues are about the removal of RequestContext.

Seems like a reasonable column/subproject of Technical-Debt .