Extension talk:FlaggedRevs/archive 3

See Extension talk:FlaggedRevs/archive 1

Problems enabling reader feedback
I don't see the User Feedback Box on my Articles (Wiki version 1.13alpha) though i did all the following:
 * 1) chmod -R 775 extensions/FlaggedRevs
 * 2) Run maintenance/update.php
 * 3) Run maintenance/archives/populateSha1.php. (Got error "PHP Notice:  Undefined index:  HTTP_USER_AGENT in extensions/FCKeditor/fckeditor/fckeditor_php5.php on line 37" but i don't think this could have do to something with this problem.)
 * 4) Run flaggedrevs/maintenance/updateAutoPromote.php.
 * 5) GD lib installed and working
 * 6) I don't know if i needed to "run FlaggedRevs/maintenance/updateStats.php". I didn't do, because i couldn't find it. Where is it / should it be? "locate updateStats.php" didn't show it. Must i run it to enable feedback?
 * 7) "include_once('extensions/FlaggedRevs/FlaggedRevs.php');" added to my LocalSettings
 * 8) $wgReviewCodes set
 * 9) "$wgGroupPermissions['*']['feedback'];" added to localsettings.php (by the way, perhaps you want to add the ";" behind "add $wgGroupPermissions['*']['feedback']; to localsettings.php." in the extension article. I missed it and got the blank wiki website after refreshing my browser)
 * 10) $wgFlaggedRevsFeedbackTags kept on the defaults ( $wgFlaggedRevsFeedbackTags = array( 'reliability' => 3, 'completeness' => 2, 'npov' => 2, 'presentation' => 1 );  )

There's also no "rating" tab/link on any page ("stable" or "not sighted") as mentioned below "Monitoring reader perception".

The $wgFlaggedRevsComments option seems to work. But as i need to give all normal users the option to leave their opinion and not to sight/review pages, this seems not to by a possible alternative. Or can i modify the user's rights to allow access to the comment function but not to sighting and reviewing?

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)
 * This is a new extension. For a version for 1.12, you can go here Aaron 00:55, 9 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)
 * This was fixed recently. Aaron 00:58, 9 May 2008 (UTC)

Enabling this extension at a Wikimedia wiki?
Some time ago there was an announcement that this extension was working on de.wikipedia, and that other individual wiki projects could request it at bugzilla.

At bugzilla, though, I see no evidence that any wiki has recently requested it, nor do I find a "help" page anywhere explaining in simple terms what settings need to be specified for such a request.

So it is currently possible to request enabling this feature for Wikimedia wikis? Is there any available model for how to make such a request correctly?

At he.wikisource.org we have already confirmed our request through a community vote. Are there any other specific features we need to add? Dovi 05:26, 30 May 2008 (UTC)

Is README Obsolete? Missing update.php and populatesha1.php from Snapshot
Hi, I'm trying to add FlaggedRevs to an MW1.12 wiki. I downloaded the snapshot listed for MW1.12 (r31252) and am trying to discern my way past two significant discrepancies in the documentation:

1. The readme instructs the user to run maintenance/update.php. There is no maintenance folder present after unpacking r31252, and I do not find an update.php anywhere in the unzipped folder tree or anything named similarly.

2. The readme instructs the user to run maintenance/archives/PopulateSha1.php. There is no maintenance folder, but there is an archives folder which contains two scripts, patch-expiry-index.sql and patch_fpc-expiry.sql.

I tried downloading the latest snapshot (r36923) but come up against a similar impasse:

1. The readme instructs the user to run maintenance/update.php. There is a maintenance folder present, but it contains three different php files: ReviewAllPages.php, UpdateAutoPromote.php, and UpdateLinks.php. I have no idea whether these supercede an earlier 'update.php' (which is nowhere to be found) or if I have somehow got hold of an incomplete snapshot. If I do not wish to enable Auto Promotion, should I execute just the other two?

2. The readme instructs the user to run maintenance/archives/PopulateSha1.php. There is no such file in the maintenance/archives folder or anywhere else within the unbundled snapshot directory tree. There are five different sql patch scripts within the archives folder.

The online documentation contains the same instructions. I searched the discussion archives for this extension as well as Googling "flaggedrevs populatesha1" without coming up with any helpful clues.

