Extension talk:FlaggedRevs

About this board

Archives (talkcontribs)

Hi there! how can I change the buttons and inputs styles on the local wiki?

Reply to "UI improving"

Is there a script that allows mass flagging?

Krzysiek 123456789 (talkcontribs)

Is there a script that allows mass flagging?

Osnard (talkcontribs)
Krzysiek 123456789 (talkcontribs)

Ok, thanks.

Reply to "Is there a script that allows mass flagging?"

How to make stable version by default ?

5 (talkcontribs) (talkcontribs)

actually it should be enough to simply set

 $wgDefaultUserOptions['flaggedrevsstable'] = false; 

to true; found in \extensions\FlaggedRevs\FlaggedRevs.php

The bad thing about this solution is, that the users could change this behaviour in their preferences.

Dadai12 (talkcontribs)

In case someone runs into the same problem with MW 1.20 or 1.21.

I set the default user options like described above:

$wgDefaultUserOptions['flaggedrevsstable'] = true; 

It worked, but I got an error when I tried to access the preferences with some users (they had the default settings for FlaggedRevs):

Fatal exception of type MWException 

My solution was to set the default options to this:

$wgDefaultUserOptions['flaggedrevsstable'] = 1;

Maybe there was a change since the above solution was written. Hope this helps. :-)

Jiou7 (talkcontribs)

Eight years later, this helps as I have the same "Fatal exception of type MWException" with MW 1.36.0 and replacing "true" by "1" works!

Is there any explanation or better solution since then? (talkcontribs)

Apologize if I am reviving the old question but want to check if there is a better way than changing the default user option for this question...

Reply to "How to make stable version by default ?"

Is time delayed autoacceptance possible

Vis M (talkcontribs)

Is it possible to optionally add an expiry time for PendingChanges tags. The purpose is to add a time delay before newbie edits go live and a vandalism patroller can immediately approve or reject that edit.

This time delay will help Vandalism patrollers and watchlisters to accept or revert newbie edits before they become live. It is intended for all edits in a wiki. Unreviewed edits can go live after the delay time (eg 2 hours), so that there will not be any backlog or a conflict with "editable by anyone" policy. It will facilitate a better alternative to en:WP:Delayed revisions

Ciencia Al Poder (talkcontribs)

I guess the reviewAllPages.php maintenance script could be modified to add an option to only review changes older than X time. Then you can add this script as a cron job every day.

Vis M (talkcontribs)

I am actually asking for a time based autoacceptance

Vis M (talkcontribs)
MGChecker (talkcontribs)

Ciencias proposal would be time based autoacceptence. An implementation via bot would be an easy alternative.

Vis M (talkcontribs)
Reply to "Is time delayed autoacceptance possible" (talkcontribs)

I am on MW version 1.34 and a, trying to use the 1.31 version of FlaggedRevs. When trying to run the update.php maintenance script I am getting the following error:

PHP Fatal error:  Uncaught Exception: Unable to open file /opt/bitnami/apps/mediawiki/htdocs/extensions/FlaggedRevs/extension.json: filemtime(): stat failed for /opt/bitnami/apps/mediawiki/htdocs/extensions/FlaggedRevs/extension.json in /opt/bitnami/apps/mediawiki/htdocs/includes/registration/ExtensionRegistry.php:136

Stack trace:

#0 /opt/bitnami/apps/mediawiki/htdocs/includes/GlobalFunctions.php(52): ExtensionRegistry->queue('/opt/bitnami/ap...')

#1 /opt/bitnami/apps/mediawiki/htdocs/LocalSettings.php(440): wfLoadExtension('FlaggedRevs')

#2 /opt/bitnami/apps/mediawiki/htdocs/includes/Setup.php(124): require_once('/opt/bitnami/ap...')

#3 /opt/bitnami/apps/mediawiki/htdocs/maintenance/doMaintenance.php(83): require_once('/opt/bitnami/ap...')

#4 /opt/bitnami/apps/mediawiki/htdocs/maintenance/update.php(277): require_once('/opt/bitnami/ap...')

#5 {main}

  thrown in /opt/bitnami/apps/mediawiki/htdocs/includes/registration/ExtensionRegistry.php on line 136

Does anyone know why I am getting this error?

Thank you

Ciencia Al Poder (talkcontribs)

Perhaps the file /opt/bitnami/apps/mediawiki/htdocs/extensions/FlaggedRevs/extension.json does not exist, or the server doesn't have read permissions to open that file

Tacsipacsi (talkcontribs)

You should use

require_once "$IP/extensions/FlaggedRevs/FlaggedRevs.php";

and not


as the extension documentation instructs you to do. (talkcontribs)

That worked, thank you! (talkcontribs)

Okay one more question, I am getting the following error:

[dd7f92a2ded44d8eb30257a8] /Main_Page Error from line 58 of /opt/bitnami/apps/mediawiki/htdocs/extensions/FlaggedRevs/backend/FRUserActivity.php: Call to undefined method ObjectCache::getMainStashInstance()

From what I can find this may be due to mismatched versions, but I am using the most recent version that I am able from the extension page's download options. Any suggestions on this?

Tacsipacsi (talkcontribs)

