Extension talk:FlaggedRevs/archive 3

From mediawiki.org
Latest comment: 13 years ago by Aaron Schulz in topic Wrong command

How to view images for everyone[edit]

I installed FlaggedRevs. It works fine so far, but anonymic users can't see images which are linked on a page like

[[File:filename.gif]]

. The user only sees the link, but not the image. When logged in, I can see the image. How can I make images ALWAYS viewable for everyone ? Thanks for help !

Need special CSS for non-stable[edit]

I need to set up custom CSS for the non-stable version of articles. Is there already support for this? I looked through the actual output of a draft page and don't see any draft-specific classes for the content section. Series8217 17:15, 27 September 2010 (UTC)Reply

Draft is shown by default[edit]

I thought stable pages were supposed to be shown by default, but instead my users see the draft version of a page by default. They can change the setting by checking "Always show the stable version of content pages by default" in their preferences, but I want this option to be checked by default. I'm using the version of FlaggedRevs from here: http://svn.wikimedia.org/svnroot/mediawiki/branches/REL1_15/extensions/FlaggedRevs/ --Series8217 12:22, 24 September 2010 PST

I figured it out; I had to set $wgFlaggedRevsExceptions to an empty array. The default value had the "users" group in it. --Series8217
Looking into this further, I got the behavior I wanted when viewing pages, but the checkbox is still unchecked. It just doesn't seem to do anything now... --Series8217

ParserCache error[edit]

I am constantly running into an error (with latest svn versions (72275) of MediaWiki an FlaggedRevs):

PHP Fatal error:  Call to undefined method User::usedOptions() in /var/www/mediawiki/includes/parser/ParserCache.php on line 176, referer: http:// [...] /mediawiki/index.php?title=Spezial:Anmelden&returnto=Test3

I am not absolutely sure how to reproduce the error, but it seems only to happen when a user is logged in and marks the page as sighted. After that, the page is broken for every (logged in) user. I tried to track down the responsible code. The error happens in RevisionReviewForm.php at line 703:

$parserCache->save( $pOutput, $article, $user );

The save-method then calls usedOptions() on the $user-object, but that method is undefined in User.php. I do not fully understand ParserCache - probably $user is not a valid parameter? Any help would be appreciated - I will comment out the code for now.

--Splinter 11:04, 3 September 2010 (UTC)Reply

FlaggedRevs not working under xampp-win32-1.7.2 ?[edit]

After updating my Webserver to xampp-win32-1.7.2 (PHP 5.3.0 (apache2handler) MySQL 5.0.51a - http://www.apachefriends.org/de/xampp-windows.html) Mediawiki 1.15.1 with Flagged Revisions r48774 (empty Wiki) faults with:

'''Warning''':  Parameter 1 to FlaggedRevsHooks::markUnderReview() expected to be a reference, value given in '''C:\wwwroot\Wiki\includes\Hooks.php''' on line '''117'''

Detected bug in an extension! Hook FlaggedRevsHooks::markUnderReview failed to return a value; should return true to continue hook processing or false to abort.

Backtrace:

#0 C:\wwwroot\Wiki\includes\Wiki.php(436): wfRunHooks('MediaWikiPerfor...', Array)
#1 C:\wwwroot\Wiki\includes\Wiki.php(63): MediaWiki->performAction(Object(OutputPage), Object(Article), Object(Title), Object(User), Object(WebRequest))
#2 C:\wwwroot\Wiki\index.php(116): MediaWiki->initialize(Object(Title), Object(Article), Object(OutputPage), Object(User), Object(WebRequest))
#3 {main}

Any help would be greatly appreciated! --RayTRoX 01:51, 13 October 2009 (UTC)Reply

Is it the FlaggedRevs from [1] ? Voice of All 02:18, 14 October 2009 (UTC)Reply
Its the r48774 downloaded with the snapshot function from the Extension page (Download snapshot for MediaWiki 1.15.x) --RayTRoX 20:48, 16 October 2009 (UTC)Reply
Removing the references from the markUnderReview function worked for me and the updated code matches the latest code in SVN. -- NivekNodle 19:12, 25 November 2009 (UTC)Reply
public static function markUnderReview( $output, $article, $title, $user, $request )

» I just updated my Ubuntu Server to 04.10 and I get a very simular error. Would someone be so kind and explain a fix to me? Commenting the markUnderReview function in FlaggedRevs.hooks.php didn't work for me.
>>> I had the same issue, seems there's a lot of issues with PHP 5.3.0, I rolled my PHP back to 5.2.6 (1.6.8 xampp), this corrected the extension errors, I say a lot of errors, when I really mean I couldnt get any to work!!

FlaggedRevs doesn't work for "Talk:" namespace?[edit]

I've added NS_TALK to $wgFlaggedRevsNamespaces in my LocalSettings.php, but it doesn't seem to have any effect. --148.2.224.140 07:22, 15 October 2009 (UTC)Reply

No you can't do that. Aaron 09:35, 15 October 2009 (UTC)Reply
Why is that? Is there a special infrastructure for Talk pages (internally within MediaWiki) or is it just a decision (by FlaggedRevs developers) to disallow it? The use case I'd like to use it for is to have some sort of flagged discussion, e.g. the discussion before a specific version of an article is marked as "quality". --Robert 148.2.224.140 09:12, 16 October 2009 (UTC)Reply

opt out/in?[edit]

For my uses, only some of the pages in the main namespace require reviews. We do not want to force users to have to review a document when it is not required (too much overhead for what we require the wiki for). So it would be nice if there was a magic word or something similar to enable/disable reviewing. From what I can see, there is no such funcionality atm. --Boy.pockets 02:48, 27 October 2009 (UTC)Reply

Review a page programmatically[edit]

Is there any "clean" (ie. expected) way (api, functions, ...) to programmatically review a page ? I have to import a huge quantity of pages that should also be reviewed, and I would like to write a small script (or a special page) that would allow me to review them all.

Edit: To be more clear, is the following code enough to review a page, or is there any additional action needed to have a properly validated page ?

$title = Title::newFromText($titleStr);
$article = new Article(title);
$rev = Revision::newFromTitle( $title );
$flags = null;
FlaggedRevs::autoReviewEdit( $article, $user, $rev->getText(), $rev, $flags, false );
FlaggedRevs::markRevisionPatrolled( $rev );

By advance, thanks for any help :)

