How to use Special:PendingChanges

So on Special:PendingChanges, what do the tags 'checked' and 'quality' next to revisions mean? Are those some sort of review levels? So a revision starts in quality and moves to checked and then stable? --Cneubauer 16:28, 21 April 2011 (UTC)

The latest "checked" is the stable version. A "quality" version is just a better "checked" version. You can get pending changes against the "stable" version, but you can also get pending changes against the "quality" version. Often the latest "checked" is up to date but the latest "quality" one is behind. Aaron 00:56, 10 December 2011 (UTC)

Help with skin

Hello!

By default, the extension use a "small icons and minimal text to show approval status of pages". However, it seems a little bugged with the Vector skin. However, choosing in "preferences" "Use detailed boxes to show approval status of pages", it is not. So, how can I turn as default, the non-bugged option?

Thanks! 201.15.204.79 00:00, 25 May 2011 (UTC)

Use $wgSimpleFlaggedRevsUI. Aaron 00:55, 10 December 2011 (UTC)

chmod o+w extensions/FlaggedRevs/client

I'm pretty sure it's almost always a bad idea to make content served/executed by a webserver world-writable, even when there aren't untrusted local users on the machine... Mdeegan 03:49, 5 July 2011 (UTC)

Not sure who added that bit but someone fixed it it seems. Aaron 00:54, 10 December 2011 (UTC)

How to make stable version by default ?

Hi, I've installed FlaggedRevs trying to build a Quality Management System. I need that users see the stable version by default, and write the following line in my LocalSettings.php:

$wgFlaggedRevsOverride = true;

However, the page ...: http://myserver/mediawiki/index.php?title=mypage

Is the same as ......: http://myserver/mediawiki/index.php?title=mypage&stable=0

I need the stable=1 by default, how can I achieve this ?

Thanks in advance

Alfonso 201.217.152.82 22:01, 9 August 2011 (UTC)

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. 84.253.4.90 11:57, 22 August 2011 (UTC)

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. :-) Dadai12 (talk) 11:49, 12 July 2013 (UTC)

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? Jiou7 (talk) 15:59, 6 July 2021 (UTC)

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... 64.251.40.242 (talk) 18:41, 19 March 2019 (UTC)

Disabling automatic sight

Can I somewhere disable the automatic sight? I don't found the variable or the function. 141.35.213.221 09:22, 15 August 2011 (UTC)

Merging pending contributions?

What happens in a scenario where User A makes a contribution and User B makes a contribution as well as some typo fixes but both users have contributed different data that are both quality submissions that should be accepted? are you forced to only pick one and the other user has to re-apply their changes to the now current/good revision? Tekmosis 14:34, 31 August 2011 (UTC)

They all build on top of each other. So you can accept them all by accepting the lasting one. You can also "accept" each if you want. You are not really accepting diffs but rather whole revisions technically. It just happens to be convenience to review diffs against a known good state. Aaron 00:52, 10 December 2011 (UTC)

Prevent picture page to show also unapproved versions

The extension seems to work for pages and included images, however when I click on the image I look at the list of all the versions I can also see and access the newer versions. Is there any way to prevent this? The point is that in the company's intranet, the unapproved versions of uploads should not be accessible. Thanks for answers! Tschuliaen 09:14, 2 September 2011 (UTC)

Have you seen Extension:FlaggedRevs/Restricting unapproved revisions ? Aaron 00:51, 10 December 2011 (UTC)

Revisions remains the same even if included templates are changed

We are building a CMS around mediawki and we need to have signed logs of page readings, with the ability to freeze a page we can record the revisions number and it will "contain" the revision number of transcluded page

But I cannot find all the information I need

In order to make this "freeze" work there must be a add-on to the database, otherwise how can a page "know" which version of template to call? There might be another way, storing in the database the expanded text and forget about links So I wonder how does it work? levreauj 12:06, 13 September 2011 (UTC)

Here is how I think it is working

There is a table (called "flaggedtemplates") that links a particular flagged edit page with all of it's templates, it links not only with the templates names but the template revision ID. With the "freeze" option of FlaggedRevs nothing will channge in the calling page until the template revision is approved and even then for the update to appear on the calling page it has to be re-approuved. At this re-approval of the calling page the flaggedtemplates table is updated, the version of the calling page remains the same but the field for the template revision ID is updated.

I don't know where the comment for the re-approval goes... Levreauj 20:23, 12 October 2011 (UTC)

Dont know if I understood your question but is that you're asking? "I'm changing the template but anonymous users do not see the recent changes to that template". If so, add the template namespace to Localsettings, e.g:

- $wgFlaggedRevsNamespaces = array( NS_MAIN, NS_FILE, NS_TEMPLATE, NS_PROJECT, NS_CATEGORY, NS_HELP );

And then re-update all the reviews by running /flaggedrevs/maintenance/reviewAllPages.php 4

Where 4 is the user ID of a reviwer (your own, e.g.). Hope it works. I had this situation and this fix worked. Choshi 01:24, 3 January 2012 (UTC)

Comment in history

how can I get a comment in the history? Look here: w:de:Datei:Kommentar-Sichtung.png ianusius ✆ Disk. 20:04, 8 October 2011 (UTC)

That looks like UI clutter to me. Aaron 00:44, 10 December 2011 (UTC)

FlaggedRevs + Semantic MediaWiki issue

We are trying to build a QMS (Quality Management System) using MediaWiki. With FlaggedRevs we build the workflow of document states (In process, Prepared, Revised and Approved). With Semantic MediaWiki's special Search Data page we have an automatic updated index (this is our "All Documents" page).

When we change a page's state, the page disappears from "All Documents". When the page is edited, even if not modified, the page appears again. This is a problem because the people that revise (and approve) the documents should change the state and then edit the document (without change it) to make it available in "All Documents".

With a trace in the database, we determine that the problem is in the "semantic metadata" in the mw_smw_* tables.

Specifically, the problem is the following code during the review (or approval):

680 Query DELETE /* SMW::deleteSemanticData Sgc03 */ FROM `mw_smw_rels2` WHERE s_id = '53' 680 Query DELETE /* SMW::deleteSemanticData Sgc03 */ FROM `mw_smw_atts2` WHERE s_id = '53' 680 Query DELETE /* SMW::deleteSemanticData Sgc03 */ FROM `mw_smw_text2` WHERE s_id = '53' 680 Query DELETE /* SMW::deleteSemanticData Sgc03 */ FROM `mw_smw_spec2` WHERE s_id = '53' 680 Query DELETE /* SMW::deleteSemanticData Sgc03 */ FROM `mw_smw_subs2` WHERE s_id = '53' 680 Query DELETE /* SMW::deleteSemanticData Sgc03 */ FROM `mw_smw_subp2` WHERE s_id = '53' 680 Query DELETE /* SMW::deleteSemanticData Sgc03 */ FROM `mw_smw_inst2` WHERE s_id = '53' 680 Query DELETE /* SMW::deleteSemanticData Sgc03 */ FROM `mw_smw_redi2` WHERE s_title = 'Gestión_de_la_documentación' AND s_namespace = '0' 680 Query SELECT /* SMW::deleteSemanticData Sgc03 */ smw_id FROM `mw_smw_ids` WHERE smw_title = AND smw_namespace = '53' AND smw_iw = ':smw' 680 Query UPDATE /* SMW::deleteSemanticData Sgc03 */ `mw_smw_ids` SET smw_namespace = '0' WHERE smw_title = AND smw_namespace = '53' AND smw_iw = ':smw'

This code is in ./extensions/SemanticMediaWiki/includes/storage/SMW_SQLStore2.php

We try to comment this code in the case of a review (or approval), the semantic metadata is not deleted, and the page dont disappear from "All Documents" (OK). But then, when the page is legitimately re-edited, the semantic metadata is inserted again, and this result in a hang in subsequent edits.

We are looking for a way in which the state changes do not eliminate the document for "All Documents" that also intelligently handle subsequent edits

Any advice is wellcome

Regards, Alfonso 201.217.152.82 13:20, 17 October 2011 (UTC)

Get a list of random reviewed pages with the API ?

Hi everyone !

How come is it not possible to give a parameter 'random' to the API with the list reviewedpages (or any of the flaggedrevs list btw) ? I can't figure how to get a list of random reviewed pages in only one query to the API, it's so frustrating ! Can this feature be considered ?

Thx in advance ! 81.255.33.227 16:14, 10 November 2011 (UTC)

Banner in the print version

Is there a way the banner of FlaggedRevs also included in the print version ? Or you can add such an option? Wniva 11:35, 25 November 2011 (UTC)

It is not currently possible. I don't plan on adding it (If I were I would just make it hidden via CSS by default but leave the HTML). Aaron 21:16, 25 November 2011 (UTC)

I've tried to find a way in CSS to display the banner in printable version, but I'm not found it. Can someone give me a hint where I can adjust to these things? Wniva 14:38, 28 November 2011 (UTC)

You would need to change the source code. There are *->isPrintable() checks it the code that determine whether anything is added or not. Aaron 20:38, 30 November 2011 (UTC)

Enable editor for comments

I want enable that editor can make a comment about his sighting. Unfortunately I get with the parameter $wgFlaggedRevsComments only that the reviewers can enter comments.

Where can I adjust that the editor has the option for comments? 80.243.35.195 14:35, 28 November 2011 (UTC)

I would avoid that feature altogether ("review notes"). It was removed in later versions of the extension. However, in the latest version of the extension, everyone can leave a log comment when they review. Aaron 20:41, 30 November 2011 (UTC)

Basic Settings Misleading

The section 'Basic Settings' states:

$wgFlaggedRevsNamespaces – Sets what namespaces to allow for reviewing. This is an array of integers. Look at the beginning of includes/defines.php to see what integer the default namespaces map to.

However, I after spending quite a while trying to get integers for namespaces to work, I found out the names of the namespaces had to be used. In fact, looking into FlaggedRevs.php, this is what is shown:

# Allowed namespaces of reviewable pages
$wgFlaggedRevsNamespaces = array( NS_MAIN, NS_FILE, NS_TEMPLATE );

The text on the Extension page should be updated! Acaldwell 15:53, 1 December 2011 (UTC)

NS_MAIN is a PHP constant which equals an integer. So the values *are* integers. Using constants just makes it more readable. You could technically do wgFlaggedRevsNamespaces = ( 0, 6, 10 ); Aaron 00:38, 3 December 2011 (UTC)

New pages marked as unreviewed by default?

Is it possible to tweak a setting somewhere to that new pages are not auto-reviwed? At the moment, when any of our users (non-reviewing rights) create a new page, it is marked as a stable version. As an admin I can un-approve the page, but I want to avoid having to do this. Can anyone help? Jemima 10:42, 9 December 2011 (UTC)

What versions of the extensions are you using and what user rights config do you have? The users must be getting 'autoreview' rights from some group they belong to. Aaron 00:42, 10 December 2011 (UTC)

After approved not show images and return broken link to file. Only to unregistered user.

How example:

Before:

http://wiki-moscow.ru/Test111

After:

http://wiki-moscow.ru/Test112

Version:

http://wiki-moscow.ru/%D0%A1%D0%BB%D1%83%D0%B6%D0%B5%D0%B1%D0%BD%D0%B0%D1%8F:Version

or http://wiki-moscow.ru/Special:Version

P.S. I tried to use different versions of the "flaged revision" and received the same thing. MediaWiki 1.18

P.S.2. Not showed images only to unregistered user! Serdtsev 20:09, 11 December 2011 (UTC)

Hmmm.

After approved Not show images from Wikimedia Commons only. Registered users can see them.

But unregistered users can see any images which was saved to the my wiki. Serdtsev 11:08, 13 December 2011 (UTC)

ForeignAPIRepos don't work with FR. It's probably possible to patch FR and FileRepo to handle this better (like always show current versions for foreign API repos). Aaron 03:08, 26 December 2011 (UTC)

Hi Araaon. Thank you for response.

May be possible now any way local modify the FR code that approved only text without any images? Serdtsev 06:53, 13 January 2012 (UTC)

Actually I'd just recommend filing a bug report to MediaWiki to let foreign files be fetched by sha1. Aaron 07:49, 13 January 2012 (UTC)

may be somehow temporarily disable approving images in the code?

I will write in bagzila later, after a set up the MediaWiki engine for testing on my other free domain. Serdtsev 09:36, 13 January 2012 (UTC)

Add 'return true' to the top of the function 'parserFetchStableFile' in the codebase. Aaron 21:01, 13 January 2012 (UTC)

Error for /maintenance/updateStats.php - "Notice: Undefined variable: times" + Misc

Hi Aaron, thanks to you and everyone else who worked on this!

1. I have MW 1.18 with the latest version of Flagged revisions. The file to run for the cronjob, updateStats.php is giving an error. Here's what I ran on the Shell access command prompt, with the output:

php /home/USER/public_html/wiki/extensions/FlaggedRevs/maintenance/updateStats.php
ValidationStatistics           Notice: Undefined variable: times in /home/USER/public_html/wiki/extensions/FlaggedRevs/dataclasses/FlaggedRevsStats.php on line 359
completed in 0.06s

I had some other suggestions or questions:

2. To approve all current pages, I ran "reviewAllPages.php" for the two editors with the highest number of edits and that seemed to empty the "Unreviewed pages" list. Is that the right way to do this?

3. $wgFlaggedRevsLowProfile changes things for visitors. Could there be a variable that can make the visitor or anonymous IP (who is not a reviewer or editor) see nothing different at all from the stable page? That is, if that variable was set as true, they would not see the "eye" icon, or the "pending changes" tab for a page which has not been reviewed and approved yet.

4. When an IP tries to edit, it sees the warning text ('revreview-editnotice' in the i18n file) above the edit box when it tries to edit: "Your changes will be displayed to readers once an authorized user reviews them. (help)". However I noticed that a registered user who is not an editor or reviewer does not see this text. They are shown that notice only after they've made the edit. Is it possible to turn it on for them as well? That way, the pre-edit notice will be shown to everyone whose changes will need to be reviewed.

5. When an IP or a user who is not an editor or reviewer creates a page, that page shows a small "unchecked" box on the right of the page when it is viewed by visitors. Is it possible to have options for:

• Dont show an unreviewed page to visitors and only show them a warning like "this new page is not visible because it has not been reviewed by an authorized user". Is that the solution? -> Extension:FlaggedRevs/Restricting unapproved revisions. I'm afraid that these changes would effect speed or do something else. I hope a build-in option ($wgShowStableVersionOnly) can made where if there's no stable version of a page, the contents are not showed to visitors, and only editors and reviewers would see it. This method can then be applied equally for new and existing pages.

6. For the situation in #5, $wgFlaggedRevsLowProfile should also work for new pages that have not been reviewed yet, like the way it works for unreviewed edits to existing pages. This way visitors will either see small notices (eye icon, "unchecked" box) or a more visible message with a blue background with the complete text "this new page has not been reviewed yet by an authorized user"

I have some coding experience in extensions and can help if needed to do some of the above. thanks. Choshi 01:00, 29 December 2011 (UTC)

