Page MenuHomePhabricator

Limit Flagged Revisions to the article, Cookbook, and Wikijunior namespaces on English Wikibooks
Closed, ResolvedPublic

Description

Per consensus at the reading room.

Related Objects

Event Timeline

A_smart_kitten triaged this task as Medium priority.

Change #1201051 had a related patch set uploaded (by A smart kitten; author: A smart kitten):

[operations/mediawiki-config@master] enwikibooks: Limit FlaggedRevs to the main, Cookbook & Wikijunior namespaces

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

I'm gonna ask for some help here from folks who know (more than me) about FlaggedRevs, if that's okay...

On my local dev/testing wiki, when I:
[a] Started with $wgFlaggedRevsNamespaces set to [ NS_MAIN, NS_TEMPLATE ]
[b] Created a new template, and transcluded it from a page in the main namespace (both while using an account with the autoreview right)
[c] Made an edit to that template (while logged-out / using an account without the autoreview right); and
[d] Changed $wgFlaggedRevsNamespaces to [ NS_MAIN ] (ie., removed NS_TEMPLATE)
...the page in the main namespace still displayed the "template changes pending review" message, even though Template: is no longer a reviewable namespace.

screenshot.png (306×635 px, 20 KB)

So I guess my question is: is there a way of removing namespaces from $wgFlaggedRevsNamespaces, without causing this banner to be irremovably displayed on pages that transclude previously-pending-review templates/pages in a removed namespace? (Am I missing something obvious? :D)


Trying to look for related tasks, what's described in T189224: FlaggedRevs bar for a template shown in all articles though there are no template versions to review seems similar, and (if I'm reading things correctly) occurred after arwiki's $wgFlaggedRevsNamespaces was limited to NS_MAIN.

T226054: FlaggedRevs disabled for NS "Wikisource", "MediaWiki" and "File" but it still requiring reviews for transcludes also seems potentially similar, but I'm not entirely sure. In any event, it looks like that was eventually solved by setting $wgFlaggedRevsHandleIncludes to 0 for ruwikisource.

Pppery changed the task status from Open to In Progress.Nov 7 2025, 4:24 PM
Pppery moved this task from Working on to Blocked on development on the Wikimedia-Site-requests board.
A_smart_kitten changed the task status from In Progress to Stalled.Nov 13 2025, 1:17 PM