Indeed, this method was removed in MediaWiki 1.34, so the FlaggedRevs version for MediaWiki 1.31 could use it with no problem, but it fails on your MW 1.34. You can download FlaggedRevs version for MW 1.34 from GitHub, but I strongly suggest that you update to MediaWiki 1.35 LTS (and FlaggedRevs for MW 1.35), since MediaWiki 1.34 isn’t supported since November 2020. (By the way, this may be the reason why FlaggedRevs for MW 1.34 cannot be downloaded with ExtensionDistributor, while FlaggedRevs for MW 1.35 is available there.) (talkcontribs)

Unfortunately the 1.34 branch is not compatible with Mediawiki 1.34 (not sure why) so it looks like my only option is upgrade MW or not use it.

Reply to "Unable to open file"
Mohanad Kh (talkcontribs)

Hi, is there any variables for FlaggedRevs ext. that could be retrieved by mw.config object?

Amorymeltzer (talkcontribs)
Mohanad Kh (talkcontribs)
Reply to "variables for mw.config"
Luk3 (talkcontribs)

Does FlaggedRevs works with Wikibase and its Items and Properties?

Reply to "Compatibility with Wikibase"

Approved changes to a template or page that appears in other pages

Dovi (talkcontribs)

We have "Flagged Reviews" (Pending Changes) installed at Hebrew Wikisource.

One difficulty with the current installation is this: When a change is made within a template (or in a page that is used within other pages), all of the pages that use it (sometimes hundreds or thousands of them) show a notice at the top about changes in the template that need to be approved in order to rate the current version of the page. This happens even if the page itself has not been changed and the newer version of the template was already approved!

Is there currently a way to configure the extension so that if changes are made to a template/page that appears within other pages are approved, then the pages that use it will simply remain at their current level of approval?

Reply to "Approved changes to a template or page that appears in other pages"
Silkwood (talkcontribs)

MediaWiki1.34.0 (ae6e0c0)

Flagged Revision – (784dad


can someone explain to me what does this mean?

Undefined index: excludeLastDays in /var/www/w/extensions/FlaggedRevs/FlaggedRevsSetup.php on line 78

It appears every time I run the update maintenance script (and other related stuff).


Ciencia Al Poder (talkcontribs)

Looks like $wgFlaggedRevsAutopromote doesn't contain the 'excludeLastDays' key.

If you've defined $wgFlaggedRevsAutopromote in LocalSettings.php be sure you define it correctly and without clearing the entire array

Silkwood (talkcontribs)


for the benefit of complete and detailed information, the warnings were all these:

PHP Notice:  Undefined index: excludeLastDays in /var/www/w/extensions/FlaggedRevs/FlaggedRevsSetup.php on line 78

PHP Notice:  Undefined index: excludeLastDays in /var/www/w/extensions/FlaggedRevs/FlaggedRevsSetup.php on line 93

PHP Notice:  Undefined index: totalCheckedEdits in /var/www/w/extensions/FlaggedRevs/FlaggedRevsSetup.php on line 97

PHP Notice:  Undefined index: excludeLastDays in /var/www/w/extensions/FlaggedRevs/FlaggedRevsSetup.php on line 98

PHP Notice:  Undefined index: maxRevertedEditRatio in /var/www/w/extensions/FlaggedRevs/FlaggedRevsSetup.php on line 101

PHP Notice:  Undefined index: neverBlocked in /var/www/w/extensions/FlaggedRevs/FlaggedRevsSetup.php on line 104

but thanks to your clue, I found out that in /var/www/w/extensions/FlaggedRevs/ there is beautiful README file that reads like this:

In 1.34 the autopromote config was removed from the default. If you want to keep the same config

add the following to your LocalSettings.php

<source lang="php">

$wgFlaggedRevsAutopromote = [

        'days'                  => 60, # days since registration

        'edits'                 => 250, # total edit count

        'excludeLastDays'       => 1, # exclude the last X days of edits from below edit counts

        'benchmarks'            => 15, # number of "spread out" edits

        'spacing'               => 3, # number of days between these edits (the "spread")

        'totalContentEdits'     => 300, # edits to pages in $wgContentNamespaces

        'totalCheckedEdits'     => 200, # edits before the stable version of pages

        'uniqueContentPages'    => 14, # unique pages in $wgContentNamespaces edited

        'editComments'          => 50, # number of manual edit summaries used

        'userpageBytes'         => 0, # size of userpage (use 0 to not require a userpage)

        'neverBlocked'          => true, # username was never blocked before?

        'maxRevertedEditRatio'  => 0.03, # max fraction of edits reverted via "rollback"/"undo"



I did changed my LocalSettings.php and now everything is fine with FR.

Perhaps the installation/configuration instructions deserve some attention and some updates.

Thank you so much @Ciencia Al Poder

Ciencia Al Poder (talkcontribs)

I find funny to see a README file with wiki syntax (that can't be rendered nicely in any text editor btw) but then devs fail to update that documentation on the wiki page... Maybe @Reedy can check if the instructions are correct, since it seems he was the author of those changes in the README

Reply to "What does it mean?"

Remove tags from $wgFlaggedRevsTags

Zagy (talkcontribs)


it used to be possible to set $wgFlaggedRevsTags to some value and that would be used for the tags. Since some release arrays defined in LocalSettings are merged with the array defined in extension.json and there seems to be no way to remove a value anymore.

FlaggedRevs itself does even support an empty $wgFlaggedRevsTags, but there seems no way to set this anymore.

Any hints?

Reply to "Remove tags from $wgFlaggedRevsTags"
Return to "FlaggedRevs" page.