Extension talk:FlaggedRevs

From MediaWiki.org

• Extension talk:FlaggedRevs/archive 1
• Extension talk:FlaggedRevs/archive 2

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

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:

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

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

Is it the FlaggedRevs from [1] ? Voice of All 02:18, 14 October 2009 (UTC)

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)

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)

public static function markUnderReview( $output, $article, $title, $user, $request )

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

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)

No you can't do that. Aaron 09:35, 15 October 2009 (UTC)

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)

[edit] opt out/in?

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)

[edit] Review a page programmatically

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)

There is a reviewAllPages.php script in /FlaggedRevs/maintenance. Voice of All 16:11, 11 November 2009 (UTC)

[edit] new pages vandalization

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.

[edit] Sqlite ?

Hi,

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

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)

[edit] Special Rights for Page Author

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

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

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)

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)

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

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)

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

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)

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)

I just tested this and it works as expected. Thank you VERY much, Aaron! --Torley 19:44, 29 December 2009 (UTC)

[edit] Weird Errors with $wgLanguageCode

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)

[edit] misspelling

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)

[edit] Review without edit right

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)

There is no way other that changing some code. Aaron 02:47, 30 December 2009 (UTC)

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

[edit] FlaggedRevs & DPL

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)

Some versions of DPL may have the stablepages pararm (only/exclude). Aaron 00:38, 27 December 2009 (UTC)

Nice, that's exactly what I was looking for. Thanks Aaron. --Gkullberg 19:27, 4 January 2010 (UTC)

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

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?

[edit] Setup -FlaggedRevs

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

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

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" );

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

[edit] Unexpected behavior with Tags, namespaces

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)

Make sure your settings appear *after* the include/require line for FlaggedRevs. Aaron 05:37, 13 January 2010 (UTC)

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)

[edit] populateSha1.php

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

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)

[edit] Setup instructions

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)

What about it is outdated? Aaron 23:29, 24 January 2010 (UTC)

Feedback from --Rob C 11:43, 26 January 2010 (UTC)

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)

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 '/extensions/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)