Have I got hold of two bad snapshots? Am I perhaps just being dense? I am not highly experienced at moderating a wiki, nor at system-hosting in general, and I apologize in advance if my questions are ignorant. Apostleverde 21:18, 2 July 2008 (UTC)


 * The "maintenance" directory is in the main mediawiki directory, not flaggedrevs. Aaron 21:56, 2 July 2008 (UTC)


 * Many thanks, Aaron. I was able to deploy (unfortunately I was not able to complete the implementation.  I receive a WSOD as soon as FlaggedRevs is included in LocalSettings.  Commenting out the include, immediately eliminates the WSOD problem.  I have also had the same problem if I try to set a custom logo by adding a $wgLogo= setting to LocalSettings.  I suspect I have an issue with my Apache directory permissions setup and am still researching this.)  Thanks for the quick response to my question.  Apostleverde 18:30, 3 July 2008 (UTC)


 * (Got it working. I was trying to use the latest FlaggedRevs with MW1.12.  Updated to MW1.13.)   Aaron, thanks for the help.  Also, thanks for creating this very useful extension.  This will be invaluable as I'm using MW as an internal CMS at my company.  My compliments!  Apostleverde 15:50, 7 July 2008 (UTC)

Can I Suppress the Review Status Bar for Key Pages (such as Main Page?)
Aaron, again thanks for all of your effort with this. I've implemented it in my company's intrawiki, and one thing I would like to do is suppress at least the review status bar for key pages such as the Main Page. Maybe I've missed this in everything I've read, and if so I apologize. Is there an easy way to do this? Obviously some form of this is implemented in Wikipedia. Regards, Apostleverde 14:46, 8 July 2008 (UTC)
 * Not really. I'll look into it since it seems useful. Aaron 16:44, 8 July 2008 (UTC)
 * Thanks for the consideration, Aaron. How is this done currently within Wikipedia?  Skin hack?  Custom mod of FlaggedRevs.php? Apostleverde 14:59, 9 July 2008 (UTC)
 * Just added $wgFlaggedRevsWhitelist. Aaron 17:29, 9 July 2008 (UTC)

FlaggedRevs and Semantic Media Wiki
When I try to use the vet tab to control what version of a page users see, I get this error:

PHP Catchable fatal error: Argument 1 passed to SMWSQLStore::updateData must be an instance of SMWSemanticData, null given, called in /extensions/SemanticMediaWiki/includes/SMW_Factbox.php on line 307 and defined in /extensions/SemanticMediaWiki/includes/storage/SMW_SQLStore.php on line 771, referer: /wiki/index.php?title=Special:Stabilization&page=Main_Page

Thoughts or suggestions? 192.73.45.37 17:59, 17 July 2008 (UTC)

FlaggedRevs class not found in updateAutoPromote.php
I'm trying to install FlaggedRevs on a MediaWiki installation version 1.13. Both are the latest from SVN as of this post. After I run the SQL code, update.php, and populateSha1.php, I run updateAutoPromote.php as instructed. I get the following error:

Populating and updating flaggedrevs_promote table ...doing user_id from 1 to 3 PHP Fatal error: Class 'FlaggedRevs' not found in /[installdir]/extensions/FlaggedRevs/maintenance/updateAutoPromote.inc on line 26

Any suggestions? Versions: Apache/2.2.0, PHP 5.2.6 (cgi-fcgi), and MySQL 5.0.45-community, memcached 1.2.5. Staeiou 19:52, 23 July 2008 (UTC)


 * Well, I went ahead and installed it in LocalSettings.php even though updateAutoPromote.php did not execute successfully. It worked!  I then went back and ran updateAutoPromote.php and it executed with no errors.  This may be cause for changing the installation procedure if updateAutoPromote.php is not necessary to run before installation.  Staeiou 20:00, 23 July 2008 (UTC)

undefined method OutputPage::addExtensionStyle
Hello everyone, I believe everything went well in the install. (I'm using 1.13.0rc2)

After I've made myself a "Reviewer", I have this error on the main page Fatal error: Call to undefined method OutputPage::addExtensionStyle in \extensions\FlaggedRevs\FlaggedRevs.class.php on line 1168

Any suggestions?
 * Either update trunk to HEAD or use the 1.13 version of flaggedrevs. Aaron 15:22, 12 August 2008 (UTC)

Is there (planned) support for the media wiki API?
I'm looking into using mediawiki in combination with the FlaggedRevs extension, now I would like to do some maintenance on pages and content using the media wiki api.

I've tried editing, and this still works. I would also like to be able to review pages! Is there support for this through the mediawiki API?

Your sincerely, --Carter040 12:01, 17 September 2008 (UTC)

Disable on the Mainpage
Hello. First, excuse my bad english. Anyone can say me, how to disable the FlaggedRevs on the mainpage, categories, etc.? Thanks and greets --212.203.69.70 14:24, 22 September 2008 (UTC)
 * Add the page titles (strings) to $wgFlaggedRevsWhitelist. Like $wgFlaggedRevsWhitelist = array( 'Main_Page' );. Aaron 14:41, 22 September 2008 (UTC)
 * Tanks very much ;) --212.203.69.70 05:43, 23 September 2008 (UTC)

