Extension talk:FlaggedRevs

About this board


Two identical user groups in Georgian Wikipedia

გიო ოქრო (talkcontribs)

Hello. In Georgian Wikipedia, for reasons unknown to me, there are two identical user groups for auto checking of edit. Please see special page in English, where you can see Autochecked users და Trusted users. What should we do first?

Ciencia Al Poder (talkcontribs)

That's something that should be reported at phabricator for investigation and fix, since that's a configuration issue.

Reply to "Two identical user groups in Georgian Wikipedia"

$wgFlaggedRevsWhitelist removed?

2 (talkcontribs)

Hi, I am upgrading from a very old version. I've been using $wgFlaggedRevsWhitelist to exclude some pages from the revisions system. After the update these pages have the revision information on them again. Looks like $wgFlaggedRevsWhitelist option has been removed. Is there any way to exclude specific pages from the revisions, or at least hide the revision bar on them?

Tacsipacsi (talkcontribs)

It was indeed removed in 0fe4ed9a6842b04324d7525447f2c80855c5dd74. There is no direct replacement, although you can configure these pages on Special:Stabilization so that their latest revision appears even if it’s not yet reviewed—this still makes the UI elements (review form, revision tag etc.) appear, but the content itself is always the latest. (Or you can switch to the protection-based system, but then you need to configure all pages that you do want to be reviewable, which is probably not feasible if you had just a few exempted pages.) You could also hide the UI elements using CSS, but that’s quite hackish and will probably break somewhere or at some time.

Reply to "$wgFlaggedRevsWhitelist removed?"

FlaggedRevs & PostgreSQL 10

Summary by Pglind

A code change resolved the issue.

Pglind (talkcontribs)

Hi team,

We are using MediaWiki 1.37.1 on PostgreSQL 10 with FlaggedRevs (tested branch REL1_37 & wmf/1.37.0-wmf.9).

Unfortunately when adding a new Wiki page we receive an error:

[22c5ffc28c0120bd38673b6d] /index.php?title=Testpagina&action=submit Wikimedia\Rdbms\DBQueryError: A database query error has occurred. Did you forget to run your application's database schema updater after upgrading or after adding a new extension?

Please see link and link for more information.

Error 22007: ERROR: invalid input syntax for type timestamp with time zone: "" LINE 1: ... WHERE fr_page_id = 268 AND (fr_rev_timestamp > ) AND (r... ^

Function: FlaggableWikiPage::updatePendingList

Query: SELECT fr_rev_id,rev_timestamp FROM "flaggedrevs","revision" WHERE fr_page_id = 268 AND (fr_rev_timestamp > ) AND (rev_id = fr_rev_id) AND (rev_page = fr_page_id) AND ((rev_deleted & 1) = 0) ORDER BY fr_rev_timestamp DESC LIMIT 1

Trying the query myself in PG, I receive the same error, however after more investigation, this is the issue:

AND (fr_rev_timestamp > '')

I have tried to run the php maintenance/update.php multiple times, but always succeeds without issues and no changes.

I also couldn't find a mention anywhere on the Extensions page that PostgreSQL isn't supported.

What can I do to resolve this?

Thank you

Tacsipacsi (talkcontribs)

I don’t know whether Postgres is officially supported (the whole extension as such is rather unsupported, though), however this seems to be a bug not directly related to PostgreSQL: comparing a timestamp with the empty string simply doesn’t make any sense; I wonder why MariaDB doesn’t cry about this. It was set to the empty string by Ladsgroup in phab:rEFLR04ffb5f56f2331138f2463584aacbb702e8d243e, maybe they can tell whether that filter is still needed and if yes, how to fix it in Postgres.

Ladsgroup (talkcontribs)

Sorry for this error. Let us see how this can be fixed.

Ladsgroup (talkcontribs)
Pglind (talkcontribs)

Thank you for looking into this!

Removing the line from the file as seen in the commit fixes the issue :)

