Extension talk:FlaggedRevs/archive 3

See Extension talk:FlaggedRevs/archive 1

patrolling
"$wgUseRCPatrol is enabled with the extension. Flagged revisions are marked as patrolled. Sysop patrolling and autopatrolling is disabled. This will mean that the only way to patrol a revision to to tag it as stable. If you have any custom groups with patrol rights, you may want to give them editor rights instead. The advantage is that patrolled edits will always correlate with a reviewed revision."

This is unclear (or perhaps I'm dense). So full diff patrolling is turned on, but then replaced by flaggedrevs? What happens for wikis with only patrolling of new pages? The cited advantage of using stable versions instead of patrolling is not really an advantage, as we do not want patrolled pages to necessarily be reviewed. Sighted, perhaps, but only if sighted versions are not shown be default (users should see the most recent revision, or something higher than sighted). OTOH, maybe I'm misunderstanding how patrolling and flaggedrevs interact here. Mike.lifeguard 20:45, 21 March 2008 (UTC)

Special:QualityOversight:

Fatal error: Class 'LogEventsList' not found in ...\extensions\FlaggedRevs\FlaggedRevsPage.php on line 1461

--193.175.73.207 18:34, 17 April 2008 (UTC)
 * Please use a new version of MW (revision # given on extension page). Aaron 22:44, 17 April 2008 (UTC)


 * Thank you, that did it. However, Special:StablePages delivers now an empty list for me, although I have several pages marked as stable, UnreviewedPages and QualityOversight seem to work. I am using a two point rating system ([unmarked,] sighted, reviewed), configured with

$wgFlaggedRevTags = array( 'accuracy'=>2 ); $wgFlaggedRevValues = 2; $wgFlaggedRevPristine = 2;
 * Any ideas what might be wrong?


 * Btw, thank you for this great extension, it's exactly what I needed!!! --92.195.50.177 13:56, 20 April 2008 (UTC)
 * "StablePages" is for pages where the settings were changed by admins. They are not ordinary pages with stable versions. Also, note that QualityOversight is not retroactive though. The way the logs are stored was changed slightly in order to make it. Aaron 15:54, 20 April 2008 (UTC)


 * I found out why I was missing my reviewedpages -list: the german translation uses 'Markierte Seiten' for both 'reviewedpages' and 'stablepages', thereby displaying only the first one in the special pages listing. I changed 'stablepages' to 'Manuell markierte Seiten' and now everything works as before. --92.195.29.162 15:58, 21 April 2008 (UTC)

$wgUseStableTemplates
I think I have configured things as intended but have a situation that seems to break the logic. If I use a template to translude the contents of another page (the sub page) into a page (the master page) and both are set for reviewing things seem to get confused in the list of previous versions for the master page

I create the masterpage and the sub page, and transclude the sub page in the master page, I've set $wgUseStableTemplates true so that when I review the master page I get the approved version of the sub page. The system is set so the non logged in people see the stable version

Basically if any entry from the list of previously approved versions of the master page is selected, it shows the currently approved version of the sub page rather than the version of the subpage approved at the time when the master page was approved, which is logically what I'd want, ie what did the master page look like when it was approved on that date.

Tarlachmoorhouse 14:10, 23 April 2008 (UTC)
 * You don't want that setting then. It is for approving templates and having that trickle down to pages, rather than approving pages, and then having that trickle down to all other pages that use the templates. Aaron 14:40, 23 April 2008 (UTC)


 * OK so the $wgUseStableTemplates works so that even if I am viewing a 'reviewed' page, an included template in that page will be updated to a later stable version of the template, e.g if I'm using the template to display a site message, if I change the site message all the pages containing it get updated to the later message including all the reviewed on and any in the historical list


 * I've tried switching it off but now when I go to the master page to review it, because I am in the Editors Group (which sees & edits unapproved pages) the master page contains the latest version of the subpage, irrespective of whether it is approved or not and when I approve the master page this unapproved text appears, rather than the approved version of the sub page. what I in effect need is a way to say when looking at a page that transcludes text from another page that has an approval, only show the approved text on that page, but once that master page has been approved it shoudl ignore changes to the subpage approved or otherwise.


 * To put this in context we are using the system to contain Policy & Procedure Documents and use transcuded pages to allow granularity and for a sub section of one policy to appear in other policy eg. 'paying an invoice' is held once but may appear as an inclusion in a number of different master pages, if the finance department is working a newer version of the 'paying an invoice' page, then if the transport department want to approve a process that includes 'paying an invoice' we need the current approved one not the part completed new version finance are working on. I don't have a problem with making transport 're-approve' their pages to include the new version of the 'paying an invoice' once finance release it, (this is good change management) we can use 'what links here' to pages that transclude the subpage


 * thanks Tarlachmoorhouse 07:47, 24 April 2008 (UTC)

Magic word to exclude a specific page from being reviewed
is it possible to have a magic word such as __NOREVIEW__ which when inserted into a page would stop the review widgit and the review status top bar from appearing on that page.

Tarlachmoorhouse 10:03, 2 May 2008 (UTC)

PHP fatal error bugs
I'm using Mediawiki 1.12.0 and FlaggedRevs 1.04 and I'm getting the following fatal errors:
 * PHP Fatal error: Call to undefined method OutputPage::appendSubtitle in /var/www/ /website/extensions/FlaggedRevs/FlaggedArticle.php on line 92
 * PHP Fatal error: Class 'LogEventsList' not found in /var/www/ /website/extensions/FlaggedRevs/FlaggedRevsPage.php on line 1638, referer: http:// /index.php/Special:Specialpages

Why are you targeting at the beta MediaWiki instead of the stable version? I'ts not a better idea to target the stable version and add new feature only once the next stable version is released? Nicolaasuni 10:29, 8 May 2008 (UTC)

CSS Errors
CSS files contains some errors, please use W3C CSS validator before publishing (i.e. "no-wrap" must be "nowrap"). Nicolaasuni 10:29, 8 May 2008 (UTC)