PHP warning fixed in r108165. Aaron 19:04, 5 January 2012 (UTC)

2. That works.

3. That doesn't seem like a good GUI design, what about pages with pending changes?

4. I'll look into this...it was probably done to reduce clutter or something.

5. You'll have to use the code on that mw.org subpage if you want this kind of functionality I'm afraid.

6. Similiar to (3), though more reasonable. I'll look into that too. Aaron 06:50, 6 January 2012 (UTC)

Mass Sight

Hello! Is there a way at all to sight all templates at once, either via the website or via some SQL script? I imported a large number of templates and I also had some I had on my wiki before and they're all unreviewed. Is there an easy way to review them all and still use FlaggedRevs on templates with changes after that? (<-- I don't want to disable it in the template namespace) Joe Gazz84 01:32, 8 January 2012 (UTC)

FlaggedRevs has a ReviewAllPages maintenance script. You change the line "'page_namespace' => FlaggedRevs::getReviewNamespaces()," to "'page_namespace' => NS_TEMPLATE," and run it. Aaron 02:21, 10 January 2012 (UTC)

Draw the stable Image on stable pages

Hello,

i want to draw the stable Image: the green snag, on the stable sites, which have no unviewed versions. Is this possible? 141.35.213.221 11:37, 25 January 2012 (UTC)

Try $wgFlaggedRevsLowProfile = false; (though I'm not 100% sure what you want). Aaron 02:04, 15 February 2012 (UTC)

Hello Aaron,

thanks for your posting. I want to see this image on sites without changes. The other two images (red and yellow) are on sites with no sighting or on sites with changes.

Okay I have found what I want. Is it possible to show the green image (proved) on a site without changes? When a site is sighted is there no image.

Edit:

Problem solved. It was the right variable ($wgFlaggedRevsLowProfile = false;) I have edit the variable in the LocalSettings file, but it don´t work. A edit in the FlaggedRevs.php solved my problem. 141.35.213.221 08:39, 5 March 2012 (UTC)

It should be in LocalSettings. Make sure you put the code line *after* the include/require of FlaggedRevs.php. Aaron (talk) 20:38, 6 March 2012 (UTC)

oh i am stupid. thanks. 141.35.213.221 10:54, 8 March 2012 (UTC)

Special:SpecialPages

I'm don't can use Special:SpecialPages after instalation of FlaggedRevs - Special:SpecialPages. This page shows "The website has a programming error.". Other pages as I see works. What is programming error can be. This is for the new site . May by that is compability error Version. For this time I exclude FlaggedRevs. Page Special:SpecialPages after that are work. What I can do. FlaggedRevs in this site is needed. And. FlaggedRevs/maintenance/updateStats.php return "Invalid entry". Please help. Thanks. Vpovilaitis 18:04, 26 January 2012 (UTC)

Look at the PHP error log (often in the apache error log). Aaron 00:12, 31 January 2012 (UTC)

Thanks. I'm found for Special:SpecialPages that was needed more memory. But when I execute FlaggedRevs/maintenance/updateStats.php, I'm receiving "Invalid entry". Vpovilaitis 17:30, 1 February 2012 (UTC)

I'd need to know more about what the error looks like. I don't recognize "Invalid entry". Aaron 02:05, 2 February 2012 (UTC)

I'm comment in file extensions/FlaggedRevs/maintenance/updateStats.inc lines:

/*if ( php_sapi_name() != 'cli' ) {
	print( 'Invalid entry' );
	die( 1 );
}*/

after that. I'm receive:

Content-type: text/html

ValidationStatistics A database error has occurred. Did you forget to run maintenance/update.php after upgrading? See: http://www.mediawiki.org/wiki/Manual:Upgrading#Run_the_update_script

Query: SELECT MIN(rev_timestamp) AS rt,MIN(n.fr_timestamp) AS nft,MAX(p.fr_rev_id) FROM `encrevision` INNER JOIN `encflaggedrevs` `p` FORCE INDEX (PRIMARY) ON ((p.fr_page_id = rev_page) AND (p.fr_rev_id < rev_id) AND (p.fr_timestamp < rev_timestamp)) INNER JOIN `encflaggedrevs` `n` FORCE INDEX (PRIMARY) ON ((n.fr_page_id = rev_page) AND (n.fr_rev_id >= rev_id) AND (n.fr_timestamp >= rev_timestamp)) WHERE rev_user = '0' AND (rev_timestamp BETWEEN '20120126223222' AND '20120207112002') AND ((rev_id % 1) = 0) GROUP BY rev_id

Function: FlaggedRevsStats::getReviewTimesAnons

Error: 1104 The SELECT would examine more than MAX_JOIN_SIZE rows; check your WHERE and use SET SQL_BIG_SELECTS=1 or SET MAX_JOIN_SIZE=# if the SELECT is okay (localhost) Vpovilaitis 12:29, 7 February 2012 (UTC)

Yes. This sql has error. Full scan is needed for this sql. Must be changed index witch must be used in this sql. Vpovilaitis 20:47, 7 February 2012 (UTC)

I'm change extensions/FlaggedRevs/dataclasses/FlaggedRevsStats.php fragment to (change using index PRIMARY to page_rev):

		# For edits that started off pending, how long do they take to get reviewed?
		# Edits started off pending if made when a flagged rev of the page already existed.
		# Get the *first* reviewed rev *after* each edit and get the time difference.
		$res = $dbr->select(
			array( 'revision', 'p' => 'flaggedrevs', 'n' => 'flaggedrevs' ),
			array( 'MIN(rev_timestamp) AS rt', 'MIN(n.fr_timestamp) AS nft', 'MAX(p.fr_rev_id)' ),
			array( 'rev_user' => 0, $timeCondition, "(rev_id % $mod) = 0" ),
			__METHOD__,
			array(
				'GROUP BY' 	=> 'rev_id',
				'USE INDEX' => array( 'p' => 'page_rev', 'n' => 'page_rev' )
				#'USE INDEX' => array( 'p' => 'PRIMARY', 'n' => 'PRIMARY' )
			),
			array(
				'p' => array( 'INNER JOIN', array( // last review INNER
					'p.fr_page_id = rev_page',
					'p.fr_rev_id < rev_id',
					'p.fr_timestamp < rev_timestamp' ) ),
				'n'	=> array( 'INNER JOIN', array( // next review INNER
					'n.fr_page_id = rev_page',
					'n.fr_rev_id >= rev_id',
					'n.fr_timestamp >= rev_timestamp' ) )
			)
		);

Vpovilaitis 07:03, 8 February 2012 (UTC)

The index usage looks fine in /trunk. I've just backported the query changes to 1.18 in r110921. Aaron 08:21, 8 February 2012 (UTC)

PostgreSQL 9.0

I'm trying to install FlaggedRevs in Mediawiki 1.18.1.

At first I got the following error message:

ValidationStatistics Warning: pg_query(): Query failed: ERROR: function unix_timestamp(timestamp with time zone) does not exist

I created the function UNIX_TIMESTAMP(TIMESTAMP WITH TIME ZONE) using

CREATE OR REPLACE FUNCTION UNIX_TIMESTAMP(TIMESTAMP WITH TIME ZONE)
RETURNS BIGINT
LANGUAGE SQL
IMMUTABLE STRICT
AS 'SELECT EXTRACT(EPOCH FROM $1)::bigint;';

from http://www.postgresql.org/docs/7.4/interactive/functions-datetime.html

Running updateStats.php now throws the following error:

ValidationStatistics Warning: pg_query(): Query failed: ERROR: invalid input syntax for type timestamp with time zone: "0"
LINE 1: ... fr_rev_id = fpp_rev_id) AND (fpp_pending_since > '0') ORDE...
                                                             ^ in [path to mediawiki]/includes/db/DatabasePostgres.php on line 253
Query: SELECT fpp_page_id,fpp_rev_id,fpp_pending_since,fr_timestamp FROM "flaggedpage_pending", "flaggedrevs" WHERE fpp_quality = '0' AND (fpp_pending_since > '2012-02-13 07:48:08 DMT') AND ( fr_page_id = fpp_page_id AND fr_rev_id = fpp_rev_id) AND (fpp_pending_since > '0') ORDER BY fpp_pending_since ASC LIMIT 1
Function: FlaggedRevsStats::getReviewTimesAnons
Error: 1 ERROR: invalid input syntax for type timestamp with time zone: "0"

I'm using PostgreSQL 9.0, Mediawiki 1.18.1 from svn (REL1_18) and FlaggedRevs from svn (REL1_18).

Any thoughts? telephono 08:07, 13 February 2012 (UTC)

See http://www.mediawiki.org/wiki/Special:Code/MediaWiki/111448 in /trunk. Aaron 07:05, 14 February 2012 (UTC)

Yep! It works in /trunk Thanks for the tip.

I still have to manually create the unix_timestamp(timestamp with time zone), though. Is this mentioned anywhere in the documentation? I stumbled upon a user comment in the PostgreSQL 7.4 documentation. Otherwise I would've had no clue on how to fix the "function does not exist" error. Or could this be added to the SQL run by update.php? Telephono 08:19, 14 February 2012 (UTC)

Customize levels?

Is it possible to change the number of criteria and/of number of levels? 91.20.4.78 17:33, 28 February 2012 (UTC)

Yes, see the configuration instructions. Jasper Deng (talk) 22:53, 28 February 2012 (UTC)

Hi there. Although the description in the extensions manual is very good, I somehow do not understand what I'm doing wrong. I'm very grateful for any help.

THIS IS WHAT I WANT:

1. I want a 1-dimension and 2-level flagging (only levels "not revised" and "quality").
2. There is only one person in the wiki who shall set flags on "quality".
3. The edits of the person who may set "quality", shall NOT be automatically "quality", i.e. the "quality"-level shall always be put manually.
4. It shall be possible to set an article back to "not reviewed".
5. If a page has pending edits, the stable version shall be shown as default.

THIS IS HOW I SET THE LOCALSETTINGS:

$wgFlaggedRevsStatsAge = true;

$wgFlaggedRevsComments = false;

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

$wgFlaggedRevsTags = array(

'control' => array( 'levels' => 1, 'quality' => 1,'pristine' => 1 ),

);

$wgFlaggedRevsOverride=false;

$wgSimpleFlaggedRevsUI = true;

$wgFlaggedRevsLowProfile = false;

My user grups (I'm the person that may set "quality") are administrator, buerocrat, editor, revisor.

THIS IS WHAT DOES NOT WORK FINE:

1. (regarding req 1, 2 and 3) When I edit a certified article, the edit is pending (correct). If another user edits the article, his edits are pending as well (correct). But if I edit the article after another user has edited, my edits are automatically certified ("quality") (WRONG).
2. (regarding req 4) If I certify an article, I can afterwards undo this certification and the flag goes back to "not reviewed" (correct). But if there were more than one edits of other users, I cannot go back to "not reviewed" (WRONG). The only workaround that I found is deleting the article and restoring it without the last edits. But I guess that's not the best way to operate...
3. (regarding req 5) I tried to put in true and in false $wgFlaggedRevsOverride, but the Wiki always shows the pending version as default.

Very much in advance for your help, greetings from Chile. Wikichile (talk) 12:02, 24 April 2012 (UTC)

• 1) Sounds like you want $wgFlaggedRevsAutoReview = FR_AUTOREVIEW_NONE.
• 2) There isn't really a feature for this. If you discover a problem, it is usually OK to just fix the article and review the new edit.
• 3) Make sure your config is below the include/require statement that loads FlaggedRevs. Aaron (talk) 22:30, 28 April 2012 (UTC)

Flagging edits only by users with certain qualities?

Is there a way flag edits for review only if the (editing) user has certain preferences or attributes? Suppose we want only users with a certain User Preference to have their edits flagged for review, and everybody else gets autoconfirmed. Is this possible to set up with a hook in PHP, say, like this:

if ($user->getOption('my custom option') = 'some value') {
 $wgFlaggedRevsAutopromote = array('edits' => 1);  // Would this work?
} else {
 $wgFlaggedRevsAutopromote = false;
}

Or is there another approach that could work? Thanks very much. Maiden taiwan (talk) 22:38, 7 March 2012 (UTC)

You can grant 'autoreview' rights via some of the hooks in includes/User.php based on user preferences I guess. Aaron (talk) 18:16, 8 March 2012 (UTC)

Great suggestion - thanks!

In our case, we need to review edits made by employees in a particular office, but other edits (from other offices) wouldn't need review. Maiden taiwan (talk) 15:51, 9 March 2012 (UTC)

Have you also considered just using custom user groups? Aaron (talk) 12:50, 10 March 2012 (UTC)

Editors should not flag their own articles

Hello, for self-control - is it possible that editors can't rate their own articles? 85.232.7.145 10:12, 8 March 2012 (UTC)

There is no setting to enforce that. You can at least disable auto-review for new pages though. Aaron (talk) 18:15, 8 March 2012 (UTC)

Thanks a lot... 85.232.7.145 09:01, 9 March 2012 (UTC)

Config the rating options?

Hello again,

is is possible to configure the rating-options? "Review"- User should only see the option:

• <label for="wpaccuracy">Status</label>
• <option class="fr-rating-option-0" value="0">
• <option class="fr-rating-option-1" value="1">

PHP

• 'revreview-accuracy' =>
• 'revreview-accuracy-0' =>
• 'revreview-accuracy-1' =>

"Editor"- User should only see the option:

• <label for="wpaccuracy">Status</label>
• <option class="fr-rating-option-0" value="0">
• <option class="fr-rating-option-1" value="1">
• <option class="fr-rating-option-2" value="2">

PHP

• 'revreview-accuracy' =>
• 'revreview-accuracy-0' =>
• 'revreview-accuracy-1' =>
• 'revreview-accuracy-2' =>

No one should see and use the select options

• id="wpdepth"
• id="wpstyle"

PHP

• 'revreview-depth' =>
• 'revreview-style' => 85.232.7.145 10:32, 8 March 2012 (UTC)

remove the sight of an page

hello, is it possible to remove the sight of an page? I want this design with only two buttons: Example. I want the "Sichtung entfernen" button. Can it somewhere activate or configure? 141.35.213.221 10:58, 8 March 2012 (UTC)

What does this do exactly? You can already de-accept accepted page revisions. Aaron (talk) 18:17, 8 March 2012 (UTC)

This is what i want. de-accept and accept. but de-accept is not option. How can I de-accept? Only over the history?

The file is from wikipedia.de. There is no explanation. It was the "Sichtung entfernen" button who capture my attention. 141.35.213.221 08:18, 9 March 2012 (UTC)

How to use?

I can find no way to use this extension. Help me here? HTFFanBrandon04 (talk) 04:57, 26 March 2012 (UTC)

It's complicated. So, what exactly is your problem here? Jasper Deng (talk) 05:01, 26 March 2012 (UTC)

I don't know how to use this extension. It's complicated! HappyTreeFriends (my home page or talk 2 me) 10:12, 9 April 2012 (UTC)

