Extension:FlaggedRevs

Article validation allows for Editor and Reviewer users to rate articles and set those revisions as the default revision to show upon normal page view. Readers can also give feedback. These revisions will remain the same even if included templates are changed or images are overwritten. This allows for MediaWiki to act more as a Content Management System (CMS).

Setup

Download the latest snapshot and extract it to your extensions directory.
Upgrade to MediaWiki 1.13 (use 1.13 flaggedrevs) or 1.14a (use current flaggedrevs)
Run maintenance/archives/populateSha1.php.
Make sure '../extensions/FlaggedRevs' is readable (for CSS/JS)
To enable reader feedback, make sure PHP has the GD libraries installed. In windows, this is done by un-commenting them out in php.ini. In linux, php should be compiled with it enabled ('--with-gd'). See a nice guide here.
To enable article validation statistics, run FlaggedRevs/maintenance/updateStats.php once. This may be unnecessary depending on the web user's rights.
Add the following line to LocalSettings.php:

include_once('extensions/FlaggedRevs/FlaggedRevs.php');

Run maintenance/update.php
Run FlaggedRevs/maintenance/updateAutoPromote.php.

It is important that the sha1 column is populated. This allows for image injection via key rather than the (name,timestamp) pair. In the future, image moves may be supported by MediaWiki, breaking the later method.

Be sure to set the $wgReviewCodes variable as well. It should be an array of 2 string items. Any text will do, though it probably shouldn't be very short (less secure) or very long (waste of resources).

Initially, no user can see the reviewer's widget. To fix this, login as sysop, go to Special:Userrights, promote a user to reviewer/editor, log out, and finally login as the promoted user. You will see the reviewer's widget on the bottom of an editable page.

Configuration

First, make sure there is a bureaucrat or steward account (Stewards can set any arbitrary rights). Bureaucrat accounts, by default, can promote users to Reviewer/Editor status or remove it. Sysop accounts can do the same with Editor status.

FlaggedRevs.php comes with a number of configurable variables. To modify these, it is best if you copy them to LocalSettings.php and change them there:

Basic settings

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

$wgFlaggedRevTags - An associative array with keys corresponding to each flag type and integer values corresponding to the level that makes the flagged attribute considered quality. If each of these are met, the revision will count as "quality" and take precedence over other reviewed revisions. For all reviews, each flag must be rated at least above level 0 ("unapproved").
$wgFlaggedRevValues - How many levels are there to each flag.
- Note: Make sure this is higher than the values in $wgFlaggedRevTags.

For example, for the tag configurations, suppose one wants to have "accuracy", "depth", and "tone" tags, with 3 levels each. The admin also want revisions with at least "accuracy" and "depth" of the 2nd levels to count as "quality". The following settings will do that:

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

Each tag corresponds to a MediaWiki namespace page. For example, the first level of the "accuracy" tag corresponds to the text at MediaWiki:revreview-accuracy-1. This can therefore be customized.

$wgFlaggedRevsOverride - Whether flagged revisions override the default revision or simply give a tag notice to the stable version.
- Note: $wgFlaggedRevsExceptions has no effect if this is set to false.
$wgFlaggedRevsExceptions - Makes users in these groups see the current revision by default.

$wgFlaggedRevsComments - Allow Editors/reviewers to add notes to the bottom of the page.
$wgFlagRestrictions - An array with keys corresponding to each flag type which have values that are arrays of each group and how high it can rate the flags.

User interface

$wgFlaggedRevTabs - Whether to use "stable" and "current" revision tabs.
$wgSimpleFlaggedRevsUI - When enabled, a simpler, icon based UI is used. Does not affect the tags shown in edit mode.

Workflow

$wgReviewChangesAfterEdit - If enabled, Editors will jump to the diff against the last stable version after they make edits, unless it could be auto-reviewed or the page has no stable version.
$wgFlaggedRevsAutoReview - If enabled, every edit by a reviewer user is automatically reviewed upon save. There is no need to hit the "submit review" button. This feature requires that the previous revision was also reviewed. Otherwise, auto review will be disabled.
- Auto review will create a review where accuracy, depth and style are set to 1. In general, such low values will earn the review a "sighted" designation. Remember that "quality" has higher precedence than "sighted". The presence of a "quality" revision will block out a "sighted" revision. If you don't want to be blocked out by a "quality" revision, you can redefine the meaning of quality. $wgFlaggedRevTags = array( 'accuracy'=>1, 'depth'=>1, 'style'=>1 );
- Note: Changes in templates and images are auto-reviewed (per-page). This could possibly cause bad versions to be reviewed. Users should be encouraged to use preview or review the page after saving. You may want to set $wgNamespaceProtection[NS_IMAGE] and $wgNamespaceProtection[NS_TEMPLATE] as array('editor') or array('autoconfirmed');
$wgFlaggedRevsAutoReviewNew - Whether to automatically review new pages by editors to the basic minimal level.

Automatic user promotion