Another PostgreSQL issue - maintenance/updateStats.php

Pglind (talkcontribs)

Hi team,

Just found another clash with PostgreSQL 10 while running php maintenance/updateStats.php on REL1_37 branch:

SELECT  AVG( 1646323491 - UNIX_TIMESTAMP(fp_pending_since) )  

FROM "flaggedpages","page"    

WHERE (fp_pending_since IS NOT NULL)

AND (fp_page_id = page_id)

AND page_namespace IN (0,6,10)  


Fails with error: Error 42883: ERROR:  function unix_timestamp(timestamp with time zone) does not exist

Thank you for checking!

Pglind (talkcontribs)

I've now added these to functions to PG 10 in order to resolve the error.













However now receive a new error:

Wikimedia\Rdbms\DBQueryError from line 1809 of /mediawiki/includes/libs/rdbms/database/Database.php: Error 23502: ERROR:  null value in column "frs_stat_val" violates not-null constraint

DETAIL:  Failing row contains (2022-03-04 09:48:17+00, reviewLag-anon-sampleStartTimestamp, null).

Function: FlaggedRevsStats::updateCache

Query: INSERT INTO "flaggedrevs_statistics" (frs_stat_key,frs_stat_val,frs_timestamp) VALUES ('reviewLag-anon-sampleStartTimestamp',NULL,'2022-03-04 09:48:17+00'),('reviewLag-user-sampleStartTimestamp',NULL,'2022-03-04 09:48:17+00'),('reviewLag-anon-sampleEndTimestamp',NULL,'2022-03-04 09:48:17+00'),('reviewLag-user-sampleEndTimestamp',NULL,'2022-03-04 09:48:17+00'),('reviewLag-anon-sampleSize',0,'2022-03-04 09:48:17+00'),('reviewLag-user-sampleSize',0,'2022-03-04 09:48:17+00'),('reviewLag-anon-average',0,'2022-03-04 09:48:17+00'),('reviewLag-user-average',0,'2022-03-04 09:48:17+00'),('reviewLag-anon-median',0,'2022-03-04 09:48:17+00'),('reviewLag-user-median',0,'2022-03-04 09:48:17+00'),('pendingLag-average',0,'2022-03-04 09:48:17+00'),('totalPages-NS:0',2,'2022-03-04 09:48:17+00'),('reviewedPages-NS:0',1,'2022-03-04 09:48:17+00'),('syncedPages-NS:0',1,'2022-03-04 09:48:17+00'),('totalPages-NS:6',0,'2022-03-04 09:48:17+00'),('reviewedPages-NS:6',0,'2022-03-04 09:48:17+00'),('syncedPages-NS:6',0,'2022-03-04 09:48:17+00'),('totalPages-NS:10',0,'2022-03-04 09:48:17+00'),('reviewedPages-NS:10',0,'2022-03-04 09:48:17+00'),('syncedPages-NS:10',0,'2022-03-04 09:48:17+00') ON CONFLICT DO NOTHING

Reply to "Another PostgreSQL issue - maintenance/updateStats.php"
2A01:261:D5B:1B00:392D:D612:2CD:2609 (talkcontribs)

After updating the mediawiki version from 1.15 to 1.35 I have a problem. All pages are marked as requiring approval. Changes are shown in the page history, but the page is not validated. Any idea what to do?

Reply to "Problems after the update."
Summary by Krzysiek 123456789

i answered questions (talkcontribs)

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

Krzysiek 123456789 (talkcontribs)

Yes, using CSS

Vikipolimer (talkcontribs)

Hi @Krzysiek 123456789 I know, but where is the MediaWiki official CSS files? can you show me?

Krzysiek 123456789 (talkcontribs)

You can simply override them with CSS for a single user or a global CSS file for a wiki(MediaWiki:Common.css). For security reasons it is not possible to modify the default styles directly. HERE you can learn more.

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"
Return to "FlaggedRevs" page.