Page MenuHomePhabricator

Expose $wgFlaggedRevsNamespaces to JS
Open, Needs TriagePublic

Description

$wgFlaggedRevsNamespaces sets the namespaces in which flagged revisions is enabled, but it doesn't seem that info is exposed to the user like $wgFlaggedRevsTags (via the tags object in wgFlaggedRevsParams). It'd be helpful to have the namespaces as well, and wgFlaggedRevsParams seems already set up for it.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMar 16 2019, 1:45 PM

Just noting that empty wgFlaggedRevsParams are no longer exported as of https://gerrit.wikimedia.org/r/c/mediawiki/extensions/FlaggedRevs/+/508427 (T219342#5116724)

Krinkle added a subscriber: Krinkle.EditedJun 17 2019, 7:39 PM

Can you describe the use case for which you'd like to use this?

Does it need to be for the whole wiki, or just the namespace the currently viewed page is in?

In any event, I'd recommend exposing this via the Siteinfo API, which JS can query.

Can you describe the use case for which you'd like to use this?

It'd be helpful for scripts and the like who wish to be able to offer the flaggedrevs options only when appropriate. In my particular case, this came up when trying to hide pending changes dropdowns in Twinkle for enWiki. They can of course be hardcoded, but that's not very portable across wikis.

Does it need to be for the whole wiki, or just the namespace the currently viewed page is in?

Ideally it'd be discoverable anywhere, as I can imagine someone else wanting the ability to bulk-protect pages in a list, and while those pages may flaggedrevs-able, the list may not be (a userspace list of articles, for example).

In any event, I'd recommend exposing this via the Siteinfo API, which JS can query.

Going off the above, using wgFlaggedRevsParams certainly made more sense (to me, anyway) when it was still being exported everywhere. As it no longer is, waiting for one extra query wouldn't be so bad, and it would admittedly fit in well with the other siprops.