$wgFlaggedRevsAutopromote - An array with keys for days, edits, time spacing, benchmarks, emailconfirmed, recent content page edits, total content edits, content pages edited, edit summaries used, IP uniqueness, and userpage existence as keys. The values correspond to how many days/edits are needed for a user account to be autopromoted to Editor status and whether they must be emailconfirmed and have a user page do so. The user must have at least X edits that are Y or more days apart, where X is the number of benchmarks and Y is the time spacing. Set this variable to false to disable this entirely.
- Note: If a user has their Editor rights removed, they will not automatically be re-granted (the editor status log is checked for revocations).
- Note: Some of these counts are not retroactive, so you may notice a delay in promotions.

For example, for $wgFlaggedRevsAutopromote, one might have:

$wgFlaggedRevsAutopromote['days'] = 60; # days since registration
$wgFlaggedRevsAutopromote['edits'] = 150; # total edit count
$wgFlaggedRevsAutopromote['excludeDeleted'] = true; # exclude deleted edits from 'edits' count above?
$wgFlaggedRevsAutopromote['spacing'] = 3; # spacing of edit intervals
$wgFlaggedRevsAutopromote['benchmarks'] = 15; # how many edit intervals are needed?
$wgFlaggedRevsAutopromote['recentContentEdits'] = 10; # $wgContentNamespaces edits in recent changes
$wgFlaggedRevsAutopromote['totalContentEdits'] = 30; # $wgContentNamespaces edits
$wgFlaggedRevsAutopromote['uniqueContentPages'] = 10; # $wgContentNamespaces unique pages edited
$wgFlaggedRevsAutopromote['editComments'] = 5; # how many edit comments used?
$wgFlaggedRevsAutopromote['email'] = true; # user must be emailconfirmed?
$wgFlaggedRevsAutopromote['userpage'] = true; # user must have a userpage?
$wgFlaggedRevsAutopromote['userpageBytes'] = 100; # if userpage is needed, what is the min size?
$wgFlaggedRevsAutopromote['uniqueIPAddress'] = true; # If $wgPutIPinRC is true, users sharing IPs won't be promoted
$wgFlaggedRevsAutopromote['noSorbsMatches'] = false; # If $wgSorbsUrl is set, do not promote users that match

Reader feedback

