Jump to content

Extension talk:Rating

Add topic
From mediawiki.org

Problem in using the extension

[edit]

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)Reply

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)Reply

Problem in using the extension

[edit]

Hi,
When I use the extension, i get the following error

Warning: Cannot modify header information - 
headers already sent by (output started at 
C:\AppServ\www\wiki\extensions\Ratings\Ratings.php:403) in 
C:\AppServ\www\wiki\includes\WebResponse.php on line 10

Is this a bug with Version 1.1.1 ?
--windtalkers

Extension Installation Issue (FIXED)

[edit]

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)Reply

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)Reply

Performance Problem (FIXED)

[edit]
echo "<!-- ee ".date("Y-m-d H:i:s")." -->\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 "<!-- ee1 ".date("Y-m-d H:i:s")." -->\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)Reply

AJAX

[edit]

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)Reply

Thanks for the pointer, that will go into my todo list. --Sanford.poon 08:23, 15 October 2007 (UTC)Reply

Data base schema

[edit]

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 <rating>...</rating> 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)Reply

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)Reply


Preview

[edit]

A preview funktion would be great. Especially because it's not possible to edit the comments after posting. --87.176.65.51 19:11, 19 March 2008 (UTC)Reply

Ratings text

[edit]

Where is the text for the comments on the ratings? It doesn't appear on the text pages which seems like it would make it difficult for search engines to pick it up. --PurplePopple 02:21, 12 October 2008 (UTC)Reply

Licens

[edit]

What Licens applies to the released code, so possible modifications and enhancements like graphical stars could be rereleased to public? --Papiertiger 16:26, 5 March 2009 (UTC)Reply

Some bug in MediaWiki 1.6.12

[edit]

I get the following error: Parse error: parse error, unexpected T_VARIABLE in Ratings.php on line 279
which is: $lparse = clone $wgParser;
The weired thing is that if i disable that line and than use some poll made by the poll extension everything comes alive from the ashes (previously the <rating> wasn't even parsed) !!! Can it be fixed? Is it something wrong with some variable that they both use?

Bug parser MediaWiki 1.8+

[edit]

Fatal error: Unsupported operand types in */includes/parser/LinkHolderArray.php on line 33
Solution: /extensions/Ratings/Ratings.php
find

       if (preg_match("/^{<.*>}$/",$compoll_user[$i-1])) {
                $user3 = substr($compoll_user[$i-1],2,strlen($compoll_user[$i-1])-4);
                $lparse = clone $wgParser;
                $output = $lparse->parse( "[[User:$user3|$user3]]", $wgParser->mTitle, $wgParser->mOptions, false, false );
                $compoll_user[$i-1] = $output->getText();
        }

replace to

        if (preg_match("/^{<.*>}$/",$compoll_user[$i-1])) {
                $user3 = substr($compoll_user[$i-1],2,strlen($compoll_user[$i-1])-4);false );
                $output = $wgParser->recursiveTagParse( "[[User:$user3|$user3]]" );
                $compoll_user[$i-1] = $output;
        }

Having done this I get the next error:

Parse error: syntax error, unexpected ')' in ..../extensions/Ratings/Ratings.php on line 278

Anybody can give me a hint at Horst.Salzwedel (at) gmail.com?? Thanks in advance, --Horst Salzwedel 00:33, 18 August 2009 (UTC)Reply

Remove the trailing "false );" from the second line. 217.41.60.242 11:12, 29 January 2010 (UTC)Reply


That was indeed a severe problem that was fixed by the above (+ removing 'false' part):

       if (preg_match("/^{<.*>}$/",$compoll_user[$i-1])) {
               $user3 = substr($compoll_user[$i-1],2,strlen($compoll_user[$i-1])-4);
               $output = $wgParser->recursiveTagParse( "[[User:$user3|$user3]]" );
               $compoll_user[$i-1] = $output;
       }

(I believe it is related to non-sensical input) --195.74.250.81 17:14, 15 May 2010 (UTC)Reply

Ah, it happened e.g. when the user name was "{<>}" (without quotes) [body blank]. --195.74.250.81 17:17, 15 May 2010 (UTC)Reply

Logged in users only?

[edit]

Is there a way to get the Rating extension to only accept input from users that are logged in?

in severe need of a feature

[edit]

a feature that keeps pages able to cache [by accounting on no-change on rating]. --195.74.250.81 15:08, 12 May 2010 (UTC)Reply

[edit]

Is this just temporarily down? This link doesn't work http://dev.openbig.net/index.php/Dev.openbig.net:Ratings

Daviddoria 14:45, 23 June 2010 (UTC)Reply

This is in desperate need of not disabling file caching.

[edit]

This extension forces disabling file caching with $wgParser->disableCache();

It would be best to clear file caching only on the event of voting or messaging with "HTMLFileCache::clearFileCache( $title ); // $title is a Title object" (from IRC).

Of course, to be global, I guess it would need to clear other types of caching too. -Fs 01:13, 2 November 2010 (UTC)Reply