Hey @JJPMaster et al — so I guess that the current status is this:

  • I'm not sure if it's currently possible to remove the Template namespace (or any other namespace that has any of its pages transcluded) from a wiki's FlaggedRevs config, without banners similar to F69801009 then being irremovably present on pages that - at the time of the namespace being removed - transcluded a page that had once been reviewed, & hadn't yet had its most recent version reviewed.
  • Possibly there might be a way to work around (and/or fix) this, but I would personally need input from people that know more about FlaggedRevs than me in order to know whether or not that's a possibility. ….and FlaggedRevs is currently without an official code steward (T185664), so there isn't a guarantee that there'd necessarily be someone who'd be able to help with this.
  • An alternative option would be to also set $wgFlaggedRevsHandleIncludes to 0 — which would, if I understand correctly, stop FlaggedRevs from checking whether the latest version of any transcluded page has been reviewed or not. It seems like that might work (both based on a small amount of local testing I've done, and based on the previous case I found in T226054#7525568); however, this would require the English Wikibooks community to have a consensus that this is definitely what it wants to do, given that it would be a wider change than just the originally proposed one to the namespace configuration.

Let me know if you/anyone has any questions about anything I've said. I'm gonna set this to stalled for the moment, as — pending knowledge of a way to fix/work around the issue I mentioned, or enwikibooks coming to a consensus to also set $wgFlaggedRevsHandleIncludes to 0 (or another option coming to light that I'm not currently aware of) — I unfortunately don't know if this task is currently actionable.

(I'm moving it back to the 'Working on' column, as in my mind I am currently working on processing this task.)

Is there a Gerrit link for Wikimedia project namespaces?

Is there a Gerrit link for Wikimedia project namespaces?

Are you asking for a link to the config file that sets all the namespaces? That is https://gerrit.wikimedia.org/r/plugins/gitiles/operations/mediawiki-config/+/refs/heads/master/wmf-config/core-Namespaces.php

Is there a Gerrit link for Wikimedia project namespaces?

Are you asking for a link to the config file that sets all the namespaces? That is https://gerrit.wikimedia.org/r/plugins/gitiles/operations/mediawiki-config/+/refs/heads/master/wmf-config/core-Namespaces.php

Yes, but I was trying to see if English Wikibooks might has NS_COOKBOOK or NS_WIKIJUNIOR, but I guess they do not. That leaves having to use NS_MAIN, 102, 110 but at the moment it's not feasible…

Yes, but I was trying to see if English Wikibooks might has NS_COOKBOOK or NS_WIKIJUNIOR, but I guess they do not. That leaves having to use NS_MAIN, 102, 110 but at the moment it's not feasible…

Maybe I'm missing something (please tell me if I am!), but I'm not sure how having the constants NS_COOKBOOK/NS_WIKIJUNIOR defined would help with things here, unfortunately (given that I assume they'd just be set to 102 & 110).
As far as I can tell, the easiest way to get things moving on this request (from a purely technical perspective) would be if the English Wikibooks community was happy for FlaggedRevs to also stop checking whether there's a stable/reviewed version of any transcluded templates/pages (ie., setting $wgFlaggedRevsHandleIncludes = 0). However, that's ultimately a decision for the community; and (as the person handling this request) I wouldn't want to unduly sway that decision in any direction.

As far as I can tell, the easiest way to get things moving on this request (from a purely technical perspective) would be if the English Wikibooks community was happy for FlaggedRevs to also stop checking whether there's a stable/reviewed version of any transcluded templates/pages (ie., setting $wgFlaggedRevsHandleIncludes = 0). However, that's ultimately a decision for the community; and (as the person handling this request) I wouldn't want to unduly sway that decision in any direction.

(cross-referencing to https://en.wikibooks.org/wiki/Wikibooks:Reading_room/Proposals#Modify_$wgFlaggedRevsHandleIncludes?, where a discussion about this is now taking place)

I have a question: is there a way for FlaggedRevs to exclude some certain pages? Three specific pages would be the Main Page, Cookbook:Table of Contents, and Wikijunior.

I have a question: is there a way for FlaggedRevs to exclude some certain pages? Three specific pages would be the Main Page, Cookbook:Table of Contents, and Wikijunior.

I'm not personally aware of one, apologies (but I'm not overly familiar with FlaggedRevs myself). The closest thing that comes to my mind right now is the ability to use FlaggedRevs as a 'page protection' option (like the English Wikipedia does), but to me that sounds like the inverse of what you're describing. Maybe someone else might know.

A_smart_kitten changed the task status from Stalled to In Progress.Dec 1 2025, 10:46 AM
A_smart_kitten changed the status of subtask T410330: Modify $wgFlaggedRevsHandleIncludes for English Wikibooks from Open to In Progress.

Change #1201051 merged by jenkins-bot:

[operations/mediawiki-config@master] enwikibooks: Limit FlaggedRevs to specific namespaces; disable FR stable-transclusion-checking

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

Mentioned in SAL (#wikimedia-operations) [2025-12-08T15:13:25Z] <urbanecm@deploy2002> Started scap sync-world: Backport for [[gerrit:1192528|SVG: do not allow native SVG rendering (T406023)]], [[gerrit:1201051|enwikibooks: Limit FlaggedRevs to specific namespaces; disable FR stable-transclusion-checking (T408110 T410330)]]

Mentioned in SAL (#wikimedia-operations) [2025-12-08T15:15:25Z] <urbanecm@deploy2002> urbanecm, asmartkitten, hartman: Backport for [[gerrit:1192528|SVG: do not allow native SVG rendering (T406023)]], [[gerrit:1201051|enwikibooks: Limit FlaggedRevs to specific namespaces; disable FR stable-transclusion-checking (T408110 T410330)]] synced to the testservers (see https://wikitech.wikimedia.org/wiki/Mwdebug). Changes can now be verified there.

Mentioned in SAL (#wikimedia-operations) [2025-12-08T15:22:14Z] <urbanecm@deploy2002> Finished scap sync-world: Backport for [[gerrit:1192528|SVG: do not allow native SVG rendering (T406023)]], [[gerrit:1201051|enwikibooks: Limit FlaggedRevs to specific namespaces; disable FR stable-transclusion-checking (T408110 T410330)]] (duration: 08m 49s)

A_smart_kitten removed a project: FlaggedRevs.
A_smart_kitten added a subscriber: Ladsgroup.

This should now be done (thx @Ladsgroup for the code-review!). Apologies for the delays :)
A couple of things to bear in mind:

  • As I discovered earlier in this task, FlaggedRevs can be...somewhat unpredictable. So, if anyone notices anything that doesn't seem right on enwikibooks now that this has been deployed, please feel free to leave a comment here. Worst case scenario, if things have gone wrong, we can always revert the config-change and see if there's another way to get this done!
  • Speaking of FlaggedRevs being unpredictable: while the deploy was in progress, I discovered that the counter of pending-changes at Special:PendingChanges hasn't updated following the removal of these namespaces (and so is now slightly higher than it should be). I didn't revert the patch as it seems like a relatively minor issue; but if the community thinks it's worth e.g. reverting these changes due to this issue, please feel free to leave a comment and we can get that done :)
    • (@Ladsgroup are you aware of an easy fix/a maintenance script for this? it seems to read fp_pending_since from flaggedpages, which I'm guessing the config change won't have updated. no worries if not but I thought I'd ask :))

(I filed T411328: Removing namespaces from $wgFlaggedRevsNamespaces can cause irremovable banners to be displayed on pages that transclude a 'previously-pending-review' page in a removed namespace for the bug I described in T408110#11336607, so that there's still a task open for it now that this site-request is resolved.)

the counter of pending-changes at Special:PendingChanges hasn't updated following the removal of these namespaces

Your patch added a FlaggedRevs namespace. Yet you say some things were removed. I must be missing something. Feel free to elaborate.

Note to self: enwikibooks uses $wgFlaggedRevsOverride = false; $wgFlaggedRevsProtection = false;, so is being used in the style "requires no pages to go through review before displaying that revision to a logged out user. is mainly used as a hidden, internal revision checking system."

Your patch added a FlaggedRevs namespace. Yet you say some things were removed. I must be missing something. Feel free to elaborate.

Previously, $wgFlaggedRevsNamespaces on enwikibooks was set to its extension-default value (the main, File: & Template: namespaces), plus the Module: namespace, plus the Cookbook: & Wikijunior: namespaces. Following the patch, the config variable is overridden & set only to the main, Cookbook: & Wikijunior: namespaces; so the File:, Template: & Module: namespaces were effectively removed.

Ah, I see. Thanks for the explanation. I think I understand the bug you're reporting, but I couldn't reproduce it in localhost with the following steps. If you can help me get these steps correct, I'll write a patch for it:

Steps to reproduce

  • Add to LocalSettings.php: $wgExtraNamespaces[200] = 'Test'; $wgFlaggedRevsNamespaces = [NS_MAIN, 200];
  • With a logged out account, create the page "Test:123", which will create a page in namespace 200.
  • Visit Special:PendingChanges. Confirm that you see the pending change. Confirm that the count is 1.
  • Change LocalSettings.php to: $wgExtraNamespaces[200] = 'Test'; $wgFlaggedRevsNamespaces = [NS_MAIN];
  • Visit Special:PendingChanges. Confirm that you do not see the pending change. Confirm that the count is incorrectly still at 1.

Ah, I see. Thanks for the explanation. I think I understand the bug you're reporting, but I couldn't reproduce it in localhost with the following steps. If you can help me get these steps correct, I'll write a patch for it:

Do these steps work for you? (For clarity, I've underlined where they differ from your steps)

  • Add to LocalSettings.php: $wgExtraNamespaces[200] = 'Test'; $wgFlaggedRevsNamespaces = [NS_MAIN, 200];
  • While logged into an account with the autoreview right:
    • create the page "Test:123", which will create a page in namespace 200.
    • create the page "456", which will create a page in the main namespace (NS 0).
  • With a logged out account, make an edit to the pages "Test:123" & "456".
  • Visit Special:PendingChanges. Confirm that you see the pending changes from both pages. Confirm that the count is 2.
  • Change LocalSettings.php to: $wgExtraNamespaces[200] = 'Test'; $wgFlaggedRevsNamespaces = [NS_MAIN];
  • Visit Special:PendingChanges. Confirm that you do not see the pending change in the Test: namespace, and that you only see the (one) pending change in the main namespace. Confirm that the count is incorrectly still at 2 (rather than 1).