To let all users be able to give feedback rating (these don't affect stable versions), add $wgGroupPermissions['*']['feedback'] to localsettings.php.

$wgFlaggedRevsFeedbackTags - An array of tags mapped to their numeric weight. This weight is simply used to determine listings of 'overall' problematic pages. There are lists for each tag at Special:ProblemPages as well as the 'overall' list. If you value, say, "accuracy" more than "completeness", then give it more weight.
$wgFlaggedRevsNamespaces - An array of integers (namespaces, see defines.php) that set what namespaces pages have to be in to be rateable.

Advanced

$wgFlaggedRevsWhitelist - array of prefixed DB form (namespace and title, underscores for spaces) titles that are exempt for reviewing.
$wgUseStableTemplates - When parsing a reviewed revision, if a template to be transcluded has a stable version, use that version. If not present, use the one specified when the reviewed revision was reviewed.
- Note: If enabled, the fr_text column can no longer be used to boost performance, though it will still be populated.
- Note: We may have templates that do not have stable version. Given situational inclusion of templates (such as parser functions that select template X or Y depending), there may also be no revision ID for each template pointed to by the metadata of how the article was when it was reviewed. An example would be an article that selects a template based on time. The template to be selected will change, and the metadata only points to the reviewed revision ID of the old template. In such cases, we can select the current (unreviewed) revision if $wgUseCurrentTemplates is enabled. Otherwise, it will be a blue link to the template.
$wgUseStableImages - (Similar to above)
$wgUseCurrentImages - (Similar to above)

$wgCompressRevisions - If zlib support is present, gzip the fr_text column. This column stores the preprocessed (templates expanded out) text of flagged revisions. This is recommended.
$wgFlaggedRevsExternalStore - Analogous to $wgDefaultExternalStore. If set to false, flaggedrevs will use its own external storage cluster for fr_text. If not, it will fall back to $wgDefaultExternalStore. If that is false too, then the local DB will be used for fr_text.

Site access

If you need per-page or partial page access restrictions, you are advised to install an appropriate content management package. MediaWiki was not written to provide per-page access restrictions, and almost all hacks or patches promising to add them will likely have flaws somewhere, which could lead to exposure of confidential data. We are not responsible for anything being leaked, leading to loss of funds or one's job.
For further details, see Security issues with authorization extensions

$wgFlaggedRevsVisible - For sites that restrict viewing of the wiki, this settings makes the stable version of pages visible to people in certain groups. This variable is an array of user groups. Setting it to array('*') will let all non-users and users always be able to see the stable version of pages. To restrict viewing of your wiki, set $wgGroupPermissions['*']['read'] = false; and $wgGroupPermissions['*']['edit'] = false;.
- Warning: This does not work well with img_auth.php, as non-user viewers will not be able to see images. You will probably just want to leave images up to "security by obscurity".
- Note: This will probably be useless without having $wgFlaggedRevsOverride=true.
- Note: Make sure that $wgWhitelistRead is set properly. You will at least want something like $wgWhitelistRead = array( 'Main Page', 'Special:Search' ). You may also want visible directory or category pages. Otherwise, the wiki will be hard to browse for readers.
- Note: Use $wgFlaggedRevsTalkVisible to allow viewing of all talk pages by these users.
- Note: You will probably want to edit MediaWiki:loginreqpagetext to make it more detailed.

Use

Approving pages

Users with some level of review status will have a small rating form on page view and diffs that lets them review revisions. Each tag must at least meet the minimal level of approval. Users should look at the whole page, included templates and images, before reviewing. The (diff to stable) link is very useful for speeding up this process.

A user cannot review a page he cannot edit. They cannot lower the level of a revision from a level they cannot set. Blocked users cannot do anything.

At Special:Stableversions, you can list out all of the reviewed revisions for a certain page or view reviewed revisions.

Upkeep

At Special:Unreviewedpages, there is a list of pages that have not yet been reviewed, for Editors only. A namespace must be selected and an optional category filter is also present.

At Special:OldReviewedpages, there is a list of pages that have been reviewed, but have edits pending. This is for Editors only. An optional category filter is also present.

Pages that cannot be reviewed can still be patrolled for anti-vandalism purposes by Editors to see what has been checked already.

A list of reviewed pages at the main review levels can be found at Special:Reviewedpages.

Monitoring reader perception

For each reviewable page, there is a "rating" tab/link on the page. This links to Special:RatingHistory, which tracks the reader reviews over time.

Also, at Special:ProblemPages, a list is maintained of pages that have received low ratings by readers.

Logging

All relevant actions are permanently logged, so everything can be tracked and overseen properly.

A log of promotion/demotion of editors and the reasons is kept at Special:Log/userrights.
A log of the approval/unapproval of revisions is kept at Special:Log/review.
A log of changes to the stable versioning configuration to pages is logged at Special:Log/stable.

Also, a new page, Special:QualityOversight shows only flaggings log entries related to quality revisions. This is useful if the main log is too flooded with page "sightings".

Notes

$wgUseRCPatrol is enabled with the extension. Flagged revisions are marked as patrolled. Patrolling and autopatrolling of pages in reviewable namespaces is disabled. Other namespaces can be patrolled by Editors. This will mean that the only way to patrol a reviewable revision to to tag it as approved. The advantage is that patrolled edits will always correlate with a reviewed revision.

Sysops can change whether quality revision have precedence or whether the stable version is shown by default for specific pages. To disable this, add $wgGroupPermissions['sysop']['stablesettings'] = false; to localsettings.php.
External text storage is supported. If you already have external text storage on, then the same is applied for fr_text.
Page links, category, image, template, language, and external links will become the UNION of the current and the stable version.
Users cannot move pages they cannot review.
Autoconfirmed users have their edits to non-reviewable pages autopatrolled by default. To disable this, use $wgGroupPermissions['autoconfirmed']['autopatrolother'] = false;

You can demote Editors either temporarily by blocking them or permanently via Special:Userrights. An extra demotion log item will appear for tracking purposes.

Limitations

Transclusions across wikis are not stabilized
External images (aside from Commons) are not stabilized
Metatemplates that conditionally include other templates may have the condition change between the time a reviewer loaded a page and when they reviewed it. Therefore, there would be no pointers to the revision id for this different template to load from, making it blue linked. You will be notified if this happens during review.
Using parser function variable to determine what templates to include (such as one template for each day) will not work for a stable revision. The revision will show as it was upon the time of review.
Using a global multi-wiki user rights page to demote Editors is not sufficient if auto-promotion is enabled as they will simply be re-promoted!

Uninstalling

Remove the include line from LocalSettings.php
Drop the tables in FlaggedRevs.sql.
Drop the columns 'page_ext_reviewed', 'page_ext_quality', and 'page_ext_stable', and the index 'ext_namespace_reviewed' from the page table (if they exist, only older versions used these)
Run maintenance/refreshLinks.php from the command line to flush out the stable version links

Testing platforms

External links

Quality Assurance in an Open Project – blog.wikimedia.org
Stable Articles and Wiki Spam – blog.wikible.org
Images of Flagged Revisions – Wikimedia Commons
About Flagged Revisions – Meta-Wiki

Licensing

This extension is being used on one or more of Wikimedia's wikis. It means that the extension is stable and works well enough to be used by such high traffic websites. A full list of the extensions installed on a particular wiki is produced by Special:Version on that wiki.

This work is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the license, or (at your option) any later version. This work is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Extension:FlaggedRevs

From MediaWiki.org

Contents

Setup

Configuration

Basic settings

User interface

Workflow

Automatic user promotion

Reader feedback

Advanced

Site access

Use

Approving pages

Upkeep

Monitoring reader perception

Logging

Notes

Limitations

Uninstalling

Testing platforms

External links

Licensing

Views

Personal tools

Site

Download

Search

Support

Development

Communication

Toolbox