Extension:FlaggedRevs

If you are looking for an extension that lets readers rate pages, see Extension:Review or Extension:Rating.

Article validation allows for Editor and Reviewer classes of users to rate articles and set those revisions as the default revision to show upon normal page view. These revisions will remain the same even if included templates are changed or images are overwritten. The text with expanded transclusions is stored in the database. This allows for MediaWiki to act more as a Content Management System (CMS).

Setup

 * Download the extension from SVN
 * Run the FlaggedRevs.sql query, substituting in your wiki's table prefix. For PostgreSQL, use FlaggedRevs.pg.sql instead.
 * Upgrade to MediaWiki 1.12
 * Run maintenance/update.php
 * Run maintenance/archives/populateSha1.php.

Add the following line to LocalSettings.php: include_once('extensions/FlaggedRevs/FlaggedRevs.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. See FlaggedRevs.php for details.

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:


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


 * - An array with keys corresponding to each flag type, with an 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").
 * - How many levels are there to each flag.
 * Make sure this is higher than the values in.


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


 * - Allow Editors/reviewers to add notes to the bottom of the page.
 * - 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.


 * - 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.
 * If enabled, the fr_text column can no longer be used to boost performance, though it will still be populated.
 * 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   is enabled. Otherwise, it will be a blue link to the template.
 * - (Similar to above)
 * - (Similar to above)


 * - If zlib support is present, gzip the fr_text column. This column stores the preprocessed (templates expanded out) text of flagged revisions. As with revision compression in general, this is recommended.


 * - An array with keys for days, edits, time spacing, benchmarks, emailconfirmed, 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.
 * If a user has their Editor rights removed, they will not automatically be re-granted (the editor status log is checked for revocations).


 * - Automatically checks the 'watch' box on the review form if they set "watch pages I edit" as true at Special:Preferences.
 * - 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.
 * - Whether to let edits by people with review rights be auto-reviewed if the change was to the stable revision (e.g. the current and the stable being the same before the edit is made). Does not apply to users that don't have the rights to rate revisions as high as the stable version.
 * Changes in templates and images are auto-reviewed. 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  and   as   or  ;
 * - Whether to automatically review new pages by editors to the basic minimal level.


 * - Whether to use "stable" and "current" revision tabs.
 * - When enabled, a simpler, icon based UI is used. Does not affect the tags shown in edit mode or at Special:Stableversions.

Use
Users with some level of review status will have a small rating form on page view and diffs that lets them review revisions. A user cannot review a page he cannot edit.



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



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. Clicking the checkbox will show pages that need to be re-reviewed, rather than ones that never were reviewed.



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.



Logging

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

Limitations

 * Transclusions across wikis are not stabilized
 * External images 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.
 * Run maintenance/refreshLinks.php from the command line to flush out the stable version links

Licensing
© GPL, Aaron Schulz, Joerg Baach, 2007