Extension:FlaggedRevs

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

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. Use FlaggedRevs.pg.sql instead if you use PostgreSQL.
 * SVN up to MW 1.11
 * Run maintenance/update.php
 * Run maintenance/archives/populateSha1.php.

Add the  line to LocalSettings.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.

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.

You may want Editors or Reviewers to be able to grant rights to others. For example:
 * - lets editors make more editors.
 * - lets reviewers make more editors.
 * - lets reviewers make more reviewers.

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.


 * - 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 precendece 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 flagged revisions override the current version only for people viewing pages that are not logged in or don't have an account.


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


 * - How long to cache the stable versions.
 * - If zlib support is present, gzip the fr_text column. This column stores the preprocessed (templates expanded out) text of flagged revisions.


 * - 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.
 * - Whether to let edits by people with review rights be autoreviewed 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 autoreviewed. This could possibly cause bad versions to be reviewed. Users should be encouraged to use preview or review the page after saving to make sure nothing is wrong.
 * - 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 they can't 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. 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.



Logging
A log of promotion/demotion of editors and the reasons is kept at Special:Log/validate.

A log of the approval/unapproval of revisions is kept at Special:Log/review.

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.

Uninstalling

 * Remove the include line from LocalSettings.php
 * Drop the tables in FlaggedRevs.sql. Drop the columns 'page_ext_reviewed' 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