I've never had problems with that extensions, neither installing and configuring it nor working with it. Tim (SVG) 11:15, 9 April 2012 (UTC)

Oh, you probably know I was using a different signature. That's HTFFanBrandon04's new signature. And how do I use the extension? Did I miss a requirement? What do I have to do? HappyTreeFriends (my home page or talk 2 me) 12:08, 9 April 2012 (UTC)

The only thing you can miss is adding the SQL tables. Tim (SVG) 12:14, 9 April 2012 (UTC)

What is an "SQL table", and what does "SQL" stand for? I use SQLite, a very lightweight database system as an alternative to MySQL. So a database is needed to store revision flagging statistics? I already have an SQLite database file! Give me all the information about the SQL tables, maintenance scripts, etcetera. All for this extension, FlaggedRevs, allowing you to vote revisions of a page. HappyTreeFriends (my home page or talk 2 me) 14:24, 9 April 2012 (UTC)

You just need to import /extensions/FlaggedRevs/schema/mysql/FlaggedRevs.sql (path for MW 1.18, trunk's path is /extensions/FlaggedRevs/backend/schema/mysql/FlaggedRevs.sql) or you run update.php. Tim (SVG) 14:47, 9 April 2012 (UTC)

Yeah, MediaWiki often requires command-line access; I personally use MySQL as MediaWiki has the best support for it. Jasper Deng (talk) 18:50, 9 April 2012 (UTC)

In the MediaWiki 1.17 and 1.18 installations:

SQLite is a lightweight database system which is very well supported. (How to compile PHP with SQLite support, uses PDO)

I use SQLite, and .sqlite and .sql files are the same????

I do not know the proper extension for my database files, should they end with .sqlite or .sql? Please reply to me as soon as possible, in order to figure out why I cannot use the existing database file and create a new database file to store revision flagging statistics? HappyTreeFriends (my home page or talk 2 me) 22:24, 9 April 2012 (UTC)

SQL is a universal language. .sql files should work in anything that deals with SQL - they're a list of database commands. Jasper Deng (talk) 22:31, 9 April 2012 (UTC)

Also, are .db files same as .sql and .sqlite files? "DB" means "Data Base", or "database". What is a database, and .db files are same as .sql and .sqlite files? HappyTreeFriends (my home page or talk 2 me) 22:38, 9 April 2012 (UTC)

.sql files are command scripts for any SQL database; .db is used by MySQL, and .sqlite by SQLite for actual databases. Jasper Deng (talk) 22:42, 9 April 2012 (UTC)

Using this new extension is so complicated!!! What do I do now? HappyTreeFriends (my home page or talk 2 me) 22:48, 9 April 2012 (UTC)

You don't need to know anything about all that if you knew how to run things from the command line. Depending on your OS, you should run something like php update.php. Jasper Deng (talk) 22:49, 9 April 2012 (UTC)

I guess he doesn't know what a commandline is and he has probably no commandline access. Just import the SQL file into the database, should work then. Tim (SVG) 06:39, 10 April 2012 (UTC)

Also doesn't work for me. What I did: Downloaded the trunk version (because I run MediaWiki 1.19 and the 1.18-Version threw error messages), executed /FlaggedRevs/backend/schema/mysql/FlaggedRevs.sql (thanks for that tip), but as not logged in I can edit every post and every change is saved immediately. The info box that changes will be reviewed isn't visible.

The flagged-box is vissible weather logged in or not logged in. When logged in I get a "Label version" box at the bottom of every page. So something seems to work but the feature that not every user can edit posts without reviewing ist missing. 194.25.185.146 09:47, 25 June 2012 (UTC)

Extending the Review Comment

I'm putting this in place for some verbose people. When they review, they're going to want to include at least 100 - 400 words of comment to express why they reviewed the document the way they did.

I'm trying to extend the comment field without breaking the extension, but have had no luck.

what changes do I need to make to which files to get a bigger comment field (it's limited to 255 chars)? can I change the form appearance without breaking the extension, if so, how? 130.64.94.229 16:38, 23 April 2012 (UTC)

I would recomment using a subpage of the article to make comments on specific revision IDs. One could probably whip up some template magic for this. It wouldn't be easy to just hack in a large comment box, and it would also require thinking about the UI (where would these long comments show up and who would read them?). Aaron (talk) 20:42, 26 April 2012 (UTC)

Cannot download for v1.18

I get an error when downloading the version for MW 1.18.

The error is:

Invalid response from remote subversion client.

Would love to use the extension but right now I am a bit stuck.

Thanks,

Gareth. 62.24.245.200 15:16, 1 May 2012 (UTC)

I second that.

I have used "svn checkout http://svn.wikimedia.org/svnroot/mediawiki/trunk/extensions/FlaggedRevs/" to get the latest version. hth 212.183.43.48 17:08, 5 May 2012 (UTC)

Status should be shown

Hello,

I want that all users can see the status (flagged, not flagged or proved) of a page.
It is possible?

Thank you 80.149.179.2 11:41, 3 May 2012 (UTC)

Set $wgFlaggedRevsLowProfile = false; Aaron (talk) 17:18, 4 May 2012 (UTC)

Thank you, but in which document? Localsettings.php ? 80.149.179.2 08:33, 10 May 2012 (UTC)

Yep. Aaron (talk) 16:27, 10 May 2012 (UTC)

PHP fatal Error after having upgraded to mediawiki 1.19.0

Hello, I've tried to upgrade mediawiki to 1.19.0 (from 1.18.2) but it seems that 'FlaggedRevs' is not compatible. Some pages (like main page) stay blank with the error below: <pre style="overflow:auto;">[Fri May 04 06:52:07 2012] [warn] [client xxx.xxx.26.122] mod_fcgid: stderr: PHP Fatal error: Call to undefined method OutputPage::getImageTimeKeys() in /var/www/wiki.debian-fr/extensions/FlaggedRevs/presentation/FlaggedPageView.php on line 1100, referer: http://www.isalo.org/wiki.debian-fr/index.php?title=wiki.debian-fr:Accueil

Thank you, Laurent. Lol313 (talk) 05:30, 4 May 2012 (UTC)

Did you also upgrade FlaggedRevs? AFAIK, that function was renamed (image -> file). Aaron (talk) 17:16, 4 May 2012 (UTC)

Hi,

Thank you for your answer Aaron.

No I kept last stable version (1.18.+) - my mistake ?

I'll try with the trunk one, I saw it's version for 1.19+

I'll be back soon with a feedback! Lol313 (talk) 08:24, 5 May 2012 (UTC)

Solved, that rock's

Thank you very much!

My Wiki: http://wiki.debian-fr.org Lol313 (talk) 08:52, 5 May 2012 (UTC)

Possibility to disable "review is pending message" for anon users?

Currently on edited pages a message "N changes in this version are pending review. ..." shows up. While this is certainly interesting for users that may edit, especially reviewers, I don't want this information to display for anon users at all. Same question for the small dropdown with the same info on the right. Thanks. 212.183.43.48 17:05, 5 May 2012 (UTC)

You'd have to use site JavaScript/CSS. Aaron (talk) 23:15, 11 May 2012 (UTC)

This is interesting, can you suggest how, please?

Thank you Gborgonovo (talk) 12:56, 15 April 2014 (UTC)

How to flag pages?

How do I flag pages so edits to the page require review? Captaincollect1970 (talk) 23:33, 31 May 2012 (UTC)

You need the 'stablesettings' right. If you have it, the protection form will show a link to the FlaggedRevs config for the page. Aaron (talk) 03:22, 5 June 2012 (UTC)

The 'stablesettings' right is already for admins. So how do I configure pending changes? Captaincollect1970 (talk) 18:28, 5 June 2012 (UTC)

This discussion is now pretty much closed because it hasn't been responded for too long. Captaincollect1970 (talk) 04:14, 7 June 2012 (UTC)

Your API help is not enough

It lacks of information for prop=flagged, in particular, how to get approved status for a given revid, not just get stable id for a page. KPu3uC B Poccuu (talk) 03:55, 4 June 2012 (UTC)

See prop=revisions examples at http://www.mediawiki.org/w/api.php. You can add the 'flagged' param to rvprop. Aaron (talk) 03:25, 5 June 2012 (UTC)

How to automatically approve all pages after importing from another wiki?

subj. Serdtsev (talk) 13:57, 8 June 2012 (UTC)

You could try to adapt a JavaScript such as wikibooks:pt:MediaWiki:Gadget-MassReview.js for your specific needs. Helder 15:34, 8 June 2012 (UTC)

Hi Helder,

Thanks for fast answered.

What is the language of the text in this script? Portuguese?

How to use this script after adding in the gadgets? Serdtsev (talk) 07:13, 9 June 2012 (UTC)

Yes, it is Portuguese.

The script will add a link in the top right of the pages (in the same portlet menu where the "move" link is). If you click the link it will ask for a number of pages to review. Then it will get a list of unreviewed pages from MediaWiki API and check each of them to see if the last edit was made by a user listed in the variable "admins" (mostly sysops in the case of Portuguese Wikibooks, but in essence the list should consist of trusted users from your wiki). Helder 11:46, 9 June 2012 (UTC)

The is a script to review all pages in FlaggedRevs/maintenance. Aaron (talk) 03:11, 12 June 2012 (UTC)

Error caused by FlaggedRevs when upgrading Wiki to 1.19

Hi! I've just upgraded my Wiki to 1.19 and everything works fine till I try to start 'FlaggedRevs' extension.

What and how I do?

1. I downloaded the extension from its page.
2. I unzipped it and than uploaded to the appriopriate folder on my server
3. As I don't have a root access (I'm using a shared hosting) I tried to launch the web update in the way described in Manual:update.php
4. I received the following information:

Warning: call_user_func_array() [<a href='function.call-user-func-array'>function.call-user-func-array</a>]: First argument is expected to be a valid callback, 'FlaggedRevsUpdaterHooks::addSchemaUpdates' was given in /home/koleje/public_html/y/includes/Hooks.php on line 216


An error occured: Detected bug in an extension! Hook FlaggedRevsUpdaterHooks::addSchemaUpdates failed to return a value; should return true to continue hook processing or false to abort. Backtrace:

The system configuration is as follows:

Apache version: 2.2.21

PHP version: 5.2.17

MySQL version: 5.0.45

Thanx in advance for all help and advices. Pawel Niemczuk (talk) 21:16, 26 June 2012 (UTC)

What version of FlaggedRevs is it? Aaron (talk) 05:02, 28 June 2012 (UTC)

On the day when I reported the error I downloaded (as I suppose) the newest version of FlaggedRevs from ist page using Git Master (snapshot was temporarily not working). Today I downloaded again FlaggedRevs v. 1.19 but this time using a snapshot. And again an error appeares. This time when I try to launch a web updater (after uploading FlaggedRevs to an appriopriate directory and adding the demanded line to LocalSettings.php) I get the following error:

Fatal error: Class 'FlaggedRevsUISetup' not found in /home/koleje/public_html/z/extensions/FlaggedRevs/FlaggedRevs.php on line 48

I presume I'm doing something wrong but I don't have the vauguest idea what I'm doing wrong... Pawel Niemczuk (talk) 04:09, 30 June 2012 (UTC)

That doesn't make much sense. That code line is almost right after the line "

require( dirname( __FILE__ ) . '/frontend/FlaggedRevsUI.setup.php' );". If that file wasn't found, you would have had a different fatal, so it must exist. Aaron (talk) 19:10, 5 July 2012 (UTC)

Dear Aaron, it seems that all my problems were caused by an inappriopriate hosting. I've just moved to a different one (with a root-access) and everything works fine! Once again thanks a lot for your patience and attention! Pawel Niemczuk (talk) 18:40, 9 July 2012 (UTC)

Same here... I think my hoster is fine, I uploaded the extension and tried to update via the webinstall, leading to "Detected bug in an extension! Hook FlaggedRevsUpdaterHooks::addSchemaUpdates failed" :/ Pattyland (talk) 20:23, 27 May 2013 (UTC)

I've finally solved the problem by moving my website to a hosting service with a shell access. Before that I tried webistall, i also downloaded everything (files, database) to a local machine, executed all necessary scripts on the local machine and than uploaded everything to the remote one. And I haven't managed to solve the problem in this way either. So I can't help you. The only thing I can say is: when I moved to a new hosting with shell access where I can execute all necessary scripts from a command line, everything works fine and smoothly without any problems. Pawel Niemczuk (talk) 22:50, 27 May 2013 (UTC)

Well, the solution can't be to change the webhoser, right? :( An extension should be installable in both ways Pattyland (talk) 21:25, 28 May 2013 (UTC)

Actually, the documentation says that shell access is a requirement to run MediaWiki. You can try workarounds like Extension:Maintenance, but advanced features (like FlaggedRevs probably is) are more likely to break. Nemo 12:40, 29 May 2013 (UTC)

Problem after installation! [HELP]

Hello!
MediaWiki Version: 1.19.1

Well, after installing this extension I found two problems on my wiki:
1 - The sortable option on DPL lists don't work anymore.
2 - The new editor don't work 100% (see)

Someone can help me to solve this problems?
Thanks in advance! 177.64.76.59 22:53, 7 July 2012 (UTC)

Are you talking about Extension:VisualEditor when you say "new editor"? Jasper Deng (talk) 00:27, 8 July 2012 (UTC)

...or maybe about the Extension:WikiEditor? Helder 14:43, 8 July 2012 (UTC)

Sorry, I forgot it. Is Extension:WikiEditor. 177.64.76.59 17:22, 8 July 2012 (UTC)

Hello, I found the bug and fixed, thanks for the attention. 177.64.76.59 16:29, 10 July 2012 (UTC)

$wgFlaggedRevsAutoReviewNew

Hi. Checking the NOC file (section 'fiwiki') I've found the variable $wgFlaggedRevsAutoReviewNew = true; but I couldn't find here the meaning of that variable. What it does? Is the same as $wgFlaggedRevsAutoReview = FR_AUTOREVIEW_CREATION_AND_CHANGES; ? Thanks. --Marco Aurelio (talk • meta) 16:11, 8 August 2012 (UTC)

Setting that var sets FR_AUTOREVIEW_CREATION. If $wgFlaggedRevsAutoReview === true as well, then it's like FR_AUTOREVIEW_CREATION_AND_CHANGES. $wgFlaggedRevsAutoReview is best configured as a bitfield but the old ways still work. Aaron (talk) 19:19, 8 August 2012 (UTC)

Thanks - I planned to set in the config

$wgFlaggedRevsAutoReview = FR_AUTOREVIEW_CREATION_AND_CHANGES;

So that just folks with the autoreview permission (plus editors, reviewers, admins, etc...) could have their edits and page creations automatically marked as sighted. --Marco Aurelio (talk • meta) 09:40, 9 August 2012 (UTC)

Exclude Categories complete with articles

Hey,

is it possible to exclude Categories complete with articles from reviewing? I would like to exempt categories including subcategories and pages from reviewing. Or am i allowed to define special categories for reviewing?

I only find the config: $wgFlaggedRevsWhitelist = array( 'Main_Page' );

Thanks a lot. 85.232.7.145 12:12, 14 August 2012 (UTC)

I'm not sure what the question is. Are you talking about category pages or pages in categories? Aaron (talk) 19:46, 14 August 2012 (UTC)

Hey Aaron,

I mean both, category pages and normal pages in categories. F. e. we have a "category:cookbook" with more than 100 pages (recipes). This category including all subcategories and pages should not be reviewed.

Do I have to write every pagename in the function

$wgFlaggedRevsWhitelist = array( 'recipe1', 'recipe2' ... 'recipe100' );

or is there a smarter way?

Thanks a lot. 85.232.7.145 09:31, 15 August 2012 (UTC)

There is no feature to whitelist all pages in a category. The way category membership is tied to parsing would make this trickly/slow to implement. Aaron (talk) 21:07, 15 August 2012 (UTC)

Hey Aaron,

thanks for your help. Have a nice weekend. 85.232.7.145 14:19, 17 August 2012 (UTC)

How to do this "Your changes will be displayed to readers once an authorized user accepts them" for media wiki user when users edit any page.?

I want that when any registered user want to contribute by editing my existing page the content edited by user should not directly display on the edited page or page created by any user should not be displayed directly first the user edited content should displayed after authorized user accepts them . Nawalsaini (talk) 11:25, 24 August 2012 (UTC)

You need to set $wgFlaggedRevsNamespaces to all the namespaces you want (see includes/defines.php). Aaron (talk) 04:28, 7 September 2012 (UTC)

Error in contribs

Hi, after I installed the FlaggedRevs extension, the following PHP warning turned up in the contribs page.

Warning: Missing argument 4 for FlaggedRevsUIHooks::addToContribsLine() in path/to/wiki/extensions/FlaggedRevs/frontend/FlaggedRevsUI.hooks.php on line 495 
Warning: Cannot modify header information - headers already sent by (output started at path/to/wiki/extensions/FlaggedRevs/frontend/FlaggedRevsUI.hooks.php:495) in path/to/wiki/includes/WebResponse.php on line 38

The first line repeats for every edit shown in the contribs page. Could anybody help me with this? Thanks! Cloud668 (talk) 07:18, 28 August 2012 (UTC)

Maybe the extension and core mediawiki version don't match? Aaron (talk) 01:26, 4 September 2012 (UTC)

API hook to action=parse to default to the latest stable version

Is there a specific method I can use to do this?

Is/are there a setting/s I can use instead of a hook? GHenle (talk) 17:13, 6 September 2012 (UTC)

Not aware of one. Aaron (talk) 17:11, 26 September 2012 (UTC)

How to disable diff overview

This extension shows diff between rewieved and current version above edit window. How to disable this feature? AS (talk) 10:53, 2 October 2012 (UTC)

It should start off collapsed, so why is this a problem? Aaron (talk) 01:51, 27 November 2012 (UTC)

It's showed full after saving AS (talk) 11:46, 23 March 2013 (UTC)

Mark reviewed pages as UNREVIEWED with the API

Because of the workflow in our office....we have a need to mark reviewed pages as unreviewed. Not sure how to do that with the API. Any help is appreciated. 64.124.79.214 18:19, 2 October 2012 (UTC)

See api.php (there is an 'unapprove' parameter for apireview). You cannot mark entire pages as unreviewed however. Aaron (talk) 01:50, 27 November 2012 (UTC)

confirmation

I want that: Our viki visitors can edit and create pages. But changes confirm by administrators and after content will be publish. if administrators is not confirm, changes will not show other visitors. How i make that? Bekircem (talk) 14:29, 4 October 2012 (UTC)

No you mean not show at all? That's harder to do. But if you want the last stable version of pages to show (unless the user clicks on a link to see the draft), than can be done via $wgFlaggedRevsOverride and $wgFlaggedRevsExceptions (see FlaggedRevs.config.php). Aaron (talk) 01:49, 27 November 2012 (UTC)

First review date

Is there ability to know the date of first page review? I want to use it with Semantic MediaWiki extension to show only reviewed pages on StartPage. Maybe some magic word (__FIRSTREVDATE__) or parser function? How can I use FlaggedRevs PHP classes to make magic word myself? Thanks alot! 91.225.116.75 07:00, 31 October 2012 (UTC)

I'm not familiar enough with SMW I'm afraid. Aaron (talk) 18:58, 28 November 2012 (UTC)

edits stopped working after installing FlaggedRevs for wiki v 1.18

I installed FlaggedRevs usings "FlaggedRevs-5e5dc25.tar.gz" and it seemed to be going well until I tried to edit an article. It gave me the internal server error once I saved my changes. It happens for all users.

Any ideas? Stumped....

Thank you~ Michelle~ 108.178.189.46 22:09, 6 November 2012 (UTC)

Also, when I accept revisions, it doesn't stick. Meaning it still stays in "unaccepted" status.

Maybe I have a buggy version.

Can someone tell me where to go to download the stable version for wiki v 1.18? 108.178.189.46 22:22, 6 November 2012 (UTC)

Undefined index: demoted

I got error message:

<b>Notice</b>:  Undefined index: demoted in <b>/home/receptdo/public_html/test/extensions/FlaggedRevs/backend/FlaggedRevs.hooks.php</b> on line <b>913</b><br />

What is the problem? Luft-on (talk) 17:18, 20 November 2012 (UTC)

What version of the code is used? It looks like the latest uses the "empty" function to avoid warnings. Aaron (talk) 01:47, 27 November 2012 (UTC)

New pages don't need approval

When I create a new page, it seems to not be under rev. control. Only when the page is accepted for the first time, future changes are handled correctly. Is there any way to disable this behaviour? 213.235.220.170 08:45, 27 December 2012 (UTC)

Set $wgFlaggedRevsAutoReview accordingly and make sure you have 'autoreview' rights. Aaron (talk) 00:06, 10 January 2013 (UTC)

After uninstall users still show FlaggedRevs groups

After uninstalling FlaggedRevs, Special:ListUsers still shows users are in groups autoreview, editor and reviewer - although in plain text and no longer as links. How to remove these from the User list? Robkam (talk) 19:12, 9 January 2013 (UTC)

I don't know of any script to remove user groups. If you don't care about adding user rights log entries, then you can start maintenance/sql.php and issue a SQL statement like "DELETE FROM user_groups WHERE ug_group IN ('editor','reviewer','autoreview')". If there are many users you may want to add "LIMIT 100" to the end and keep running it until there are 0 affected rows. Aaron (talk) 00:04, 10 January 2013 (UTC)

Approve all pages?

Is it possible to approve all pages at once? I know there is a maintenance script called "reviewAllPages.php" but this will only mark my pages as sighted. I want them to be approved. Maybe I can modify the reviewAllPages.php script?

Thanks! Stefan 13:18, 1 February 2013 (UTC)

You can change the '$flags = FlaggedRevs::quickTags( FR_CHECKED ); // Assume basic level' line I suppose. Aaron (talk) 01:03, 4 February 2013 (UTC)

Ok I tried this and changed the line to '$flags = FlaggedRevs::quickTags( FR_QUALITY ); // Assume basic level' but nothing changed, then I tried with '$flags = FlaggedRevs::quickTags( FR_PRISTINE ); // Assume basic level' and again nothing changed. I'm not really much of a coder :/

Do you have another suggestion what I could try to get all pages approved? Maybe an SQL Statement?

Thanks Stefan 07:55, 4 February 2013 (UTC)

What does var_dump( FlaggedRevs::quickTags( FR_QUALITY ) ); give in eval.php? Aaron (talk) 01:11, 7 February 2013 (UTC)

Enabled (I think) but not doing anything ...

I've gone through what I think are the appropriate threads in this forum, as well as used search, but have to be missing something, because its still not working .. at least, I don't think it is.

First, installed from git, onto a mediawiki 1.20.3 install ... modified my LocalSettings.php file, to include:

== require_once("$IP/extensions/FlaggedRevs/FlaggedRevs.php");

$wgFlaggedRevsStatsAge = false; $wgFlaggedRevsExceptions = array( ); $wgFlaggedRevsAutoReview = FR_AUTOREVIEW_NONE; ==

And left the default set for:

$wgFlaggedRevsOverride = true;

So, if I'm reading right, any edit / new page has to go through a reviewer before its visible to anyone, logged in or not.

I have non-logged in allowed to edit (internal wiki, we just don't want to have to create user accounts for everyone *just in case* someone decides to want to edit) ...

when I go to a page on the site that doesn't exist, and click 'edit', it allows me to edit and save, but its instantly visible, no review required.

I went to the database itself and looked in the various flagged* tables, and nothing seems to be being written there either ... so figured I have to had missed a step in this process *somewhere* ...

Now, I may be mis-understanding the intent of this extension, but I'm hoping its just some flag I'm not noticing that needs to be set ... from reading through the threads here, I had found '$wgFlaggedRevsAutoReview = FR_AUTOREVIEW_NONE;' ... so is there maybe another that I haven't stumbled across yet ... ?

Thanks ... 142.32.208.237 22:25, 20 March 2013 (UTC)

New unreviewed pages are always fully visible. FlaggedRevs only applies to pending edits to reviewed pages. It might be interesting to add a feature to not let google et all index new unreviewed pages, but hiding brand new pages is tricky to implement and be usable. Aaron (talk) 07:29, 21 March 2013 (UTC)

'k, a bit more awkward then I'd hoped, but I can work around that ... not a showstopper. But just to clarify:

1. FR_AUTOREVIEW_NONE
2. Don't auto-review any edits or new pages

Doesn't actually apply to "new pages" then ... ? Or am I mis-understanding what is meant by disabling auto-review?

But, that said, I just went to a page that I created previously as Anon, clicked the Edit button, added text to it and Saved ...

Again, its totally visible to the next Anon person to come along, and checking the database, still nothing in the flaggedrevs table:

mediawiki=# select * from flaggedrevs;

fr_rev_id | fr_rev_timestamp | fr_page_id | fr_user | fr_timestamp | fr_quality | fr_tags | fr_flags | fr_img_name | fr_img_timestamp | fr_img_sha1

-----------+------------------+------------+---------+--------------+------------+---------+----------+-------------+------------------+-------------

(0 rows) 142.32.208.237 17:17, 21 March 2013 (UTC)

A new page that is not reviewed/auto-reviewed acts almost the same with FlaggedRevs enabled as it does without it enabled. Even if autoreview is totally disabled, new pages will still be visible just like without FlaggedRevs. The extension only changes the workflow once a page actually as at least one reviewed version. Aaron (talk) 23:07, 25 March 2013 (UTC)

'k, we can definitely live with that ... the problem that I'm currently having is that I never seem to get any pages *for* review ... all the FlaggedRev tables seem to be empty, even after I create a new page *and* subsequently edit it again ... I'v checked my PostgreSQL server log for any SQL errors (ie. a missed column, duplicate key, etc) and its all totally clean ... which leads me to believe I've missed a setting somewhere ...

thoughts? direction? 142.32.208.226 16:11, 26 March 2013 (UTC)

Do you have the review form on any pages? Nothing will go in any tables until revisions start getting reviewed by admins. Aaron (talk) 20:39, 26 March 2013 (UTC)

'k, first, just did a fresh install of mediawiki 1.20, and installed FlaggedRevs using:

cd extensions

git clone https://gerrit.wikimedia.org/r/p/mediawiki/extensions/FlaggedRevs.git

Set the following in my LocalSettings.php:

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

$wgDefaultUserOptions['flaggedrevsviewdiffs'] = true;

$wgFlaggedRevsStatsAge = false;

$wgFlaggedRevsExceptions = array( );

$wgFlaggedRevsAutoReview = FR_AUTOREVIEW_NONE;

Steps followed:

1. Go to a non-existent page
2. Click Edit / Create
3. Enter text, click Save
4. Go to page as Reviewer (I see a Review this Revision at bottom of page, and an 'Unchecked' at the top)
5. Click Accept Revision, and it generates the following error in the database:

ERROR: invalid input syntax for type timestamp with time zone: "" at character 195

STATEMENT: SELECT /* FlaggableWikiPage::updatePendingList OpenStudent Sup... */ fr_rev_id,rev_timestamp FROM "flaggedrevs","revision" WHERE fr_page_id = '2' AND fr_quality = '1' AND (fr_rev_timestamp > <singlequote><singlequote>) 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

And nothing seems to happen past that ... so, if I'm reading what you've said previously accurately, the reason I'm not seeing anything in any of the flaggedrev tables is because I need to click Accept Revision on page creation to effectively get it into the workflow, and the error above is preventing that from processing properly ... ?

So, how to fix that bug? 142.32.208.226 22:06, 27 March 2013 (UTC)

Hi, I also have a wiki to expand I want to be happy, because FlaagedRevs is an asset. Now I have tried several times to get this extension to work, but unfortunately appears to me, the various database tables do not exist.

My Wiki is running at a hosting provider, where there is no command-line access for my web hosting offer. According to me there is only one mentioned by the web update feature (Manual: Upgrading#Web_updater), but it still lacks the tables. What should one do now to get to run the extension?

The same steps as the previous speaker, I also performed several times without success. My wiki is running in german.

Here are some examples that are missing tables:

----------------------------------------------------------------------------------------------------

Example #1

Die letzte Datenbankabfrage lautete:

(Die SQL-Datenbankabfrage ist verborgen.)

aus der Funktion „SpecialRecentChanges::doMainQuery“. Die Datenbank meldete den Fehler „1146: Table 'example.flaggedpages' doesn't exist (46.228.199.146)“.

or:

----------------------------------------------------------------------------------------------------

Example #2

Die letzte Datenbankabfrage lautete:

(Die SQL-Datenbankabfrage ist verborgen.)

aus der Funktion „IndexPager::buildQueryInfo (contributions page unfiltered)“. Die Datenbank meldete den Fehler „1146: Table 'example.flaggedrevs' doesn't exist (46.228.199.146)“.

---------------------------------------------------------------------------------------------------- Abani79 (talk) 22:56, 30 March 2013 (UTC)

Does running php <PATH TO MEDIAWIKI>/maintenance/update.php --quick help? Aaron (talk) 00:00, 31 March 2013 (UTC)

Hey Aaron, whereas i can use the webupdater, the wiki setup starts and check some tasks to do and quits then. But i haven't command-line access, so i'm unable to use commands like this. Is there no solution, to lets tasks how it the update.php with command-line access do, the web updater perform the same?

My experience tells me, that such tasks never performed, like updating database tables, or i am wrong with this?

Thank you anyway, for your reply. :) Abani79 (talk) 00:14, 31 March 2013 (UTC)

How to organize chain of several approvals for one page

Hi,

I need to organize in private wiki following workflow for page acceptance or return to lower level: user A can accept and send page to user B user B can accept and send page to user C or can return page to user A user C can accept and send page to user D or can return page to user B user D can accept and send page to user E or can return page to user C user E can accept and send page to user F or can return page to user D user F can accept and send page to see by anonymous readers (without login) or can return page to user E Thanks for reply in advance Peter Peter195 10:56, 5 July 2013 (UTC)

Is it possible to apply reviewing to only some specific pages?

Is it possible to apply reviewing per-page instead of per-namespace?Just like the pending change protection on English wikipedia.Is there a way to do so? Lsmll (talk) 07:48, 6 July 2013 (UTC)

$wgFlaggedRevsProtection = true (see FlaggedRevs.config.php comments). Aaron (talk) 04:45, 23 July 2013 (UTC)

Updating FlaggedRevs leads to PHP error

After successfully upgrading to Mediawiki 1.21 FlaggedRevs produced a PHP error, so I decided to update FlaggedRevs, too.

Unfortunately, I get the following PHP errors:

PHP Notice: Undefined property: SkinMonoBook::$mTitle in D:\Programme\Apache Software Foundation\Apache2.2\htdocs\w\extensions\FlaggedRevs\FlaggedArticleView.php on line 989 PHP Fatal error: Call to a member function isTalkPage() on a non-object in D:\Programme\Apache Software Foundation\Apache2.2\htdocs\w\extensions\FlaggedRevs\FlaggedArticleView.php on line 989

Can anyone help? Thanks in advance.

Martin 91.20.28.170 10:32, 10 July 2013 (UTC)

How to make stable version from pristine version

Hi, my lowest reviewed version is presented as stable for non-users. How can I do pristine version a stable one?

Thanks in advance Peter 31.61.140.106 06:34, 13 July 2013 (UTC)

There are ways to give links to it, but you cannot make it the stable version (unless it's the latest of course). Aaron (talk) 17:45, 21 July 2013 (UTC)

Script not working when loading from Mobile phone

The main page is loading fine when using my desktop browser, but when loading the wiki main page from my android phone, i am getting this error msg : Fatal error: Call to undefined method Revision::getContent() in extensions/FlaggedRevs/backend/FlaggedRevs.class.php on line 570 any hint? am using latest versions of MW and this Extension. 92.151.114.70 22:44, 14 July 2013 (UTC)

Wiki does not show stable version for non-users

Hi, problem is as in the subject. Instead of stable version, reviewed version in presented. In table flaggedrevs there are values 2 in fr_quality fields. The table flaggedpage_config is empty. Settings in Localsettings.php as follow: $wgFlaggedRevsVisible = array( '*' ); $wgFlaggedRevsOverride = true; $wgHooks['TitleReadWhitelist'][] = 'efFlaggedRevsHooks_userCanView'; function efFlaggedRevsHooks_userCanView( Title $title, $user, &$result ) {

   global $wgFlaggedRevsVisible, $wgTitle;
   if ( empty( $wgFlaggedRevsVisible ) ) {
       return true;
   }
   # Admin may set this to false, rather than array()...
   $groups = $user->getGroups();
   $groups[] = '*';
   if ( !array_intersect( $groups, $wgFlaggedRevsVisible ) ) {
       return true;
   }
   # See if there is a stable version. Also, see if, given the page
   # config and URL params, the age can be overriden. The later
   # only applies on page views of $title.
   if ( !empty( $wgTitle ) && $wgTitle->equals( $title ) ) {
       $view = FlaggablePageView::singleton();
       // Cache stable version while we are at it.
       if ( $view->showingStable() ) {
           $result = true;
       }
   } else {
       // Search and such need to know that the reader can view this page
       if ( FlaggedRevision::newFromStable( $title ) ) {
           $result = true;
       }
   }
   return true;

}

$wgFlaggedRevsPrecedence = 2;

Thx for help 195.205.47.232 13:25, 18 July 2013 (UTC)

The "precedence" setting was basically removed in newer versions. Aaron (talk) 04:43, 23 July 2013 (UTC)

So, how can I present for non-users only pristine versions in my private wiki? (only pristine should be visible nothing else).

How to do it?

Thx in advance Peter 195.205.47.232 08:13, 23 July 2013 (UTC)

Aaron could You please prepare and send me patch to allow for non-users read only pristine version in my private wiki?

Regards, Peter 195.205.47.232 08:18, 23 July 2013 (UTC)

How do notifications work?

Hi Aaron,
is there a way that reviewers get an email notification about sites that need to be reviewed?
Or is it "only" possible via watchlists?
My customer's desire is, that the reviewers get one mail a week - containing all the articles that have been created or edited. I don't know if that is possible...
Thanks. Stefahn (talk) 10:16, 18 August 2013 (UTC)

I have the same requirement. Any solution out there? Thanks! LFS (talk) 20:01, 12 February 2015 (UTC)

Feature Request: Please provide more EchoEvents or add some hooks.

Hi Aaron Schulz, hi Joerg Baach!

I noticed that in the current version there is a minimal support for the new Echo notification system. At the moment only rejections create an EchoEvent. This is pretty cool. But it would be great to have more EchoEvents, like when an article gets approved or a new draft version is created. As FlaggedRevs is productive on many WMF sites I understand if this may be a little overhead. As an alternative FlaggedRevs could have some hooks of it's own, that third party extensions can bind to and fire custom EchoEvents. I think the most important hook would be something like FlaggedRevsRevisionReview. Maybe some *Before* and *After* hooks would make sense too.

Maybe I could add some EchoEvents/Hooks myself and submit a patch to gerrit?

P.S.: FlaggedRevs is a really awesome extension and makes MediaWiki even more valuable. Thanks a lot! Osnard (talk) 15:29, 18 October 2013 (UTC)

This was started in https://gerrit.wikimedia.org/r/#/c/79775/ but not finished. Someone could finish and fix that up I suppose. Aaron (talk) 23:02, 28 October 2013 (UTC)

Hi! Thanks for the reply. I will see if I can find some time for it. What would you prefer? Echo integration or Hooks that allow third party users to implement their own notifications? Osnard (talk) 08:08, 7 November 2013 (UTC)

I found this FR while searching for FlaggedRev hooks. I would prefer hooks, especially because I'd like to do some automated actions after a revision has been approved. I guess hooks are more flexible, and I use them a lot to inject my own functionality into MediaWiki. But then again, for those who have only a hammer, everything looks like a nail. GolezTrol (talk) 22:50, 29 November 2013 (UTC)

Version 1.14?

How to get version 1.14 of FlaggedRevs?

It seems I can only get 1.19 and above. Via ViewVC I can take a look at 1.14, but only download single files. How do I get the whole thing? 178.9.118.197 15:04, 20 October 2013 (UTC)

svn co https://svn.wikimedia.org/svnroot/mediawiki/branches/REL1_14/extensions/FlaggedRevs/

? Nemo 16:49, 20 October 2013 (UTC)

Documenting the meanings of color-coded contributions

I see that Help:Extension:FlaggedRevs#Current colors has a helpful guide to what FlaggedRevs colors mean on edit lists, but an inline comment says "Found these colors on www.mediawiki.org, and guessed the respective meanings based on a user's contribution list. Don't know if they are the extension's default or a custom version of them specific of that site." - so it sounds like they should be verified. :) I noticed those colors while looking at Wikibooks, and I wrote a comment suggesting improved documentation there as well. Thanks! Dreamyshade (talk) 07:50, 28 November 2013 (UTC)

I did what I could - see the diff - let me know if you see any colours that aren't listed there, but I think I got all of 'em. MarkTraceur (talk) 08:08, 28 November 2013 (UTC)

new page hide until reviewed

This post by Nemo bis was moved on 2013-12-09. You can find it at Extension talk:Approved Revs/Archive 2013#new page hide until reviewed. Nemo 13:20, 9 December 2013 (UTC)

Use api instead of action=ajax

According to the Ajax manual, `api.php` should be used instead of the obsolete `action=ajax`.

I guess and hope that would also allow people (like me ;)) to use the APIAfterExecute to hook into FlaggedRev's actions. GolezTrol (talk) 19:45, 10 December 2013 (UTC)

Hide or change "Edit" tab on stable pages

Is possible to hide or change the edit tab in a page with at least one stable revision in a given namespace?

FlaggedRevs is enabled at pt.wikisource in some namespaces. The usage on the main namespace is to keep the text as it is on the source (if the source isn't provided by Extension:ProofreadPage but for some resource without original scans), but keeping the page editable for annotations, new metadata, category changes and related stuff. The edit tab may looks for external users as "I can change the words in this work!" even if the changes don't get approved.

See for example s:pt:O Piolho Viajante/XXXVIII (the JS trick on [Expandir] shows the source info).

This is not a community request/question, only an individual user thinking while doing some edits =) 555 (talk) 17:51, 13 December 2013 (UTC)

ReviewAllPages.php reports errors

I cann't review all pages using reviewAllPage.php script. The following messages occur:

yoga:/srv/mediawiki-1.21.1/extensions/FlaggedRevs/maintenance # php ./reviewAllPage.php --conf ../../../LocalSettings.php --username Admin

PHP Notice: Undefined index: * in /srv/www/htdocs/mediawiki-1.21.1-II-instancja/extensions/ConfirmEdit/ConfirmEdit.php on line 206 Reviewer username: Admin First argument must be a Title or WikiPage. Backtrace:

1. 0 /srv/www/htdocs/mediawiki-1.21.1-II-instancja/extensions/FlaggedRevs/backend/FlaggedRevs.class.php(1022): FlaggedRevs::stableVersionUpdates(Object(Article))
2. 1 /srv/www/htdocs/mediawiki-1.21.1-II-instancja/extensions/FlaggedRevs/maintenance/reviewPagesInFile.php(94): FlaggedRevs::autoReviewEdit(Object(Article), Object(User), Object(Revision), Array, true)
3. 2 /srv/www/htdocs/mediawiki-1.21.1-II-instancja/extensions/FlaggedRevs/maintenance/reviewPagesInFile.php(26): ReviewAllPages->autoreview_current(Object(User))
4. 3 /srv/www/htdocs/mediawiki-1.21.1-II-instancja/maintenance/doMaintenance.php(110): ReviewAllPages->execute()
5. 4 /srv/www/htdocs/mediawiki-1.21.1-II-instancja/extensions/FlaggedRevs/maintenance/reviewPagesInFile.php(118): require_once('/srv/www/htdocs...')
6. 5 {main}

Can anybody sugest me what I should correct? Thanks in advance. 31.62.233.77 10:10, 28 December 2013 (UTC)

How do I modify the protection interface for stable settings (add more than just none and sysop)?

Right now I have $wgFlaggedRevsProtection=true and when I go to protect the page, it shows the flaggedrevs settings all right but the only options are to not protect it (allow all) and protect it so that it must be reviewed AND auto-reviewed by sysop. I want it to be possible for autoconfirmed to auto-accept their own edits like on enwiki with pending changes protection enabled. I have let "autoconfirmed" to have "autoreview" but still those two (none and sysop) are the only protection settings in the menu. 88.113.156.12 07:25, 8 January 2014 (UTC)

Try changing $wgFlaggedRevsRestrictionLevels. Aaron (talk) 23:12, 25 February 2014 (UTC)

Getting $wgFlaggedRevsNamespaces configuration in JavaScript

Hello,

I am looking for a way to get the content of $wgFlaggedRevsNamespaces variable through javascript, to define if a particular namespace is under review or not. I've searched in API help but it seems there is no sush a feature.

Of course, I could :

1. list namespaces through meta=siteinfo&siprop=namespaces
2. look for the first page in each namespaces with list=allpages
3. test the flag status of theses pages through prop=flagged

but wow, this is a bit complicated just to get this poor information.

Does anyone know an easier way to do it?

Thank you. ⇨ Dr Brains ^{∞ Doléances ∞} 19:13, 20 January 2014 (UTC)

Restrict to specific pages

I only need this on a few pages. I know there is a whitelist, but I need ALL of my pages except a few exempted. Is there a way to create an array of the titles of all current pages and then remove the specific pages? Could I create a specific category? I know I can restrict it to a namespace, but these are just basic articles + the main page. Indolering (talk) 00:05, 4 April 2014 (UTC)

You can try setting $wgFlaggedRevsProtection = true and manually adding the pages as an admin. Aaron (talk) 23:12, 7 April 2014 (UTC)

Pending changes page style

Is it possible to assign a style to paending changes page? Has it a dedicated class? I cannot find it.

Thank you. Gborgonovo (talk) 12:29, 15 April 2014 (UTC)

advertise not working

Hi!

when I click on "advertise" this text appears: "Notice: Other reviewers can see that you are reviewing these changes."

but:

• for other users this changes nothing. Another reviewer doesn't see that I'm reviewing that page
• when I click on "de-avertise" nothing happens. The text doesn't disappear.

Version: REL1_22 with mw1.22.5 Koemski (talk) 16:18, 15 April 2014 (UTC)

bounce Koemski (talk) 11:54, 12 May 2014 (UTC)

I believe the best way is to report a bug on bugzilla in case nobody has done so in the meantime. [[kgh]] (talk) 12:02, 12 May 2014 (UTC)

filed report: https://bugzilla.wikimedia.org/show_bug.cgi?id=65572 93.218.90.247 08:26, 21 May 2014 (UTC)

Setting "Revision displayed on default page view" does not work

Hi,

I use FlaggedRevs REL1_22

Setting the above mentioned option does not have any effect at all. When I set it to "the stable version" I still get the "Pending changes" Tab displayed.

In my personal prefs I set "Use the default settings for each page" and this is my config in LocalPreferences.php:

# Extension:FlaggedRevs
$wgFlaggedRevsStatsAge = false;
require_once("$IP/extensions/FlaggedRevs/FlaggedRevs.php");
$wgGroupPermissions['sysop']['autoreview'] = false;
$wgGroupPermissions['editor']['autoreview'] = false;
$wgGroupPermissions['bot']['autoreview'] = false;
$wgGroupPermissions['reviewer']['autoreview'] = false;
$wgFlaggedRevsTags = array(
    'accuracy' => array( 'levels' => 1, 'quality' => 1, 'pristine' => 1 ),
);
$wgFlaggedRevsAutoReview = false;

Best, Koem 93.218.105.206 16:39, 20 May 2014 (UTC)

filed bug: https://bugzilla.wikimedia.org/show_bug.cgi?id=65574 93.218.90.247 08:32, 21 May 2014 (UTC)

How to get list of pages with includes

Hi,

When reading an article with includes, I'm notified by FlaggeRevs about the changes in includes, and it correctly shows the last valid version. But I can't find a way to get a list of pages which includes have been changed.

I have $wgFlaggedRevsAutoReview = FR_AUTOREVIEW_NONE; and $wgFlaggedRevsHandleIncludes = FR_INCLUDES_STABLE; in my Localsettings.php.

Is there a way to get such a list, as we can have the list of reviewed pages with pending changes ?

Best regards,Ludovic. Ludovic Strappazon (talk) 09:31, 12 June 2014 (UTC)

Hide newly created article

A new created article is always displayed even if not approved. Is there a way to hide newly created articles as in the extension ApprovedRevs?

Regards Dominik 80.70.182.98 10:30, 24 June 2014 (UTC)

Yes, this is a feature I am missing most. We're mostly having issues with spammers that create new pages. Hiding new pages by default would discourage spammers. Can you add this please? 78.53.96.13 23:25, 23 September 2014 (UTC)

This is possible, though the configuration needed is a bit more on the advanced side. For how to configure it, see the page Extension:FlaggedRevs/Restricting unapproved revisions. JoelKP (talk) 23:38, 27 December 2014 (UTC)

But this method is not compatible with requirements of TimedMediaHandler extension. So, it would be nice if You add this feature. It will be very usefull. 31.61.131.235 16:47, 30 December 2014 (UTC)

User groups resetting after relogin

When I add user to group editor or reviewer or autoreviewer or all off them user can review, all works well. But after user relogin he is deleting from this groups: MessageCache::load: Loading ru... got from global cache Unstubbing $wgParser on call of $wgParser::firstCallInit from MessageCache::getParser Parser: using preprocessor: Preprocessor_DOM Unstubbing $wgLang on call of $wgLang::_unstub from ParserOptions::__construct User: cache miss for user 97 User: loading options for user 97 from database. DatabaseBase::query: Writes done: DELETE FROM `user_groups` WHERE ug_user = '97' AND ug_group = 'editor' 91.197.189.174 12:32, 7 August 2014 (UTC)

I have the same problem. Anybody have an idea of what might be happening? Bty0808 (talk) 20:37, 21 September 2017 (UTC)

What authentication extension do you use? Bty0808 (talk) 14:21, 7 March 2018 (UTC)

No new revision if template is changed...

Hi! I really don't want to re-approve every page that has a certain template, once I change the template. Is there a way to disable this requirement or auto-approve in these cases (if the page was approved before) ? Heinrich krebs (talk) 15:04, 14 August 2014 (UTC)

Any help? Please. Heinrich krebs (talk) 16:44, 11 September 2014 (UTC)

Hi,

have a look at $wgFlaggedRevsHandleIncludes. You can find a detailed description in the FlaggedRevs.config.php file in the extensions root folder. Osnard (talk) 11:29, 16 September 2014 (UTC)

Thank you. I will change the settings there, and hope it'll fix the problem. Heinrich krebs (talk) 17:16, 17 September 2014 (UTC)

Everyone sees Edit Review widget after installation

Hi,

I successfully installed FlaggedRevs extension for my internal wiki. However even if I log-in as user I can see Edit Review widget even though in installation notes it says nobody would see it until relevant permissions are granted. the only line for this extension in localsettings I have is require_once..

Any idea? Edga (talk) 10:12, 10 September 2014 (UTC)

The reviewer's widget isn't the little box in the top right corner. Everyone is supposed to be able to see that. The reviewer's widget is the big box all along the top of the page with buttons to accept or reject the revision. Jackmcbarn (talk) 14:17, 10 September 2014 (UTC)

Class 'FlaggedRevs' not found

Before item 6.2 of Setup manual tried to run updateStats.php and got error about class 'FlaggedRevs' not found.

Then I did items 7 (Enable FlaggedRevs) and 8 (Update MediaWiki's database schemas) and returned to item 6.2. UpdateStats.php worked succesful!

May be move item 6 (Enable collection of article review statistics) after item 8? Avshukan (talk) 13:12, 16 September 2014 (UTC)

Set up different Revs for different NS

I would like to set up some permissions for a NS and others for another NS. For example:

• NS1: all users can edit, some can review (ns1-reviewers), and somebody can validate (ns1-validators)
• NS2: normal users can only read, only ns2-editors can edit, ns2-reviewers can review (end edit) in ns2, and ns2-validators can validate (and edit and review)

Is this possible? How...?

Thank you Gborgonovo (talk) 17:32, 6 November 2014 (UTC)

Is ns1 group a subset of ns2, or vice versa? Does ns1 group edit ns2, and vice versa? Nemo 07:32, 7 November 2014 (UTC)

No, they are completly different and separated ns, and the groups (as well) must have different permissions. Gborgonovo (talk) 08:27, 7 November 2014 (UTC)

Show non-checked page version until review = quality or higher

This extension could be very useful to my agency, if I can get the configuration set to meet our requirements. I followed the instructions for restricting unapproved revisions, which almost works for my purposes. I have multiple tags, and my wgFlaggedRevsTags array is set such that each tag requires a level 2 in order to be considered "quality". The behavior I'd like to see is that each tag is controlled by a different reviewer, and only when all reviewers have set level 2, and we have "quality" achieved, is the revised page shown to anonymous users. Instead, what I see is that when any of the tags reaches level 2, putting the page into a "checked" state, the page is then displayed to anonymous users prior to the "quality" state being reached. How might I go about fixing this? 198.214.211.107 20:00, 2 December 2014 (UTC)

It looks as though there is not an available configuration option that I can set to modify the default behavior from accepting draft revisions (i.e. less than quality) as reviewed/stable. I can work around the need for having each reviewer control different levels on different tags, but I really need the viewable versions for anonymous users to only show once quality or pristine levels are reached. Having pages viewable after they have just been checked, but not yet reached quality will not work for my purposes. Can anyone help suggest what modifications I might try to this extension in order to get what I'm after? Many thanks. 198.214.211.106 16:51, 9 December 2014 (UTC)

Maybe look at https://www.mediawiki.org/wiki/Extension:FlaggedRevs/Restricting_unapproved_revisions . Aaron (talk) 07:45, 11 February 2015 (UTC)

In fact the issue is not "how to not show unstable versions" but how to have stable versions only if a tag has reach a certain level.

For exemple, with only one tag with 3 levels Draft-Verified-Approved : how to tell the extension to consider that "Verified" is not a stable state and thus not shown by default (with $wgFlaggedRevsOverride = true) Bruno Spy (talk) 07:10, 27 August 2015 (UTC)

Is there any update to this? I have the same question:

3 Levels: Draft - Verified - Approved. Only Approved shall be considered as stable, how to achieve this?

Setting is "status" => array('levels' => 2, 'quality' => 3, 'pristine'=3).

Currently all pages having status "Verified" are considered as "stable". 193.5.216.100 (talk) 08:20, 9 May 2018 (UTC)

MW version

I've been using the FlaggedRevs since MW 1.15 at least (march 2010) The Infobox now mentions MW 1.17+ Why? Arent (talk) 14:31, 9 December 2014 (UTC)

Actually nobody should use a MW-version older than MW 1.19 so even 1.17 is an outdadated information. The current code in the repo will not work for versions earlier than MW 1.17 anyway. I believe this website should not advertise the usage of outdated and unsupported software since the docu also caters for potential new users. For them it is not important to know that it used to work somehow for an ancient release at some time in the past. [[kgh]] (talk) 15:13, 9 December 2014 (UTC)

People 'should not' use pre-1.19 MW version of course, but in the meantime you'll find heaps of older installations. Especially when you already have a tooled-up wiki with heavy extensions and/or old-style skins it is not always that easy to upgrade. MW usually upgrades fine but with SMW and FlaggedRevs and skinning and ... I need to stay at 1.16 that I've been using for years. If the infobox says that FlaggedRevs is only useable from 1.17 (downloadable for 1.19++) it displays incorrect information. Sometimes you are forced by circumstances to do what you ideally wouldn't do. Arent (talk) 15:37, 9 December 2014 (UTC)

You are writing about existing users. They know that it used to work somehow for an ancient release at some time in the past. [[kgh]] (talk) 15:55, 9 December 2014 (UTC)

Arent, the extension infobox always talks of master (or latest stable branch). It's a known deficiency that MediaWiki.org currently is unable to provide a compatibility matrix: only Semantic Bundle and MLEB do such a thing, the other extensions are left to wikiapiary: (which we link). Nemo 16:14, 9 December 2014 (UTC)

Can FlaggedRevs be used to tame $wgRawHtml ?

When allowing raw html in a wiki ($wgRawHtml), the FlaggedRevs review interface unfortunately shows the changes to the reviewer. Not only in textual form (the diff) but the actually rendered page.

Can this be disabled?

I am concerned, that evil javascript could be used to steal the login cookie of an admin.

If admins could review the just textual diff before that rendered page is shown to anyone, then admins could just decline the edit if someone added some javascript that they don't like without running it in their browser before. Otherwise it's hard to prevent execution of javascript by non-admin editors. Adrelanos (talk) 23:44, 27 January 2015 (UTC)

$wgRawHtml must not be used in a wiki where untrusted users can edit, period. Nemo 08:21, 28 January 2015 (UTC)

FlaggedRevs with AutoWikiBrowser

I use AutoWikiBrowser to review and script alot of autoedits within my wiki. I would like to be able to review pages with FlaggedRevs at the same time. Is there any collaboration between the two, or has anyone developed any plugins or modules that would allow the cross functionality? Sdsolutions (talk) 18:10, 2 March 2015 (UTC)

API and FlaggedRevs

Ad API talk:Main page#API and FlaggedRevs.

I think that function to check the selected article will be usefull. This function schuld returned: pageid, title, reviewed version id (+date, +author), most current version id (+date, +author). Malarz pl (talk) 07:06, 15 April 2015 (UTC)

You can check if the article is reviewed with this:

- https://fi.wikipedia.org/w/api.php?action=query&prop=info%7Cflagged&titles=Turku

If stable_revid=lastrevid then page is reviewed and it doesn't have pending changes

If stable_revid!=lastrevid then page is reviewed and it have pending changes

if there is no flagged information then page is unreviewed

However i don't think that you can get information of date + author of old version with single query. Zache (talk) 08:18, 16 April 2015 (UTC)

Thanks. When I check oldreviewed I got dates of last edit and last stable version. It's all I need now. Malarz pl (talk) 12:32, 16 April 2015 (UTC)

Main, File and Template ns + Category, Module, User, Project and Help added

I saw that these questions. I wanted to write the solution. Open the file extensions/FlaggedRevs/FlaggedRevs.config.php . Edit form : $wgFlaggedRevsNamespaces = array( NS_MAIN, NS_USER, NS_PROJECT, NS_FILE, NS_MODULE, NS_TEMPLATE, NS_HELP, NS_CATEGORY );. That's it. Now; Go to the main index with PuTTY. ssh command : php maintenance/populateImageSha1.php run. After; php extensions/FlaggedRevs/maintenance/updateStats.php run. That will be all. Easy to come. İncelemeelemani (talk) 13:33, 1 May 2015 (UTC)

That file must not be edited directly. Place your configuration in LocalSettings.php, adding the line

$wgFlaggedRevsNamespaces = array( NS_MAIN, NS_USER, NS_PROJECT, NS_FILE, NS_MODULE, NS_TEMPLATE, NS_HELP, NS_CATEGORY );

after the line calling FlaggedRevs. Nemo 06:08, 14 May 2015 (UTC)

No Such Special Page

I installed the latest version of FlaggedRevs on my wiki which is 1.25.1. When I go and accept a revision on an editable page it says No Such Special Page. I'm not sure what I did wrong or what I need to change. Bennkenn (talk) 14:43, 16 June 2015 (UTC)

Do you see the special page in "Special:SpecialPages" on your wiki? Nemo 07:55, 2 July 2015 (UTC)

Have the same problem with MediaWiki 1.25.3 and FlaggedRevs REL1_25 2015-06-16T21:07:19. I can't see anything suspicious in the logs, and reviewing works, but the special pages related to FlaggedRevs have disappeared. Пика Пика (talk) 10:51, 6 November 2015 (UTC)

I have found the cause of that problem: some extensions cannot create special pages if inside LocalSettings.php $wgGroupPermissions['*']['read'] = false; is set. so not working on private wiki.

btw i have same problem on 1.26.2 (latest stable) Ibutakov.smartec (talk) 14:44, 21 March 2016 (UTC)

Size of 'flaggedrevs_statistics'

What's this table role and how to prevent it's overgrowing? ParaSigma (talk) 11:12, 6 January 2016 (UTC)

Creating new page

In my wiki when user without high permissions create a new page this page is unreviewed so next edits aren't reviewed. Is it possible to set up that every new page create by user automatically has stable version? 31.172.189.50 (talk) 13:31, 16 February 2016 (UTC)

Why would it be good? The goal of FlaggedRevs is to have all edits manually flagged—it includes page creations. (Of course it doesn’t refer to “high permissions”, i.e. at least autoconfirmed users, whose edits to flagged pages are always flagged—again regardless of whether it’s a page creation or a normal edit.) Tacsipacsi (talk) 14:41, 16 February 2016 (UTC)

You are right but when user without autoconfirmed perimissions created a new page and wrote content, reviewer can't reject this revision only accept. So it is possible to set up that first automatically stable version of new page is blank page and all content which user wrote will be pending changes? 31.172.189.50 (talk) 11:47, 17 February 2016 (UTC)

We use this extension on the Hungarian Wikipedia, and the general rule is that a reviewer should flag the revision (while reverting or tagging it if not correct). The technical equivalent of reverting at new pages is speedy deletion (for non-sysops it’s of course marking for speedy, while flagging it). Why would be the stable version a never-existed one? Tacsipacsi (talk) 23:07, 17 February 2016 (UTC)

Is there a way to hide the new pages until they aren't revised? P.gibellini (talk) 15:36, 30 April 2016 (UTC)

Currently there isn't. How do you think it (i.e. what would anonymous users see instead of the article; what would be the color of links pointing to such articles, red or blue)? Or what do you mean under "hiding" of these articles? Tacsipacsi (talk) 16:55, 30 April 2016 (UTC)

This is a good question. A new page created by a normal user at the moment is immediately visible to all the users (with the flag of "to be revised", of course).

Perhaps it could be added a parameter in LocalSettings.php in order to choose wether show the page as in current version of FlaggedRevs or to show instead a simple placeholder (something like "This is a new page and needs to be revised"). I'd not bother to change the colors of the links. P.gibellini (talk) 15:57, 1 May 2016 (UTC)

Thank you for clearing your conception. (I don't know if anyone's going to implement it.) Tacsipacsi (talk) 21:15, 1 May 2016 (UTC)

User rights

User rights are extremely confusing.

• autoreview receives autoreview right,
• editor receives review as his main right (why is he not reviewer then?),
• reviewer receives validate as his main right (why is he not validator then?).

Years extension enabled in uk.wiki I am still confused. Ата ^(talk) 19:40, 24 February 2016 (UTC)

API

How can i check via API who reviewed specific revision? I'd like to have revision history with information which revision was flagged and who did it. Malarz pl (talk) 12:31, 13 April 2016 (UTC)

It can be queried with the page history (example query). It seems to be available only with prop=revisions (not with list=allrevisions). Tacsipacsi (talk) 16:26, 13 April 2016 (UTC)

Thanks for help. I added rvprop-flagged to API:Revisions. Malarz pl (talk) 06:52, 14 April 2016 (UTC)

Question to set Site to Sighted

Problem with installation MW1.27

Hello. I've some troubles installing FlaggedRevs extension. I've followed the process (except the cron part §6.2) and when returning on the wiki I've the following message :

"A database query error has occurred. This may indicate a bug in the software."

I've checked the data base : there is a table called "approved_revs" with 5 lines.

I'm on a shared hosting (PHP 5.6.24).

Does anybody knows what I may try to do ? 176.182.100.164 (talk) 13:29, 6 August 2016 (UTC)

I've ran the maintenance/populateImageSha1.php script using the Maintenance extension with a new line in the metadata.ini. The message told me it ran succesfully. 176.182.100.164 (talk) 13:31, 6 August 2016 (UTC)

"I've checked the data base : there is a table called "approved_revs" with 5 lines." sorry this has no link with the subjet 176.182.100.164 (talk) 13:43, 6 August 2016 (UTC)

Set Manual:$wgShowExceptionDetails to true to see details about the error. I don't know what's the relation about the error and having to run the populateImageSha1.php script Ciencia Al Poder (talk) 16:42, 7 August 2016 (UTC)

I've set $wgShowExceptionDetails to true, but unfortunately, I've then a blank page. Even the message "A database query error has occurred. This may indicate a bug in the software." disappear. 176.182.100.164 (talk) 16:09, 16 August 2016 (UTC)

You must have been messed something up in LocalSettings.php when adding $wgShowExceptionDetails, like introducing a syntax error. Common causes are a missing semicolon, a typo or introduction of garbage characters. Ciencia Al Poder (talk) 16:21, 16 August 2016 (UTC)

OK, you were wright, thanks. Anyway, I don't have any new message in addition of "A database query error has occurred. This may indicate a bug in the software."

Is it possible the update.php didn't run well : are there some new tables that should have been add in the wiki database ?

Here is the log for the update :

"Turning off Content Handler DB fields for this part of upgrade.

...have ipb_id field in ipblocks table.

...have ipb_expiry field in ipblocks table.

...already have interwiki table

...indexes seem up to 20031107 standards.

...have rc_type field in recentchanges table.

...index new_name_timestamp already set on recentchanges table.

...have user_real_name field in user table.

...querycache table already exists.

...objectcache table already exists.

...categorylinks table already exists.

...have pagelinks; skipping old links table updates

...il_from OK

...have rc_ip field in recentchanges table.

...index PRIMARY already set on image table.

...have rc_id field in recentchanges table.

...have rc_patrolled field in recentchanges table.

...logging table already exists.

...have user_token field in user table.

...have wl_notificationtimestamp field in watchlist table.

...watchlist talk page rows already present.

...user table does not contain user_emailauthenticationtimestamp field.

...page table already exists.

...have log_params field in logging table.

...logging table has correct log_title encoding.

...have ar_rev_id field in archive table.

...have page_len field in page table.

...revision table does not contain inverse_timestamp field.

...have rev_text_id field in revision table.

...have rev_deleted field in revision table.

...have img_width field in image table.

...have img_metadata field in image table.

...have user_email_token field in user table.

...have ar_text_id field in archive table.

...page_namespace is already a full int (int(11)).

...ar_namespace is already a full int (int(11)).

...rc_namespace is already a full int (int(11)).

...wl_namespace is already a full int (int(11)).

...qc_namespace is already a full int (int(11)).

...log_namespace is already a full int (int(11)).

...have img_media_type field in image table.

...already have pagelinks table.

...image table does not contain img_type field.

...already have unique user_name index.

...user_groups table exists and is in current format.

...have ss_total_pages field in site_stats table.

...user_newtalk table already exists.

...transcache table already exists.

...have iw_trans field in interwiki table.

...wl_notificationtimestamp is already nullable.

...index times already set on logging table.

...have ipb_range_start field in ipblocks table.

...no page_random rows needed to be set

...have user_registration field in user table.

...templatelinks table already exists

...externallinks table already exists.

...job table already exists.

...have ss_images field in site_stats table.

...langlinks table already exists.

...querycache_info table already exists.

...filearchive table already exists.

...have ipb_anon_only field in ipblocks table.

...index rc_ns_usertext already set on recentchanges table.

...index rc_user_text already set on recentchanges table.

...have user_newpass_time field in user table.

...redirect table already exists.

...querycachetwo table already exists.

...have ipb_enable_autoblock field in ipblocks table.

...index pl_namespace on table pagelinks includes field pl_from.

...index tl_namespace on table templatelinks includes field tl_from.

...index il_to on table imagelinks includes field il_from.

...have rc_old_len field in recentchanges table.

...have user_editcount field in user table.

...page_restrictions table already exists.

...have log_id field in logging table.

...have rev_parent_id field in revision table.

...have pr_id field in page_restrictions table.

...have rev_len field in revision table.

...have rc_deleted field in recentchanges table.

...have log_deleted field in logging table.

...have ar_deleted field in archive table.

...have ipb_deleted field in ipblocks table.

...have fa_deleted field in filearchive table.

...have ar_len field in archive table.

...have ipb_block_email field in ipblocks table.

...index cl_sortkey on table categorylinks includes field cl_from.

...have oi_metadata field in oldimage table.

...index usertext_timestamp already set on archive table.

...index img_usertext_timestamp already set on image table.

...index oi_usertext_timestamp already set on oldimage table.

...have ar_page_id field in archive table.

...have img_sha1 field in image table.

...protected_titles table already exists.

...have ipb_by_text field in ipblocks table.

...page_props table already exists.

...updatelog table already exists.

...category table already exists.

...category table already populated.

...have ar_parent_id field in archive table.

...have user_last_timestamp field in user_newtalk table.

...protected_titles table has correct pt_title encoding.

...have ss_active_users field in site_stats table.

...ss_active_users user count set...

...have ipb_allow_usertalk field in ipblocks table.

...pl_namespace, tl_namespace, il_to indices are already UNIQUE.

...change_tag table already exists.

...tag_summary table already exists.

...valid_tag table already exists.

...user_properties table already exists.

...log_search table already exists.

...have log_user_text field in logging table.

...l10n_cache table already exists.

...index ls_field_val already set on log_search table.

...index change_tag_rc_tag already set on change_tag table.

...have rd_interwiki field in redirect table.

...transcache tc_time already converted.

...*_mime_minor fields are already long enough.

...iwlinks table already exists.

...index iwl_prefix_title_from already set on iwlinks table.

...have ul_value field in updatelog table.

...have iw_api field in interwiki table.

...iwl_prefix key doesn't exist.

...have cl_collation field in categorylinks table.

...categorylinks up-to-date.

...module_deps table already exists.

...ar_page_revid key doesn't exist.

...index ar_revid already set on archive table.

...ll_lang is up-to-date.

...user_last_timestamp is already nullable.

...index user_email already set on user table.

...up_property in table user_properties already modified by patch patch-up_property.sql.

...uploadstash table already exists.

...user_former_groups table already exists.

...index type_action already set on logging table.

...have rev_sha1 field in revision table.

...batch conversion of user_options: nothing to migrate. done.

...user table does not contain user_options field.

...have ar_sha1 field in archive table.

...index page_redirect_namespace_len already set on page table.

...have us_chunk_inx field in uploadstash table.

...have job_timestamp field in job table.

...index page_user_timestamp already set on revision table.

...have ipb_parent_block_id field in ipblocks table.

...index ipb_parent_block_id already set on ipblocks table.

...category table does not contain cat_hidden field.

...have rev_content_format field in revision table.

...have rev_content_model field in revision table.

...have ar_content_format field in archive table.

...have ar_content_model field in archive table.

...have page_content_model field in page table.

Content Handler DB fields should be usable now.

...site_stats table does not contain ss_admins field.

...recentchanges table does not contain rc_moved_to_title field.

...sites table already exists.

...have fa_sha1 field in filearchive table.

...have job_token field in job table.

...have job_attempts field in job table.

...have us_props field in uploadstash table.

...ug_group in table user_groups already modified by patch patch-ug_group-length-increase-255.sql.

...ufg_group in table user_former_groups already modified by patch patch-ufg_group-length-increase-255.sql.

...index pp_propname_page already set on page_props table.

...index img_media_mime already set on image table.

...iwl_prefix_title_from index is already non-UNIQUE.

...index iwl_prefix_from_title already set on iwlinks table.

...have ar_id field in archive table.

...have el_id field in externallinks table.

...have rc_source field in recentchanges table.

...index log_user_text_type_time already set on logging table.

...index log_user_text_time already set on logging table.

...have page_links_updated field in page table.

...have user_password_expires field in user table.

...have pp_sortkey field in page_props table.

...recentchanges table does not contain rc_cur_time field.

...index wl_user_notificationtimestamp already set on watchlist table.

...have page_lang field in page table.

...have pl_from_namespace field in pagelinks table.

...have tl_from_namespace field in templatelinks table.

...have il_from_namespace field in imagelinks table.

...img_major_mime in table image already modified by patch patch-img_major_mime-chemical.sql.

...oi_major_mime in table oldimage already modified by patch patch-oi_major_mime-chemical.sql.

...fa_major_mime in table filearchive already modified by patch patch-fa_major_mime-chemical.sql.

...user_id is already unsigned int.

...rc_comment in table recentchanges already modified by patch patch-editsummary-length.sql.

...hitcounter doesn't exist.

...site_stats table does not contain ss_total_views field.

...page table does not contain page_counter field.

...msg_resource_links doesn't exist.

...msg_resource doesn't exist.

...bot_passwords table already exists.

...have wl_id field in watchlist table.

...cl_collation key doesn't exist.

...index cl_collation_ext already set on categorylinks table.

...collations up-to-date.

...site_stats is populated...done.

Purging caches...done." 176.182.100.164 (talk) 17:16, 18 August 2016 (UTC)

Ok, maybe the right setting here is $wgShowSQLErrors = true; Ciencia Al Poder (talk) 20:46, 18 August 2016 (UTC)

OK it works. The error is :

• Query: SELECT page_id,page_namespace,page_title,page_restrictions,page_is_redirect,page_is_new,page_random,page_touched,page_links_updated,page_latest,page_len,page_content_model,fpc_override,fpc_level,fpc_expiry,fp_pending_since,fp_stable,fp_reviewed FROM `HELIOCENTRIXpage` LEFT JOIN `HELIOCENTRIXflaggedpages` ON ((fp_page_id = page_id)) LEFT JOIN `HELIOCENTRIXflaggedpage_config` ON ((fpc_page_id = page_id)) WHERE page_namespace = '0' AND page_title = 'Accueil' LIMIT 1
• Function: FlaggableWikiPage::pageData
• Error: 1146 Table 'gditrisk_heliocentrix.HELIOCENTRIXflaggedpages' doesn't exist (localhost)

So the flaggedpages table doesn't exist. I don't understand why : I've followed all the steps of the installation. May the problem come from the fact that I'm on a shared host ? 176.182.100.164 (talk) 16:08, 19 August 2016 (UTC)

From the output of the update.php process, apparently it hasn't populated any of the tables/fields of this extension. I'm not sure why.

FlaggedRevsUpdater.hooks.php contains the instructions to update the database, which in turn runs some of the scripts in the folders. You could run them manually but that's far from ideal, and you'll need to manually add the table prefix you're using. Ciencia Al Poder (talk) 10:23, 20 August 2016 (UTC)

tone, style, or Readability?

The article refers to "tone", but the current extension actually uses "style", not "tone". In the database, ft_tags has values like "accuracy:2\ndepth:2\nstyle:2\n". In the user interface, however, the "style" tag is displayed as "Readability". Maybe older versions of the extension had "tone" rather than "style" or "Readability", I don't know. Anyway, the documentation doesn't correctly describe the current extension. If I understand correctly, all references in the documentation to "tone" should be changed to "style", and there should be a note explaining that "Readability" in the user interface corresponds to "style" in the database. 66.75.59.84 (talk) 18:01, 19 November 2016 (UTC)

Missing Special Pages?

I noticed that some special pages are references by Flagged Revs but they are missing. How can I install those pages? THanks. Peteolsen (talk) 15:22, 28 November 2016 (UTC)

I had similar issues, I pulled the git version and not the distribution version. Ryan.lewkowicz (talk) 17:46, 13 December 2016 (UTC)

Which pages are missing and where (on which wiki)? Special pages usually can't be "installed" but are automatically enabled while installing the extension. Tacsipacsi (talk) 16:57, 28 November 2016 (UTC)

Special:UnreviewedPages and Special:PendingChanges

They are referenced by the FR but I don't have those special pages and I get an error.

Thanks

Pete Peteolsen (talk) 19:06, 28 November 2016 (UTC)

On which wiki don’t have you them? Here, of course, they don’t exist as FR is not installed on MediaWiki.org; it’s in use on just a few Wikimedia wikis, most notably the German Wikipedia. Tacsipacsi (talk) 19:15, 28 November 2016 (UTC)

I can confirm that none of the special pages mentioned here:

Extension:FlaggedRevs#Use

show up. I downloaded for MW version 1.29 from both the MW extension distributor as well as from git. There is no error, just a page stating that the special page does not exist. Jamal22066 (talk) 17:45, 20 November 2017 (UTC)

This is a private wiki we are developing for a client. It's an internal info wiki not available to the public. Peteolsen (talk) 19:56, 28 November 2016 (UTC)

Then it’s more difficult to debug. What error do you get? What is in LocalSettings.php (if FR variables can be published)? Tacsipacsi (talk) 21:36, 28 November 2016 (UTC)

I get the default special page not found error Peteolsen (talk) 12:30, 29 November 2016 (UTC)

I opened a ticket with the developers on this https://phabricator.wikimedia.org/T151870 Peteolsen (talk) 12:29, 29 November 2016 (UTC)

Bulk approve pages?

I imported all the pages from out old wiki via dump/import. I now have to go through and accept them all. There's the api, but I can't just list all pages from all namespaces and approve them. I'm still fiddling, but if anyone has an Idea let me know. Ryan.lewkowicz (talk) 17:48, 13 December 2016 (UTC)

I see on the maintenance subdirectory of the extension there's a reviewAllPages.php

You may be able to mark all as reviewed executing this script from the console Ciencia Al Poder (talk) 10:26, 14 December 2016 (UTC)

Advanced Review Log Customization

Hi all, I was wondering how we could customize the Special:AdvancedReviewLog to show only selected users (more than one, about 5), instead of all reviews.

If anyone knows, please let me know. PaleoIsh (talk) 15:18, 7 February 2017 (UTC)

Custom Namespaces not recognised

I use a adapted Version of ExtraNamespaces but only the usual 3 Namespaces are recognized (Main, Files, Templates).

In the LocalSettings.php i have only configured Main and then the numbers from the custom namespaces (100, 102 ...). The custom namespaces are properly listed in the special page "Links to this site" for example.

I runned the updateStats.php script manually but with no effect. Any suggestions what might be the problem? 193.5.216.100 (talk) 13:26, 9 August 2017 (UTC)

It appears that the config from FlaggedRevs.config.php is loaded and not the configuration set in LocalSettings.php. Any suggestions why? Sirlordrouter (talk) 14:13, 9 August 2017 (UTC)

Did you define $wgFlaggedRevsNamespaces before including FlaggedRevs? Like this:

$wgFlaggedRevsNamespaces = [ NS_MAIN, 100, 102 ];
require_once "$IP/FlaggedRevs/FlaggedRevs.php";

Then by including FlaggedRevs, you overwrite the custom configuration, so simply move the namespace config below the inclusion. Tacsipacsi (talk) 15:54, 9 August 2017 (UTC)

No, the require once is decalred befor any configuration.

This is my configuration in LocalSettings.php

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

#FlaggedRevs settings

$wgFlaggedRefsNamespaces = array(NS_MAIN, 100, 102, 104, 106, 108, 110, 112, 114, 116, 118, 220, 222, 224, 226, 228);

$wgFlaggedRevsHandleIncludes = FR_INCLUDES_FREEZE;

$wgFlaggedRevsOverride = true;

$wgFlaggedRevsAutoReview = FR_AUTOREVIEW_CHANGES;

$wgFlaggedRevsTags = array(

            'accuracy' => array( 'levels' => 2, 'quality' => 2, 'pristine' => 3 ),

);

$wgFlaggedRevsWhitelist = array('Main_Page'); Sirlordrouter (talk) 07:07, 28 August 2017 (UTC)

It’s misspelled: the variable is called $wgFlaggedRevsNamespeces. (Also, the [] notation is preferred instead of array() in MediaWiki code, see my code sample above. The latter causes no problems, but the former is shorter and is more similar to other languages’ array notation.) Tacsipacsi (talk) 14:25, 28 August 2017 (UTC)

Hello

I'm having the same problem, even though I've used the right code, and just like your example.

why? Davidnead (talk) 09:09, 16 October 2017 (UTC)

Give a user Editor but not autopatrol their edits

My wiki does a lot of realtime data entry, and so when I onboard new staff members for data entry, I want their edits to not go through approval before showing up on the page. But I do want them to show up as unpatrolled in Recent Changes so I can check over them at a later time. Does this extension allow for this, and if so, how can I configure it? RheingoldRiver (talk) 16:24, 22 January 2018 (UTC)

You can set $wgFlaggedRevsOverride = false;. Or just use the default patrol system (the disadvantage of the latter is that it’s accessible from fewer places and stores whether a revision was patrolled only for 30 days, but maybe it’s easier to configure). Tacsipacsi (talk) 19:48, 23 January 2018 (UTC)

The problem with that is that I still want changes from most users to be pending and not show up to regular visitors. There's basically three types of editors I need:

• Trusted editors, whose changes will be autopatrolled and accepted and immediately be live
• Trainee editors, whose changes will immediately be live for live data entry purposes, but will not be autopatrolled so that I can review what they did easily from recent changes
• Visitors who happen to edit the wiki, whose changes are both pending & unpatrolled when they edit

Is there any way to set up a system like this? RheingoldRiver (talk) 21:18, 24 January 2018 (UTC)

I don’t know about such settings. (There may be, though, I only know the default mode, not to speak about other extensions.) Tacsipacsi (talk) 12:07, 25 January 2018 (UTC)

How to disable "template/file changes in this version are pending review"

Is there any way to do this? If the template/file itself has been reviewed already or was done by someone with Editor permission, I don't need to review the change again on the page where it's transcluded/embedded. RheingoldRiver (talk) 16:33, 16 March 2018 (UTC)

And this message shouldn’t appear in that case, only if a non-trusted user edited a used template or file, and that edit hasn’t been reviewed yet. If it’s not the case, please report the bug on Phabricator. Tacsipacsi (talk) 21:18, 16 March 2018 (UTC)

Hmm I think this might be happening because the files were moved to a commons wiki and then deleted from this wiki (example page - https://lol.gamepedia.com/index.php?title=Afreeca_Freecs&oldid=880962&diff=curand I won't check it so it stays). Is that intended behavior? RheingoldRiver (talk) 01:18, 17 March 2018 (UTC)

I know this problem (though I have never reported it as a bug). To be honest, I think there’s no good solution for this problem – I see three possible options: the current one, where you have to mark each page using images from the central image repository as checked, another one is the ability to mark individual images stored in the central repo as checked, including ones that are never actually used on this wiki, and the third is to not require flagging for images of the central repo, which means that not all content will be checked, and vandals can overwrite images with anything with a lower risk of being reverted before anyone could see it. Tacsipacsi (talk) 12:39, 17 March 2018 (UTC)

Could I just totally disable the "pending changes for included files or templates" notice altogether? I know that's not a good option in general but it would work for my wiki - we have Pending Changes more to protect against well-intentioned but incorrect content page updates and rarely have to deal with vandalism or any template edits at all. RheingoldRiver (talk) 04:27, 18 March 2018 (UTC)

Maybe this can help: https://github.com/wikimedia/mediawiki-extensions-FlaggedRevs/blob/8e9cd5c6672eebda3fcf4f8f881c078487e0d619/FlaggedRevs.php#L208-L220 Osnard (talk) 12:05, 6 April 2018 (UTC)

Is there any attempt, to improve the usability in the next time?

FlaggedRevs is a powerfull tool, but for users beyond Wikipedia you easy lost the orientation. This starts with the fact that when comparing versions I only come back to the page via the article tab, this goes on with unclear labels and missing design. It's a pity that this great and popular expansion on the surface is still so weak. Can we help to move the issue forward? Is there a roadmap? RichardHeigl (talk) 08:20, 8 May 2018 (UTC)

Pages automatically become "unchecked" after some time

Is this a feature of FlaggedRevs? Is there any way I can disable it? Generally on my wiki if pages aren't edited for a long time it means they don't need to be updated, not that they need to be checked again. I'm not 100% sure things are being marked unchecked but it seems like they are. RheingoldRiver (talk) 07:20, 30 May 2018 (UTC)

It’s certainly not a feature, I don’t face with it on Wikimedia sites (mostly Hungarian Wikipedia). Is your wiki public? If yes, could you cite a specific page which has become unchecked? Tacsipacsi (talk) 15:05, 30 May 2018 (UTC)

It is public, mostly there have been some category pages which I'm pretty sure were checked & later on aren't checked. That said I don't have a page that I'm 100% certain this is happening to so I will reply again if I'm certain. RheingoldRiver (talk) 13:05, 4 June 2018 (UTC)

How do I $wgFlaggedRevsExceptions = [ '*' ]; works?

I've set $wgFlaggedRevsExceptions = [ '*' ]; for everyone see the latest edit. But this doesn't work. 181.55.114.245 (talk) 03:14, 16 May 2019 (UTC)

I've resolved this. I used $wgFlaggedRevsOverride and I set this to false.

$wgFlaggedRevsOverride = false; 181.55.114.245 (talk) 04:00, 16 May 2019 (UTC)

Any way to get the review status of a page via API?

Move FlaggedRev staus via XML-Dump into another wiki

I tried to dump my wiki into an XML and import it into a fresh installation. But FlaggedRevs weren moved too.

I used mediawiki's onboard maintenance scripts.

How would I fix that...? Heinrich krebs (talk) 15:10, 12 August 2019 (UTC)

Unfortunately the out-of-the-box tools of MediaWiki allow only to export "the lastest stable version", but not "all revisions with their flags". Additionally, the import does not know anything about flags. Osnard (talk) 06:24, 13 August 2019 (UTC)

Remove tags from $wgFlaggedRevsTags

Hi,

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? Zagy (talk) 06:34, 26 February 2020 (UTC)

What does it mean?

MediaWiki1.34.0 (ae6e0c0)

Flagged Revision – (784dad

Hi,

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).

Thanks.
Silkwood (talk) 11:54, 16 March 2020 (UTC)

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 Ciencia Al Poder (talk) 10:21, 17 March 2020 (UTC)

Hi,

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" ]; </source>

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 Silkwood (talk) 13:09, 17 March 2020 (UTC)

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 Ciencia Al Poder (talk) 10:28, 18 March 2020 (UTC)

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

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? Dovi (talk) 14:47, 28 April 2020 (UTC)

Compatibility with Wikibase

Does FlaggedRevs works with Wikibase and its Items and Properties? Luk3 (talk) 13:46, 28 September 2020 (UTC)

Is time delayed autoacceptance possible

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 Vis M (talk) 15:06, 8 November 2020 (UTC)

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. Ciencia Al Poder (talk) 16:00, 8 November 2020 (UTC)

I am actually asking for a time based autoacceptance Vis M (talk) 17:14, 8 November 2020 (UTC)

I have added a feature request at Phabricator: https://phabricator.wikimedia.org/T267642 Vis M (talk) 13:48, 10 November 2020 (UTC)

Ciencias proposal would be time based autoacceptence. An implementation via bot would be an easy alternative. MGChecker (talk) 13:32, 12 November 2020 (UTC)

Ok.

A proposal to add a time based auto-review feature to FlaggedRevs: w:Wikipedia:Timed flagged revisions. Vis M (talk) 17:03, 20 April 2021 (UTC)

variables for mw.config

Hi, is there any variables for FlaggedRevs ext. that could be retrieved by mw.config object? Mohanad (talk) 14:02, 24 December 2020 (UTC)

If you're on a page with FlaggedRevs active, there's wgStableRevisionId and, if it's not empty, wgFlaggedRevsParams. These were always present before https://gerrit.wikimedia.org/r/c/mediawiki/extensions/FlaggedRevs/+/508427. I think that's it; I previously put in a task for wgFlaggedRevsNamespaces. ~ Amory (u • t • c) 14:35, 24 December 2020 (UTC)

thx @Amorymeltzer Mohanad (talk) 14:41, 24 December 2020 (UTC)

Unable to open file

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 164.144.1.7 (talk) 16:08, 21 January 2021 (UTC)

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 Ciencia Al Poder (talk) 17:49, 21 January 2021 (UTC)

You should use

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

and not

wfLoadExtension('FlaggedRevs')

as the extension documentation instructs you to do. Tacsipacsi (talk) 19:31, 21 January 2021 (UTC)

That worked, thank you! 164.144.1.1 (talk) 19:28, 26 January 2021 (UTC)

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? 164.144.1.1 (talk) 20:13, 26 January 2021 (UTC)

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.) Tacsipacsi (talk) 22:38, 26 January 2021 (UTC)

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. 208.87.237.201 (talk) 15:48, 27 January 2021 (UTC)

Is there a script that allows mass flagging?

Is there a script that allows mass flagging? Zamkorus (talk) 12:57, 27 July 2021 (UTC)

There is https://github.com/wikimedia/mediawiki-extensions-FlaggedRevs/blob/REL1_35/maintenance/reviewAllPages.php

But it does not allow to specify a list of pages, but instead will really flag all pages in the activated namespaces.

There is also https://github.com/wikimedia/mediawiki-extensions-BlueSpiceFlaggedRevsConnector/blob/REL1_35/maintenance/BSBatchReview.php

AFAIK you don't even need to install BlueSpiceFlaggedRevsConnector. Just downloading and executing the script should be okay, Osnard (talk) 06:18, 28 July 2021 (UTC)

Ok, thanks. Zamkorus (talk) 09:24, 28 July 2021 (UTC)

UI improving

Problems after the update.

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? 2A01:261:D5B:1B00:392D:D612:2CD:2609 (talk) 19:20, 16 February 2022 (UTC)

FlaggedRevs & PostgreSQL 10

Another PostgreSQL issue - maintenance/updateStats.php

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)  

LIMIT 1;

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

Thank you for checking! Pglind (talk) 16:08, 3 March 2022 (UTC)

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

CREATE OR REPLACE FUNCTION UNIX_TIMESTAMP(TIMESTAMP

WITHOUT TIME ZONE)

RETURNS BIGINT

LANGUAGE SQL

IMMUTABLE STRICT

AS 'SELECT EXTRACT(EPOCH FROM $1)::bigint;';

CREATE OR REPLACE FUNCTION UNIX_TIMESTAMP(TIMESTAMP

WITH TIME ZONE)

RETURNS BIGINT

LANGUAGE SQL

IMMUTABLE STRICT

AS 'SELECT EXTRACT(EPOCH FROM $1)::bigint;';

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 Pglind (talk) 09:50, 4 March 2022 (UTC)

$wgFlaggedRevsWhitelist removed?

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? 37.225.66.149 (talk) 09:37, 22 May 2022 (UTC)

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. Tacsipacsi (talk) 11:14, 22 May 2022 (UTC)

Two identical user groups in Georgian Wikipedia

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? გიო ოქრო (talk) 14:44, 30 June 2022 (UTC)

That's something that should be reported at phabricator for investigation and fix, since that's a configuration issue. Ciencia Al Poder (talk) 09:25, 4 July 2022 (UTC)

Two issues

I recently installed MediaWiki and FlaggedRevs on my Windows laptop with XAMPP/Apache. I encountered two major issues which strangely are not mentioned on this site. Both are related to accessing rest.php.

Issue one: FlaggedRevs on Apache did not like this url format: localhost/Article. It prevented rest.php from being accessed. I had to change it to localhost/wiki/Article.

Issue two: FlaggedRevs on Apache did not work on subpages because their titles contain forward slashes. To fix this you need to set AllowEncodedSlashes to "NoDecode". On Apache, this feature is set to "Off" by default.

I wrote about these problems at bigger length on the support desk, see here. I do believe this site should have notes about these hurdles to prevent other people from wasting time on them like I did. Manifestation (talk) 12:59, 25 June 2023 (UTC)

Since I heard no objections, I added a little bit about the 2nd issue. As for the 1st issue, I asked the folks at Stack Overflow. Maybe they know what to do.

Oh, and btw... what's up with these <translate> tags all over this page? What is there purpose? Manifestation (talk) 12:53, 2 July 2023 (UTC)

Thanks to Stack Overflow, I now also fixed the 1st issue. I added the solution to the support desk thread. Manifestation (talk) 10:23, 3 July 2023 (UTC)

Special:PendingChanges not always working

I am unable to consistently get this to work. I want to make it so that any changes need to be approved first. I've played around with Help:Pending changes, but can't seem to get it to work every time.

Sometimes it works, othertimes not. Sometimes if I leave it for 5mins, then it works, but doesn't for another page...

I'm really dumbstruck. Any advice?

Running mw1.39 QixxDev (talk) 12:18, 25 July 2023 (UTC)

Yes, FlaggedRevs can be a pain. I got it working on my wiki after about a week of trying. Do you use Google Chrome? If so, you can press Ctrl + Shift + I on Windows, or Cmd + Option + I on Mac. Then go to "Console", and see what kind of error messages your site is giving. You can also check the error logs of the server to see what goes wrong. Manifestation (talk) 06:52, 26 July 2023 (UTC)

Thanks! This is a good hint! QixxDev (talk) 07:56, 26 July 2023 (UTC)

FlaggedRevs on 1.40

Fatal error: Uncaught ExtensionDependencyError: FlaggedRevs is not compatible with the current MediaWiki core (version 1.40.0), it requires: >= 1.41.