--Gizmhail 08:42, 29 October 2009 (UTC)Reply

There is a reviewAllPages.php script in /FlaggedRevs/maintenance. Voice of All 16:11, 11 November 2009 (UTC)Reply
This only seems to make pages "sighted" - if we know we are importing from another data source that is really a "quality" set of data this script does not seem to allow marking pages with the right levels to give a "quality" page indication - any suggestions? (I've tried to figure out what the call in reviewAllPages.inc to FlaggedRevs::autoReviewEdit( $article, $user, $text, $rev, $flags, true ); is doing but I cannot see how the $flags should be set. Thanks --Rob C 09:35, 9 March 2010 (UTC)Reply

new pages vandalization[edit]

Hi! I wonder if there is a way to prevent new pages vandalization. Just like $wgFlaggedRevsAutoReviewNew, but for non-editors users. I mean the first thing a user wants to enter in the new created page to be automatically send to draft and the stable page to look something like "Awaiting approval". What i am trying to do is initiating of RevisionReview() and at ArticleInsertComplete hook approve it so that the next edit to that page will be automatically send to draft. My solution is a little twisted but does not stop the first edit. I'll be grateful for any suggestion. Thanks 4 your time.

Sqlite ?[edit]

Hi,

How to install FlaggedRevs with sqlite ? 92.158.89.96 14:21, 13 November 2009 (UTC)Reply

It's not supported yet. Though the .sql file was just changed today to use sqlite compatible indexing. Aaron 07:54, 1 December 2009 (UTC)Reply


are there any news about this ? 217.8.61.111 09:50, 5 May 2010 (UTC)Reply

Special Rights for Page Author[edit]

Hi

I'd like to set up a Wiki, where the original authors of the pages get mid-level flagrights for their own, but only low-level rights for other pages. Plus there's one user(group) with high-level rights. Is that possible with FlaggedReview? How so? Or may I be able to change the source (slightly) to achive this (i only had a short look at it yet. Maybe someone can point out a good starting point?)

Additionally, it would be great, if pages created by normal authors are automatically set to need a mid-level flag to be displayed (as stable), but pages from "high-level" users need a high-level flag.

Any help is appreciated - thx

Rename 'stable' and 'draft' tabs?[edit]

Is there any way to rename the 'stable' and 'draft' pages to something like 'approved' and 'development'? Thanks! --Gkullberg 15:08, 4 December 2009 (UTC)Reply

You can edit 'MediaWiki:revreview-current' to say something other than draft. The other message was removed in recent versions (e.g. "stable" is now the name of the original page tab, such as "article"/"image"/"category"...). Aaron 07:58, 5 December 2009 (UTC)Reply

1176 : Key 'PRIMARY' doesn't exist in table 'flaggedrevs'[edit]

After following the setup, I can't save any text and there is this error :

1176 : Key 'PRIMARY' doesn't exist in table 'flaggedrevs'
Sounds like you are using a developmental version. Be sure to use the "snapshot link" to download a supported version, like 1.15. Aaron 16:41, 7 December 2009 (UTC)Reply

How to make newest templates always show up?[edit]

I know the expected behavior is: "These revisions will remain the same even if included templates are changed or images are overwritten." But, I'd like to always show the newest templates and images, even on pages that haven't been reviewed yet. This could reduce tedium approving pages manually just to push through template/image updates, such as navboxes and other widely-used stuff. How can I change FlaggedRevs to behave like this? Thanks in advance. --Torley 16:08, 7 December 2009 (UTC)Reply

It helps to make images and templates reviewable. Since reviewing them "cascades" to everything that uses it (pages use the latest stable template/file version). Aaron 13:14, 11 December 2009 (UTC)Reply
I just tested this and it works as expected. Thank you VERY much, Aaron! --Torley 19:44, 29 December 2009 (UTC)Reply

Weird Errors with $wgLanguageCode[edit]

Currently I have $wgLanguageCode = 'es' in my localsettings. According to Manual:$wgLanguageCode it should be 'Es', because that's the name of the language file. Error 1.

I'm running flaggededs perfectly fine, except that some messages are in the spanish and others in english. When you click the -/+ symbol next to the EYE on the top right, the message in English. The link next to it, though, links to the right page in Spanish. All of this goes to English exclusivelly when I change 'es' for 'Es'.

Any ideas on this? Perhaps is a bug...perhaps I'm a dumbass :( --Mark 02:11, 11 December 2009 (UTC)

misspelling[edit]

Can someone please correct the spelling of "receive" from the incorrect "recieve" three times on the extension page? thank you 96.250.77.160 07:27, 20 December 2009 (UTC)Reply

Review without edit right[edit]

Is there a way to let users without edit right review an article? (I already know how to make the form show up, but submiting the review doesn't work) Sidcom 22:22, 20 December 2009 (UTC)Reply

There is no way other that changing some code. Aaron 02:47, 30 December 2009 (UTC)Reply
Mkay, i did that. But i think, this should be checked on again, because you establish the "review" right, which should be the decisive one. You should use the same check for wether or not the form is shown and wether or not the review is saved. As it is, users with review but no edit right get to see a seemingly functional form, but the data is not saved (and there is no error msg). As it is, such a rights setup may not seem necessary or useful, but once you use different extensions, this can mess things up. The fact, that you also need edit rights should at least be lined out in the user rights section (especially since there is no error msg, so debugging this was a pita ;) ).

FlaggedRevs & DPL[edit]

We currently use DPL to query content from pages within a Namespace. That Namespace has FlaggedRevs turned on. What I'm seeing is that DPL is querying the draft content and not the stable page content. This might be a DPL question, but is there any known way to have DPL query the stable content instead? --Gkullberg 22:32, 22 December 2009 (UTC)Reply

Some versions of DPL may have the stablepages pararm (only/exclude). Aaron 00:38, 27 December 2009 (UTC)Reply
Nice, that's exactly what I was looking for. Thanks Aaron. --Gkullberg 19:27, 4 January 2010 (UTC)Reply

Key 'rev_id' doesn't exist in table 'revision'[edit]

I got the following error while trying to run updateStats.php:

ValidationStatistics...Error in numRows(): Key 'rev_id' doesn't exist in table 'revision' (localhost)
Backtrace:
#0 /srv/www/htdocs/mediawiki/extensions/FlaggedRevs/maintenance/updateStats.inc(185): Database->numRows(false)
#1 /srv/www/htdocs/mediawiki/extensions/FlaggedRevs/maintenance/updateStats.php(13): update_flaggedrevs_stats()
#2 {main}

I´m using MW 1.15, and download the specific version of this extension in the snapshot link. Any ways to solve that?

Setup -FlaggedRevs[edit]

when i am trying to set up the Flagged Rev , 7th step will not execute, it cause the following error

Populating and updating flaggedrevs_promote table ...doing user_id from 1 to 2 Fatal error: Class 'FlaggedRevs' not found in D:\wamp\www\mediawiki-1.13.3\exten sions\FlaggedRevs\maintenance\updateAutoPromote.inc on line 26

help me to install flagged Revs-1.13.x extention in my mediawiki -1.13.3

Issues with Postgresql (FlaggedRevs-MW1.15-r58382)[edit]

I've run into a bunch of problems installing this release with a Postgresql installation.

The maintenance upgrade fails with a number of errors.

  1. The table flaggedpage_pending is not created.
  2. The line in FlaggedRevs.php
 $wgExtNewIndexes[] = array('flaggedrevs', 'key_timestamp', "$base/postgres/patch-fr_img_name.sql" );

should actually be

 $wgExtNewIndexes[] = array('flaggedrevs', 'fr_img_sha1', "$base/postgres/patch-fr_img_name.sql" );

# The timestamp field for fr_img_timestamp is not correctly formatted for Postgresql. This is fixed in FlaggedRevision.php by changing

 $revRow = array(
                'fr_page_id'       => $this->getPage(),
                'fr_rev_id'            => $this->getRevId(),
                'fr_user'              => $this->getUser(),
                'fr_timestamp'     => $dbw->timestamp( $this->getTimestamp() ),
                'fr_comment'       => $this->getComment(),
                'fr_quality'       => $this->getQuality(),
                'fr_tags'              => self::flattenRevisionTags( $this->getTags() ),
                'fr_text'              => '', # not used anymore
                'fr_flags'             => $textFlags,
                'fr_img_name'      => $this->getFileName(),
                'fr_img_timestamp' => $dbw->timestamp( $this->getFileTimestamp() ),   <=== Add call to $dbw->timestamp
                'fr_img_sha1'      => $this->getFileSha1()
                );

There's another bug with an invalid SELECT, but I haven't sorted that out yet.

P.S.

There's a SELECT GROUP BY problem -

 A database error has occurred
 Query: SELECT
          oi_name,
          oi_archive_name,
          oi_size,
          oi_width,
          oi_height,
          oi_metadata,
          oi_bits,
          oi_media_type,
          oi_major_mime,
          oi_minor_mime,
          oi_description,
          oi_user,
          oi_user_text,
          oi_timestamp,
          oi_deleted,
          oi_sha1,
          MAX(fr_quality) AS fr_quality 
          FROM oldimage LEFT JOIN flaggedrevs
          ON ((oi_sha1 = fr_img_sha1 AND oi_timestamp = fr_img_timestamp)) 
          WHERE (oi_name = 'Signup_verify1.png') 
          GROUP BY oi_name,oi_timestamp 
          ORDER BY oi_timestamp DESC LIMIT 50
 Function: LocalFile::getHistory
 Error: 1 ERROR: column "oldimage.oi_archive_name" must appear in the GROUP BY clause or be used in an aggregate function

This is a pretty common problem when you try to use MySQL GROUP BY semantics with Postgresql, which is much stricter.

In strict SQL terms, the above SELECT statement doesn't make sense. I assume you're trying to merge records with identical timestamps and SHA1 values and use the highest quality value. Unfortunately, this statement won't work with Postgresql.

The code comes from FlaggedRevs.hooks.php in the addToFileHistQuery function.

P.P.S.

Here's another timestamp formatting problem in FlaggedRevs.hooks.php

This is what the code should be -

public static function addToFileHistLine( $hist, $file, &$s, &$rowClass ) {
               if( !$file->isVisible() )
                       return true; // Don't bother showing notice for deleted revs
               # Quality level for old versions selected all at once.
               # Commons queries cannot be done all at once...
               if( !$file->isOld() || !$file->isLocal() ) {
                       $dbq = wfGetDB(DB_SLAVE);  <= Move DB connect out of line, then add $dbq->timestamp call below
                       $quality = $dbq->selectField( 'flaggedrevs', 'fr_quality',
                               array( 'fr_img_sha1' => $file->getSha1(), 'fr_img_timestamp' => $dbq->timestamp( $file->getTimestamp() )),
                               __METHOD__ );
               } else {
                       $quality = is_null($file->quality) ? false : $file->quality;
               }
               # If reviewed, class the line
               if( $quality !== false ) {
                       $rowClass = FlaggedRevsXML::getQualityColor( $quality );
               }
               return true;
       }
Some changes were made and backported. Aaron 23:37, 12 January 2010 (UTC)Reply

Unexpected behavior with Tags, namespaces[edit]

I am running a snapshot of the development Mediawiki (phase3-nightly-r60791) and an SVN checkout of FlaggedRevs (Rev 60951) on XAMPP 1.7.3 (Apache 2.2.14, MySQL 5.1.41, PHP 5.3.1). I am trying to enable FlaggedRevs on only 7 custom namespaces of the wiki and set 4 tags (accuracy, depth, tone & readability) but the configuration settings in LocalSettings.php are not being reflected in the site.

The two main problems I am experiencing are:

1. The only page that shows a "Current revision (unreviewed)" is the Main_Page. Given the settings (see below) I would expect only the pages in the custom namespaces to show the FlaggedRevs tag. I've tried setting $wgFlaggedRevsWhitelist = array( 'Main_Page' ); but the FlaggedRevs still show on Main_Page.

2. The number and content of the tags are not reflecting what is in LocalSettings.php. The "tone" tag was on Main_Page in the default installation but now does not show in the FlaggedRevs reviewing display at the bottom of Main_Page.

Here are the FlaggedRevs settings in LocalSettings.php:

$wgGroupPermissions['sysop']['review'] = true; 
$wgGroupPermissions['sysop']['validate'] = true;
$wgGroupPermissions['sysop']['autoreview'] = true;
$wgGroupPermissions['sysop']['unreviewedpages'] = true;

$wgFlaggedRevsNamespaces = array( 100, 110, 120, 130, 140, 150, 170 );

$wgFlaggedRevTags = array('accuracy' => 3, 'depth' => 2, 'tone' => 2, 'readability' => 2 );

$wgFlagRestrictions = array(
  'accuracy' => array( 'review' => 3 ),
  'depth'    => array( 'review' => 3 ),
  'tone'    => array( 'review' => 3 ),
  'readability' => array( 'review => 3 ), 
);

$wgFlaggedRevTabs = true; 
$wgSimpleFlaggedRevsUI; 
$wgFlaggedRevsAutopromote = false;

Any help is greatly appreciated! --208.145.81.105 01:16, 13 January 2010 (UTC)Reply

Make sure your settings appear *after* the include/require line for FlaggedRevs. Aaron 05:37, 13 January 2010 (UTC)Reply
Now we're getting somewhere - thank you! I'm seeing the namespaces showing FlaggedRevs and the tags are showing up correctly.
Most extensions have that "gotcha". It's funny, I was just thinking about that the day before you posted it. Aaron 20:14, 13 January 2010 (UTC)Reply

populateSha1.php[edit]

Executing the script populateSha1.php reports: "Done 0 files in 0.0 seconds" can this be correct? --FarwayK 21:25, 24 January 2010 (UTC)Reply

If you have no images or the script was already ran before, you can get that. I wouldn't worry. Aaron 02:35, 25 January 2010 (UTC)Reply

Now, what if you don't have the file??? using MediaWiki 1.15.3 Josvanreenen 12:20, 22 April 2010 (UTC)Reply

I canot find populateSha1.php either. I just downloaded the extension from Special:ExtensionDistributor/FlaggedRevs and choose 1.15. --Popol0707 10:51, 7 May 2010 (UTC)Reply
Me too.. can't find that file. It's a pity that nobody helps.. --87.123.160.236 12:52, 11 January 2011 (UTC)Reply

Setup instructions[edit]

The Extension:FlaggedRevs#Setup instructions seem to be outdated / incorrect. Shouldn't it be updated, or at least mention the updated version in the the Readme.txt for newer builds? --FarwayK 21:25, 24 January 2010 (UTC)Reply

What about it is outdated? Aaron 23:29, 24 January 2010 (UTC)Reply
Feedback from --Rob C 11:43, 26 January 2010 (UTC)Reply
With MW v1.15.1 the populateSha1.php file is now in /mwdir/maintenance/archives which suggests that it is not a "current" script - should it still be run?
My own answer (that needs checking :-)) - this populateSha1.php script appears to be a run-once upgrade script and populates the img_sha1 field for any existing image files that may already be in a MW installation; I assume that as this script is now archived that a brand new MW install does not need this to be run as img_sha1 gets updated by MW for each image upload? (found refs to img_sha1 in LocalFile.php and LocalRepo.php)
So how about updating to indicated the correct location of populateSha1.php? I know it is a minor thing, but it does not inspire confidence in the documentation and by inference the product to just "let this slide"
I downloaded the FlaggedRevs extension using the download link mentioned in setup section and selected MW 1.15.x as version as advised in Setup section, got FlaggedRevs r48774, this is missing the /mwdir/extensions/FlaggedRevs/client mentioned in Setup section step 3 - is this important? (it seems to be working without so suspect no longer needed - hence Setup text needs to alter?)
Make '/extensionshttp://www.mediawiki.org/w/index.php?title=Extension_talk:FlaggedRevs&action=edit/FlaggedRevs/' readable. The '/client'/ is actually for the newer, trunk (1.16), version. I've just added a mention of that to the instructions. Aaron 22:44, 26 January 2010 (UTC)Reply

The script update.php does not exist. --Popol0707 10:59, 7 May 2010 (UTC)Reply

What version of MW are you using? It's there for 1.15. Jpatokal 01:40, 12 May 2010 (UTC)Reply

Moving pages[edit]

Would it be possible to require moved pages to be flagged before actually being moved? Moving pages is quite invasive action and when performed by a novice should IMHO be checked by a more experienced user. Lampak 09:40, 19 February 2010 (UTC)Reply

Just use $wgGroupPermissions['user']['move'] = false; and $wgGroupPermissions['YOUR EDITOR GROUP']['move'] = true;. Requiring flagging is just weird. Aaron 23:14, 19 February 2010 (UTC)Reply

Place the SimpleUI in the Header line[edit]

How do i get the SimpleUI up into the "firstHead" line? Sidcom 10:29, 5 March 2010 (UTC)Reply

thats's just what I was looking for...
Trying css first. - Arent 13:44, 31 March 2010 (UTC)Reply

API examples are not working[edit]

For example I'm trying to run the example for show unreviewed pages:

  • api.php?action=query&list=unreviewedpages&urnamespace=0&urfilterlevel=0

This returns:

<?xml version="1.0"?>
<api>
  <warnings>
   <query xml:space="preserve">Unrecognized value for parameter 'list': unreviewedpages</query>
 </warnings>
</api>

So I tried adding the parameter &urstart in the following combinations (I know I've got a page in main namespace 0 called "A"):

  • api.php?action=query&list=unreviewedpages&urstart=A&urnamespace=0&urfilterlevel=0
  • api.php?action=query&list=unreviewedpages&urstart="A"&urnamespace=0&urfilterlevel=0
  • api.php?action=query&list=reviewedpages&urstart=&%22A%22&urnamespace=0&urfilterlevel=0
  • api.php?action=query&list=reviewedpages&urstart=&%22&A&%22&urnamespace=0&urfilterlevel=0

I've manually added Wikisysop to editor group as the page Special:UnreviewedPages originally failed unless you are in the editor group and I thought it might be that causing problems. I'm running: MW1.15.1 FlaggedRevs r60856 --Rob C 09:55, 9 March 2010 (UTC)Reply

Fatal error[edit]

Fatal error: Call to a member function getTimestamp() on a non-object in FlaggedArticleView.php on line 240

That shows up on this page: http://www.theopedia.com/BHS

--64.22.206.26 14:05, 16 March 2010 (UTC)Reply

Fixed in r63818. These are very new changes. Aaron 14:54, 16 March 2010 (UTC)Reply

Performance hit with FlaggedRevs enabled[edit]

MediaWiki 1.15.1, PHP 5.2.8, MySQL 5.0.51a-community-log, Flagged Revisions (Version r60856)

I noticed issues with my MW response time (some of which is server) and during investigation I've noticed that flaggedrevs is adding about 1.5 seconds to page load times (rough test using firebug net panel, cache disabled and forcing page re-load; first time with flagged revs and second time with it removed from LocalSettings.php). This is a really useful extension to indicate page status are there any suggestions on what it could be? Is there any location for profiler outputs and test pages to test profiler with to see what MW extensions are doing i.e. standardised performance test pages that I could put in my MW and then compare my profiler output with the developer or Mediawiki/Wikipedia test results? Many thanks --Rob C 16:32, 26 March 2010 (UTC)Reply

Followup comment - tried enabling MediaWiki file cache ($wgUseFileCache = true;$wgFileCacheDirectory = "$IP/cache";) to speed things up and this failed as "list all" and "approved" links in the flagged revs header on the page did not have the correct URL on the cached page (e.g. got this http://localhost/appwiki/index.php?title=Special:Stableversions&page=Main_Page rather than http://iww.intranetserver.com/appwiki/index.php?title=Special:Stableversions&page=Main_Page)--Rob C 13:12, 31 March 2010 (UTC)Reply

How do I show review status on quality page for all users[edit]

If a page has a "draft" then both the draft and the stable version get the icon stating the review status - the stable page shows its a quality revision or whatever with the rankings. However if the page doesn't have a draft - ie the head revision is stable, then the icon isn't displayed. I think its useful to always have the "quality" marking for the quality page, even when there is no draft.

How can we display the revision icon even for stable head revision pages.

Sounds like $wgFlaggedRevsLowProfile = 0; Aaron 19:34, 9 April 2010 (UTC)Reply

How do I track "aged" revisions[edit]

I'd like to be able to track pages that were last reviewed at some time in the past, but which might have gone out of date subsequently. Is there any way to do a report that shows all reviewed pages sorted by oldest "flagged" date first - and ideally starting from items over a year since their last review?

DPL can list all the reviewed items, but I don't believe there is any way to list review dates of the flagged revision, or to restrict the recovered set to just those with an X month old revision date.

Thank you. Hamish

Transclusion of stabilized pages[edit]

Hello. When I'm trying to transclude stabilized page into another, I'm getting in resulting compound page text from newest (not reviewed) transcluded page. But I need to transclude it's reviewed version, not current (draft). Is there ability to do this?

I found similar questions in archive (1, 2), but seems, that this problem has been not resolved yet. — Solon 12:16, 26 April 2010 (UTC)Reply

Hiding Draft Version for logged in users[edit]

I am trying to hide the draft version from a group of logged in users. I was able to find this article Manual:Preventing_access#Showing_only_approved_versions but it didn't tell me what I needed to do. Anyone know what I should do?

Altusnamura

PHP 5.3 compatibility[edit]

Back in revision 50154 (2009-05-03), FlaggedRevs was updated to be compatible with PHP 5.3: diff

However, I just downloaded "A snapshot of version r60856 of the FlaggedRevs extension for MediaWiki 1.15.x", which should date from Jan 2010, and the change above is nowhere in sight -- so FlaggedRevs breaks on PHP 10.3. This is despite the fact that SVN r60855 does contain the change. Downloading the SVN trunk instead fixed this, but that apparently doesn't work with MW 1.15 anymore. What's going on? Jpatokal 06:46, 10 May 2010 (UTC)Reply

To answer my own question, it looks like the REL1_15 branch has not incorporated this particular change. [2] Would be nice to add it in there... Jpatokal 06:49, 10 May 2010 (UTC)Reply
Done in r66648 Aaron 21:40, 26 May 2010 (UTC)Reply
I get errors with the REL1_15 branch r73669 on PHP 5.3 that make it non-functional. I had to remove some &'s from various functions in FlaggedRevs.hooks.php until I stopped getting errors. I created a patch, where can I submit it? Series8217 16:41, 27 September 2010 (UTC)Reply

Regression in later versions preventing page creation in custom namespace[edit]

I don't know where to report bugs in FlaggedRevs but wanted to mention a bug that I have reproduced in r66853 and r66861 where FlaggedRevs is apparently preventing the creation of new pages when the pages are in a custom namespace. I can create pages and subpages but not if they are a page in a custom namespace, e.g. Mycustomnamespace:Mypage. I've rolled back to r66092 which appears to function much more quickly (later revs were lagging for 2-3 seconds) and allows the creation of the page in the custom namespace. Any ideas if this is a known bug and how to fix it?

I can't reproduce that in /trunk and don't have enough info. FR isn't really related to page creation. Aaron 21:39, 26 May 2010 (UTC)Reply
Same for me with /trunk. Back to an older version helped. Down't know where to find release number. WindowsXP, MW 1.16.0, Xampp, PHP 5.3.2--LouisCyphre 11:59, 15 October 2010 (UTC)Reply
What exactly happens? The description above is too vague to approach (if I can't repro). Aaron 18:14, 15 October 2010 (UTC)Reply

Stat[edit]

Is it possible to have a list of pages that fall under some criterias? For example, if I want to work on pages that have been reviewed with a quality of 1, how can I get this list?

For example, in wikipedia they have a current status table for progress and quality assesment. (like in the video game project EN:Wikipedia:WikiProject_Video_games/Assessment#Current_status).

I would be happy to have something even more basic, like a table with the 3 criterias, and one cell for each value. When you click on the number, you have the list of page with this rating (could even work with hidden categories).

It's just an idea to keep track of the progress of pages and to be able to improve the content. --Gdore 18:12, 11 August 2010 (UTC)Reply

For those who find $wgFlaggedRevsWhitelist not working[edit]

I had this problem. The reason was that the array must contain internal MW page names, not human-friendly names. For example it must be

$wgFlaggedRevsWhitelist = array('Main_Page');

instead of

$wgFlaggedRevsWhitelist = array('Main Page');

Specific pages[edit]

Is there a way to only enable FlaggedRevs on specific pages, à la English Wikipedia? —Waterfox 23:50, 1 September 2010 (UTC)Reply

FR_INCLUDES_CURRENT does not seem to work properly[edit]

I have set $wgFlaggedRevsHandleIncludes = FR_INCLUDES_CURRENT; I have listed all templates that didn't have Accurate status and set their status to Accurate manually. Did the same with all files. And still on all approved latest revisions of pages I was getting indication that the page was draft because it was awaiting template/file changes (after clicking on the link there was no information which templates/files exactly were problematic). Only after I changed the setting to default value (FR_INCLUDES_STABLE) the indication started to work correctly.

The best for me would be to set up FlaggedRevs so that it would completely ignore template and file review statuses and based page status on the page itself only. I haven't found any setting for this. Is it possible? 212.182.91.35 08:42, 7 September 2010 (UTC)Reply

What version? I don't think the latest has any problem like that (enwiki uses it atm). Aaron 18:23, 8 September 2010 (UTC)Reply
MW1.16-r69932 (seems to be the latest). Or should I try the trunk (is it safe)? 212.182.91.35 12:07, 13 September 2010 (UTC)Reply

Doesn't work in custom namespaces[edit]

I have FlaggedRevs installed and for the most part things seem to be working correctly. However, the UI does not show up on any of my custom namespaces. Is there a setting or something that I am missing that will allow it to work on the custom namespaces as well?

I am running Mediawiki 1.15 and FlaggedRevs 1.15 as well.

--20.132.68.146 19:17, 22 October 2010 (UTC)Reply

Okay, I figured out the problem. For $wgFlaggedRevsNamespaces I was using the name (i.e. NS_CUSTOM) instead of the number that I had assigned to the namespace (i.e. 102). As soon as I switched that it worked fine. --20.132.68.146 20:25, 22 October 2010 (UTC)Reply

Is it possible to change the picture for validation?[edit]

Hi!

I am a MD at a hospital. We are considering using mediawiki with the FlaggedRevs for our premomorias. For that to work it would be good to have bigger flags for valid articles (If possible a small banner stating if the article is validated or not rather than the small symbol used on most pages with FlaggedRevs). Is that possible? We want it to be easy to see if an article is validated (and therefore approved for use by our senior doctors) or not (and therefore to be considered just suggestions). Is that possible to configure?

Paul Pålsson, Sweden

Anonymous edits patrolling[edit]

Can FlaggedRevs be used for this? --AS 13:45, 29 October 2010 (UTC)Reply

The question is too vague (is it referring to Manual:$wgUseRCPatrol where all non-"anon" edits are auto-patrolled or something?). Aaron 01:55, 1 November 2010 (UTC)Reply
Yes. Is there any wiki, which uses this mechanism (wgUseRCPatrol)? --AS 22:16, 1 November 2010 (UTC)Reply
Just enable $wgUseRCPatrol and set $wgGroupPermissions['user']['autopatrol'] = true. Note that 'user' means logged-in and '*' means anon. Aaron 00:20, 3 November 2010 (UTC)Reply

Best Practice for Per-Category Reviewing[edit]

In the wiki we're setting up, we will have different teams working on different parts of the wiki. Ideally reviewers should be assigned to only certain parts of the wiki. What is the best way to do this? By defining different Namespaces which have a certain set of reviewers or by defining categories where a set of reviewers can review anything in that Category or one of its sub-categories?

I see that this topic has been discussed before here, here, here, and here. But does anyone have a solution?

Thanks a lot! --Acaldwell 10:04, 4 November 2010 (UTC)Reply

There is no technical way to do the later. Aaron 22:04, 7 November 2010 (UTC)Reply
OK, thanks for the info.--Acaldwell 10:56, 23 November 2010 (UTC)Reply

Simple UI Icons not appearing[edit]

I have FlaggedRevs working on my wiki, but I can't get the review status icons to show up in the top right hand corner of each page. It's not very clear on the Extension page, but I beleive this is turned on by setting $wgSimpleFlaggedRevsUI to true. I tried this, but unfortunatly it didn't work. Is there anything else I need to do? Here are the settings in my LocalSettings.php:

#FlaggedRevs
include_once('extensions/FlaggedRevs/FlaggedRevs.php');
# Define which namespaces fllagedrevs applies to (use int)
$wgFlaggedRevsNamspaces =array("0", "", "", "");

# Define how Tags are applied
$wgFlaggedRevTags = array(
        'accuracy' => array( 'levels' => 1, 'quality' => 1, 'pristine' => 1 ),
);
# Show 'Draft' tab at top if applicable
$wgFlaggedRevTabs = true;
#Show a simpler icon bsaed UI
$wgSimpleFlaggedRevsUI = true;
# Do not hide reviewing options:
$wgFlaggedRevsLowProfile = false;
#Who flagged revs is visible for:
$wgFlaggedRevsVisible = array('reviewer','editor','bureaucrat','administrator');
# Pages exempt from reviewing
$wgFlaggedRevsWhitelist = array();
#By defauls show users the reviewed version:
$wgFlaggedRevsExceptions = array();

$wgReviewChangesAfterEdit[edit]

The documentation mentions $wgReviewChangesAfterEdit, but neither in the 1.16 nor in the trunk version I find this symbol. Is there a new way to configure that a member of the editor group can edit pages without being forced to review his edit immediately?— Preceding unsigned comment added by 95.89.140.3 (talkcontribs) 11:31, 17 December 2010

That shouldn't happen much if the group has the 'autoreview' right, but it still comes up if they edit a page with pre-existing pending changes. Aaron 22:01, 12 February 2011 (UTC)Reply

Category Restriction[edit]

Is there a way to restrict the functionality of this extension so that it is only applied to certain categories? Thanks --Enterprise user 19:49, 7 January 2011 (UTC)Reply

Not at this time (probably not anytime soon). Aaron 21:59, 12 February 2011 (UTC)Reply

PHP Fatal error[edit]

After executing the update.php maintenance script, I am greeted by the following error:

PHP Fatal error: Argument 1 passed to FlaggedRevsHooks::addSchemaUpdates() must be an object of class DatabaseUpdater in /var/www/wiki/extensions/FlaggedRevs/FlaggedRevs.hooks.php on line 2000

Is there an existing resolution to this? --Enterprise user 20:37, 7 January 2011 (UTC)Reply

Resolved; reverted to the stable REL1_16_0 version of the extension. Not sure what was causing this problem in the trunk version. --Enterprise user 22:00, 7 January 2011 (UTC)Reply

A complete test suite for a translation[edit]

I completed the translation of FlaggedRevs into Hebrew and i would like to check that my translation actually makes sense in context.

It is already installed on he.wikisource and the admins there agree that i'll play with it and gave me reviewer rights.

My question is: Is there a proper manual test suite for FlaggedRevs, which guides the tester through all the possible permutations of revision levels and relevant messages? This must be manual, because the translation uses many PLURAL tricks and there are many messages that are similar except small wording changes, but all of them must be read by a human who knows the language. --Amir E. Aharoni 15:58, 8 January 2011 (UTC)Reply

Not at this time. The qqq entry in the language files would help a lot if it complete. Aaron 18:08, 12 February 2011 (UTC)Reply

Possible to implement review comment to "View history"-area?[edit]

Would it be (easy) possible to implement the review comment to the "View history"-area additional to the review log? It would avoid two more clicks. --Frieda99 10:20, 20 January 2011 (UTC)Reply

I found a field called "fr_comment" at the table flaggedrevs and filled it manually, because all fields were empty, but it didn't appear anywhere in the mediawiki. --Frieda99 14:52, 20 January 2011 (UTC)Reply

That shows below the page content when viewed, and only if "$wgFlaggedRevsComments = true". It doesn't go in the history (which is cluttered enough). Aaron 06:04, 1 February 2011 (UTC)Reply

How to display the last editor and reviewer of each page[edit]

Hi. I'm running Mediawiki-1.16 on an internal company website with the corresponding version of FlaggedRevs. My company's web-policy requires that every internal web-page display the author and the approving official. I know that this information (the who edited and when) can be found in the history of an article as well the "who reviewed it" info too for a mediawiki using Flagged revisions, but I was wondering what the strategy would be to modify a mediawiki skin so that the skin can access that information and display it somewhere on every page. Currently, I know the skin has access to really high-level stuff like the article title, article id number, namespace, etc... could someone describe how a skin might be able to extract the last editor and reviewer data (who and when) to be shown as general page info for every page? Thanks! --Rkevans 05:12, 1 February 2011 (UTC)Reply

check vs. review[edit]

I am reviewing the translation of this extension into Hebrew and i have ran into the following problem: there are many messages that say "review" and many others that say "check" - "reviewed pages" vs. "checked pages". Is there any difference between the two terms? --Amir E. Aharoni 07:21, 7 February 2011 (UTC)Reply

"review" is the process of looking over a revision and then flagging (as checked or quality or what not) or reverting it. A "checked" page or revision is one that someone looked over and thought was OK. A "quality" page or revision that meets a strictly higher standard. Aaron 21:58, 12 February 2011 (UTC)Reply

Wrong command[edit]

Article says:

Run time updateStats.php to see how long the script takes to run

I guess time updateStats.php should become time php updateStats.php. --83.7.198.211 11:10, 27 February 2011 (UTC)Reply

Fixed. Aaron 08:56, 18 March 2011 (UTC)Reply