Table not found...?
So, I'm currently running Mediawiki 1.13.1, with PHP 5.2.6, and MySQL 5.0.67 on a Windows machine. I followed all the steps put forward by the Extension page and after adding the include statement to my LocalSettings.php file and restarting my server, I get messages when trying to run the updateAutoPromote.php file.


 * The error message states:
 * MySQL returned error "1146: Table 'wikidb.flaggedpages' doesn't exist (localhost)"

I really don't want to hack the wikidb entry to include a flaggedpages table... but I'd really love to figure out how to get that table properly integrated into my database. Can anyone make any suggestions? --192.223.226.5 20:46, 22 September 2008 (UTC)


 * I was able to play around with running the update.php, updateStats.php, & updateAutoPromote.php files again and again until they all appeared to succeed. Now, however, I get a message telling me that:
 * A database query syntax error has occurred... from within function "FlaggedRevs::getPageVisibilitySettings". MySQL returned error "1054: Unknown column 'fpc_select' in 'field list' (localhost)".
 * Any new thoughts? --192.223.226.5 21:07, 22 September 2008 (UTC)


 * I had the same problems. My solution: using the 1.13.x instead of the Trunk version. After following exactly the README, everything was fine.


 * I had this same problem, so I peeked into the db and found only two of the tables had been added. I then opened up the README and noticed a very important looking instruction to (step 2) * (MySQL) Run the 'FlaggedRevs.sql' query, substituting in your wiki's table prefix.  ...it's an important detail.  After deleting the queries that created the flaggedpages and flaggedrevs_promote tables, everything worked!  CWinDC 05:26, 9 January 2009 (UTC)


 * I had same problem on a fresh install ( Debian etch + Mediawiki-1.13.3 + FlaggedRevs-MW1.13-r39880.tar ) : running FlaggedRevs.sql is required otherwise installation will fail.
 * The instructions page on the website is for the current (1.15a) version, not 1.13. The readme.txt for each package should be used. I just backported (r45951) some changes to the 1.13 version to avoid this confusion. Aaron 06:44, 21 January 2009 (UTC)

Overly Complex?
I feel like the voting process is overly complex. I think it would be ideal to simply have a plus and minus voting buttons that would mean either the edit is an improvement or it is not. After a certain number of individuals vote that the edit is an improvement, it is automatically published. If the edit is voted negatively, it will be removed from the draft after a certain number of vote. Why isn't there an extension to perform this function?

199.106.86.2 00:38, 22 October 2008 (UTC)
 * You can tweak the voting tags to be just up/down (which will make a radio button). It will not set the default though. Aaron 05:02, 22 October 2008 (UTC)

Unclear instruction - $wgReviewCodes
''Be sure to set the $wgReviewCodes variable as well. '' - an example here would be good, as well as an explanation of how this is used or why it is important.

This code comment is also less than comprehensible:


 * 1) Please set these as something different. Any text will do, though it probably
 * 2) shouldn't be very short (less secure) or very long (waste of resources).
 * 3) There must be two codes, and only the first four are checked.

There must be two codes, and only the first four are checked. Er, what? --pfctdayelise 03:50, 17 November 2008 (UTC)
 * Typo; fixed on svn. It's just two. Voice of All 08:11, 17 November 2008 (UTC)

Parser functions
Parser functions that output html code directly (using the isHTML and noparse options) and shouldn't be subsequently parsed, seem to get reparsed when displayed back to a user - which means the html gets rendered as text in the wiki page with &gt and &lt replacing the > and < characters. The output of the parser function is effectively broken from the first time it is viewed as a latest 'sighted' version. :o(
 * Try using $wgUseStableTemplates Voice of All 05:39, 3 December 2008 (UTC)

