Extension talk:Rating

Problem in using the extension
Hi, When I use the extension, i get the following error Warning: Cannot modify header information - headers already sent by (output started at C:\xampp\htdocs\mediawiki\extensions\Ratings\Ratings.php:389) in C:\xampp\htdocs\mediawiki\includes\WebResponse.php on line 10

Is this a bug with Version 1.1.1 ? --Harshalm 06:49, 25 October 2007 (UTC)
 * Can you use the older versions of this extension successfully? The repository for older version is here. On the other hand, I have checked line 389 of Ratings.php and did not spot any errors right away. It would be helpful if you can send me your apache error_log or the full php error text. --Sanford.poon 03:29, 26 October 2007 (UTC)

Extension Installation Issue (FIXED)
This extension doesn't work, or the instructions are bad ?
 * Hello I am the author of this extension, what exactly was the problem you encountered? What's your MediaWiki version? Did you sign up for a key at ReCaptcha.org? Did you initialize the database by adding the tables? --Sanford.poon 03:53, 28 August 2007 (UTC)

The vision is 1.9.3.I didn't sign up for a key at recaptcha.org. when I finished all steps,my wiki couldn't work at all. it printed as:parse error syntax error unexpected T_REQUIRE_ONCE iN.....
 * I have fixed a small bug in installation without recaptcha and repacked the extension in gzipped tar. Please download version 1.0.1 from here and try again. I have set up also a version 1.9.3 test platform in here (version) --Sanford.poon 02:29, 1 September 2007 (UTC)

Performance Problem (FIXED)
echo "\n";

$sql = 'insert into poll_message (poll_id,poll_user,poll_msg) select poll_info.poll_id,\' AUTO \',\'DEL\' from poll_info, (select poll_title,min(poll_date),max(poll_date) poll_datemaxi	from poll_info       group by poll_title) title where poll_info.poll_title = title.poll_title and TIME_TO_SEC(title.poll_datemaxi)-TIME_TO_SEC(poll_info.poll_date)>2'; $result = mysql_query($sql); $err = $err.mysql_error; echo "\n";

This part of code slow down the proccess dramatically when number of ratings increases. For 3000 polls this takes 10 and more seconds.


 * This is the PURIFY code from Eric David's Poll extension. I do not see a reason to keep it. As a workaround I suggest changing the line

if ($total == 0 || $lines[1] == "PURIFY") // Purify the poll_info table
 * to

if ($lines[1] == "PURIFY") // Purify the poll_info table
 * while I completely rewrite the statistics (poll_info) part of the extension. I will release a new version 1.0.2.2 later today with this workaround.
 * --Sanford.poon 06:40, 20 September 2007 (UTC)

AJAX
The comment paging should probably support ajax (there are ajax functions in MW core) to cut down on I/O transfer. Aaron 14:02, 11 October 2007 (UTC)
 * Thanks for the pointer, that will go into my todo list. --Sanford.poon 08:23, 15 October 2007 (UTC)

Data base schema
The extension uses three new tables to be added to the wiki's data base:

ratings_info, ratings_message and ratings_vote.

For table ratings_vote the primary key has been defined as a combination of the "poll id" (a MD5 hash of the contents which is in between the ... tags) and the user's IP address. Why is the user's IP involved there?

We want to achieve that per poll there is one vote per user. I would not save the user's IP at all because in a public wiki most of the users have dynamic IP adresses and in a intranet wiki one user might have several workstations.

What do you think? I like to change the data base schema in that way that only the user name is saved (no IP).

--Sternenfaenger 16:00, 23 October 2007 (UTC)


 * That's a really difficult design question you have asked. The current design, as inherited from the Poll extension, checks for both the user's IP and username when receiving a vote. It will remove the user's (found by having either IP or username match) previous vote before inserting a new one. The problem is exactly what you have suggested: two different users with the same IP cannot vote more than once. While this design has its own merit, I agree with you that the key for the ratings_vote table should not be involved with the IP, it should be keyed based on poll_id and vote time instead. On the other hand I have been thinking of implementing other vote restrictions that are customizable through parameters, including: no restriction, one vote per user based on IP and/or user and time-based restriction (one vote daily etc). Please share with me what you think about this! Thanks a lot. --Sanford.poon 04:06, 26 October 2007 (UTC)