Is there a way to install the extension without having root access?
It seems quiet unfair to me, that you can comfortably install MediaWiki without having root access, but for an extension you suddenly need more rights. So all my installation was in vain, for I cannot configure MediaWiki to my needs.


 * You don't need root access: You need shell access. If you don't have shell access, you can try running the queries on the database through phpMyAdmin. —Emufarmers(T 01:23, 8 December 2008 (UTC)

"flaggedpages' doesn't exist"
I installed both latest 1.14 and 1.13.2 and followed the "setup" but get error. The tables don't seem to exist. Should I create these manually or did my setup fail? Any help is appreciated.
 * Once flaggedrevs is enabled, running update.php should work. Voice of All 21:57, 8 December 2008 (UTC)

Running update.php failed in updating the SQL tables. However, when I importing these manually everything worked(I am using a windows xampp setup and imported the "FlaggedRevs.sql" via localhost/xampp "phpMyAdmin") --Walfried.veldman 13:31, 9 December 2008 (UTC)


 * I got the same Problems on xampp 1.6.7 using wiki 1.13.3: update.php reports
 * MySQL meldete den Fehler: 1146: Table 'wikidb.flaggedpage_config' does n't exist (localhost). If you import the "FlaggedRevs.sql" via localhost/xampp "phpMyAdmin" don't forget to create a prefix manually in the file.--Guido Hornig 16:42, 21 December 2008 (UTC)

What is FlaggedRevs?
I am sure I am mistaken but it sounded like current articles are going to be preserved as are without further revision except by review. Is that it? A halt on insant changes? RTG 19:27, 2 January 2009 (UTC)


 * Obviously there is some description on the page here but it says "Article validation is..." I was looking for "FlaggedRevs is..." if possible thanks. In fact, of 43 entries of "FlaggedRevs" on the previous page, 41 are parts of filenames or machine code, one is the title, and the other one says "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." I realise it is probably an item of little consequence but it does sound like a block on editing. RTG 19:31, 2 January 2009 (UTC)
 * That setting was removed recently. I've removed the whole 'advanced' section now. The stuff there either no longer applies or doesn't need to be fiddled with. Voice of All 13:44, 3 January 2009 (UTC)

I echo the call for a better description, and I will explain why I can't extract any meaning from the first section, which reads "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." I guess that this has been written by technical people and an introduction for laymen has been overlooked so far. Regards 88.217.143.89 12:41, 23 January 2009 (UTC)
 * The term "FlaggedRevs" is not used at all. One may guess that FlaggedRevs is an extension that allows one to do "Article validation", but perhaps it isn't.
 * The terms "Editor user" and "Reviewer user" are not defined.
 * What does "rating an article mean"? Presumably assigning a number based on whether the article is good or bad? If so, what that has to do with "validation" or "FlaggedRevs"?
 * "those revisions" - which revisions? Same applies to "these revisions". Is there a difference between these and those revisions?
 * what is a "default revision"?
 * what is a "normal page view" - perhaps it is best to explain what an "abnormal page view" might be.

Need a feedback from the devs on a specific flagged rev implementation
I have started a proposal which will make use of flagged revision. I want to get a feedback if this type of implementation is feasible under the current version of this MediaWiki extension or does significant changes needed to be made to this extension to make this proposal feasible on the English Wikipedia. Yamamoto Ichiro 00:04, 7 January 2009 (UTC)

Minor bug?
FlaggedRevs was just implemented at he.wikisource (thank you!) and I think I may have found a small bug, possibly related to the RTL environment.

For pages that have never been reviewed, FlaggedRevs provides an automatic notice telling the reader that this is the "Current version (unreviewed)". In English Wikinews, for instance, this notice appears at the top right of the article (end of the line), e.g.. In English Wikibooks it is centered at the top of the article, e.g..

But at he.wikisource it appears in the top right corner (beginning of the line) and also interferes with centered text in the first line of text. For example:. The centered texts are pushed off-center to the left.

When the first line of text is not centered the notice appears at the beginning of the first line with the text following, e.g..

Is this an overall bug or something that can be corrected locally? What would the best way to correct this? Dovi 19:06, 10 January 2009 (UTC)


 * Hi Dovi, I have corrected this by modifying the CSS. It is still not perfect on pages where the first line is centered, but what you can do is to add an extra empty line in the top of the page. Ori229 18:07, 12 January 2009 (UTC)


 * Thanks Ori. That is good for local improvement at he.wikisource. My guess is that a minor fix in the extension itself is called for here, so that it will work for all pages at all RTL wikis. Dovi 07:49, 13 January 2009 (UTC)

Possible to make automatically show unsighted revisions after one week?
If an edit has not been sighted nor reverted for one week, can the article automatically be temporarily taken off Flagged Revisions, showing the draft version to anonymous visitors until a revision is sighted? --Apoc2400 23:42, 26 January 2009 (UTC)

Wikitext not being parsed
Hello,

I have installed FlaggedRevs on my MW 1.13.3 and everything seems to be working properly with one exception. The banner at the top of each page as well as other messages within the extension are displaying wikitext as though it were not special. For instance I show this at the top of a page: There are no reviewed revisions of this page, so it may not have been checked for quality. Has this been reported yet? Is there a fix?

Thanks, --Tcronin 20:11, 27 January 2009 (UTC)