User talk:Patheticcockroach

Hey dude with the funny nickname :) I think your Extension:IM Status is quite interesting, and to give it some more exposure, and to support more i18n, I just added it to the MediaWiki SVN. I also made a few minor patches, most significant I think is delaying the message loading. If you are serious about MediaWiki hacking, I would also recommend that you request commit access to the MediaWiki svn repo, by sending a short mail with a request to brion at wikimedia dot org, accompanied by a public key you can use with your subversion client. Cheers! Siebrand 20:19, 5 October 2008 (UTC)
 * Will do if I find something more to add to the extension ;) Patheticcockroach 07:19, 6 October 2008 (UTC)

Installation difficulties
Hello, I'm new to the wiki stuff and I have problems to install your extension:RatingBar... I followed the install instructions but somehow it still doesn't want to work. The php_error.log is saying:

[09-Apr-2009 12:28:27] PHP Warning: require_once(C:\Inetpub\wwwroot\mediawiki/extensions/RatingBar/ratingbar.php) [function.require-once]: failed to open stream: Permission denied in C:\Inetpub\wwwroot\mediawiki\LocalSettings.php on line 282 [09-Apr-2009 12:28:27] PHP Fatal error: require_once [function.require]: Failed opening required 'C:\Inetpub\wwwroot\mediawiki/extensions/RatingBar/ratingbar.php' (include_path='C:\Inetpub\wwwroot\mediawiki;C:\Inetpub\wwwroot\mediawiki/includes;C:\Inetpub\wwwroot\mediawiki/languages;C:\Inetpub\wwwroot\mediawiki/extensions; C:\Inetpub\wwwroot\me diawiki/extensions/Ratings;.;C:\php5\pear') in C:\Inetpub\wwwroot\mediawiki\LocalSettings.php on line 282

I'm just a noob that needs help ^^ AndiRay 11:11, 9 April 2009 (UTC)
 * Looks like a permission problem. But on Windows (Windows Server I suppose?) I don't really know how to fix this. You need to make sure that all files in extensions/RatingBar/ can be read (and maybe executed too) by the user that runs your HTTP server and PHP. Patheticcockroach 12:26, 9 April 2009 (UTC)


 * Yes, it is a Windows Server... actually I first try new extensions on my laptop (just XP) before adding them to the Server (WinServer2008). I managed to install the Extension ArticleComments but when I try to install any Rating Extension I get the same error. Maybee it has to do with scriptfiles or something else, since ArticleComment ist rather "easy" (Some extensions can conflict with maintenance scripts, for example if they directly access $_SERVER (not recommended). http://www.mediawiki.org/wiki/Manual:Extensions Since alot of people dont seem to have a problem it is obviously my fault :( or everyone uses Linux... In XP you cant do chmod 0777 or whatever. Is there some way to give the LocalSettings.php the permission to access the file?  Thanks for answering so fast AndiRay 12:52, 9 April 2009 (UTC)


 * Sorry, I don't know enough about Windows Server to know how to fix this :( Patheticcockroach 11:32, 17 April 2009 (UTC)


 * I got it running, well kind of... it doesnt notice that I am logged in but I guess it is kind of the same as Jonem's problem I think. I just had to select the Ratingbar folder, rightclick, properties, security and there enable everything (I didn't want to spend my time on finding out what exactly has to get the permission). I read you want to implement stars, that would really rock. AndiRay 13:46, 20 April 2009 (UTC)
 * If that's the same problem as Jonem, setting $site_name to the same value as $wgDBname should fix it. If you don't have a table prefix, the extension has a bug with that (fixed in next version), please post a link to your wiki so I can get your session ID cookie name and tell you how to edit the buggy line. Patheticcockroach 16:55, 20 April 2009 (UTC)


 * I've already tried that but I have no prefix. That means I will have to wait. My wiki is an intranet one for the company I work for... where can I find the session ID cookie? And thx for the support! AndiRay 08:07, 21 April 2009 (UTC)

Extension:RatingBar Error
Hi, First let me thank you for making the RatingBar extension for MediaWiki, it seems like a great extension. Unfortunately I'm experiencing a problem with it after I've followed the instructions and installed it. After I've added the RatingBar code to a page, whenever someone (either logged in or not logged in) clicks on it to submit a rating, the page displays the following error message:

Warning: mysql_fetch_array: supplied argument is not a valid MySQL result resource in /"path to my directory"/extensions/RatingBar/doqueries.php on line 76

The code in Line 76 of the file doqueries.php as referred to in the error message is: if( !$too_many_votes_with_ip && $action_id=="vote" && ( $uid>0 or $unique_check=='ip' or ( $line3 = mysql_fetch_array($query3) ) ))

Do you know what could be causing this error and how it could be fixed?

Thank you very much for your reply and help, I appreciate it. Sincerely, --Jonem 10:21, 17 April 2009 (UTC)
 * The warning when the user is not logged in is caused by a little mistake in the extension code, for this you need to change your PHP configuration (set "display_errors" to Off), until we find a fix. If you can't change your PHP configuration, you can try to replace "mysql_fetch_array($query3)" with "@mysql_fetch_array($query3)". The warning when the user is logged in is probably caused by a problem with your session name, $site_name isn't handled properly by version 1.0-rc1 of the extension. You may want to check this out, or post a link to a page on your wiki with the rating bar so I can figure out your session name cookie. Patheticcockroach 11:32, 17 April 2009 (UTC)

Thank you very much for the fast reply. I tried to replace "mysql_fetch_array($query3)" with "@mysql_fetch_array($query3)", this caused the error message to disappear but also made the voting function to not work (nothing happened when logged in user or not logged in user tried to vote). The strange thing is that even though I'm logged in, the same message as "you must login or register to vote" is displayed. I don't think the error would be caused by an error in the session name, since the name of the site is just one word. Here is a link to a page on my recently installed wiki with the rating bar: http://www.nicer.info/wiki/index.php?title=Testing Thanks once again for your help, I'm very grateful. Sincerely, --Jonem 13:10, 17 April 2009 (UTC)


 * In config.php, I think you should set:

$table_prefix						= 'nic2';		// Copy value from $wgDBprefix $site_name							= 'capiorse'; // Copy value from $wgSitename?? (not sure about this!)
 * These parameters are needed for the extension to be able to compute your session cookie name (which in your case is capiorse_nic2_session). No session cookie name = can't read the session = can't get the user name = the user can't vote ;) Patheticcockroach 14:10, 17 April 2009 (UTC)

Thanks once again for the quick reply and help. When first installing Mediawiki I hadn't set a prefix for the database, I now did a clean install of MediaWiki in order to set a prefix which could be entered for the extension. Unfortunately the solution wasn't that simple and I'm still receiving the same error message as before without the vote being recorded, even though I'm trying to vote as an logged in user. I have made sure that I have entered the prefix (nc_) as specified in the $wgDBprefix setting from LocalSettings.php and the site name (Nicer) the same as $wgSitename setting from LocalSettings.php. When making the SQL query I've also changed the 'wg_ratingbar' to 'nc_ratingbar'. If it would help you to find the error by testing my site, I have a user with the login as: Username: Test Password: test1 The url to a page with the rating bar: http://www.nicer.info/wiki/index.php?title=Testing As far as I understand something is stopping the vote from being recorded in the Mysql database, but more than that is above my understanding :) I'm very thankful for your help as to what could be causing the error. Sincerely, --Jonem 21:32, 17 April 2009 (UTC)
 * Ok, apparently, $site_name shouldn't be the same as $wgSitename... but I don't know what settings it matches then. Basically, your session ID cookie is now called "capiorse_nic2_nc__session". If your prefix is "nc_" then $site_name should be set as "capiorse_nic2", and I'd be very interested to know which LocalSettings parameter this matches. I'm sorry for misinterpreting your previous session ID cookie, I thought you had a prefix because of the underscore, the extension can work without a prefix otherwise (it actually currently has a bug in this case, but it will be working in next version). Patheticcockroach 05:57, 18 April 2009 (UTC)

It worked now, thank you! $site_name matches $wgDBname in Localsettings.php, so $site_name in the config.php of RatingBar extension should have the same value as entered for $wgDBname in Localsettings.php which in my case was capiorse_nic2 exactly as you said. In order to avoid the Mysql error message for not logged in users, I've made changes as you specified before: "mysql_fetch_array($query3)" to "@mysql_fetch_array($query3)" on line 76 of doqueries.php

Also there's two similar error messages for a logged in user, and to get rid of them I've made a similar change as above: ”mysql_fetch_array($query2)” to “@mysql_fetch_array($query2)” on line 131 of doqueries.ph. And: ”mysql_fetch_array($query3)” to “@mysql_fetch_array($query3)” on line 133 of doqueries.php I'm not that experienced in PHP code and I don't know what placing a @ in front of these lines actually does. Could you explain to me what this does? Do you think these changes could cause any performance issues for the RatingBar extension later on? (otherwise, it might be a good idea to add these changes to the installation instructions for the RatingBar extension, or even directly to the code of the download package, so future users of the extension wouldn't have those Mysql errors). And at last a suggestion; in future versions of the RatingBar extension, do you think it would be possible to make a feature where an admin could see how a username or IP adress have voted? (if not possible in the extension already will say ;) Thanks once again for all the help, I'm tremendously grateful! Sincerely, --Jonem 12:40, 18 April 2009 (UTC)
 * Thanks a lot for catching the $site_name<=>$wgDBname match, I'll be able to fix the doc now :) The warnings you are reporting have been dealt with in the current dev version. Placing a @ before calling a function simply disables error reporting for the function, so no performance issue, it's just as if you configured PHP with display_errors=Off ;) It's already possible to see the votes made by a user with , but it's not limited to admin ATM (it's disabled by default, and can be enabled for everyone). We'll improve that later. For the moment, you can use something like phpMyAdmin to see the votes by IP or by user ID if you really need to (not really a comfortable solution, but is usable for occasional use) Patheticcockroach 15:05, 18 April 2009 (UTC)

Thanks once again for a lightning fast reply and all the help. I'm very happy to have been of some help (although minor) of matching the $site_name to the term in the localsettings :) Thanks for explaining what the @ does to the functions and I'm looking forward to the release of the next version currently in dev. I tried the  and it works great, but is it possible to also display the votes made by not logged in users. Will say, votes not only by username but also by IP with a similar copy and paste code as above? (I tried looking for votes in phpMyAdmin and in the nc_ratingbar table, but I didn't quite manage to understand it :) I played around a little with the script and the settings in it's config.php file and I might have encountered a minor bug (or it's something with my own settings again). But when changing the $unique_check on line 48 of config.php to "both", votes made by users not logged in can't be recorded. When a not logged in user votes it just displays "You voted %", without showing how many percent and the vote isn't recorded at all. Strangely enough, votes by logged in users are recorded and works with the option set to "both". Changing the setting to "ip" in config.php, makes it work also for not logged in users, but then a logged in user isn't tied to an IP address by the extension and one person could first vote as a logged in user and then log out and vote again as a not logged in user from the same computer. Having the setting as "ip" also allows one person to create multiple users on the same computer and making multiple votes, which I understand wouldn't be possible with the option "both", since the person then would have to get a new IP address for every username in order to vote from the same computer. Is this the same for you that the option "both" isn't working correctly, or have I managed to mess up the configuration on my part somehow? ;) Thanks once again for all the help, I can't thank you enough! Sincerely, --Jonem 12:12, 19 April 2009 (UTC)
 * The problem with $unique_check is that we implemented it without describing precisely how it should behave at first. The value "user" should mean one vote per registered user I think, and I'm really not sure of what the other values are precisely supposed to do (Franck did this part)... yet what you describe about the "both" behavior not displaying voted % is clearly buggy.
 *  doesn't work with IP yet, it's on the to do list for later :) As for the phpMyAdmin reading, "page_id" is the name of the page for which the vote is recorded, "ip" is the IP of the person who voted, and "rating" is the rating they casted (0 to 100). So a query like "SELECT * FROM 'nc_ratingbar' WHERE 'ip' = '127.0.0.1'" will list all votes by IP 127.0.0.1. Patheticcockroach 14:02, 19 April 2009 (UTC)

Thanks again for the swift reply. By following your explanation I've managed to query the database through phpMyAdmin for all votes of a certain IP, thank you very much. Regarding the minor bug with the "both" settings in the config.php file, do you think I could alert Franck of this by writing on his discussion page? Thanks once again for the help. I've thanked you so many times now that the word "thanks" has nearly become superfluous :) but I'm really grateful for your help, it was a long time since I received such wonderful help. Sincerely, Jonas
 * You're welcome :) To make it up for my buggy software, I try to at least help solve the bugs ;) I e-mailed Franck a link to this thread, so no need to post on his talk page about it Patheticcockroach 16:55, 20 April 2009 (UTC)

Thank you for e-mailing Franck! --Jonem 10:38, 21 April 2009 (UTC)
 * Hi Jonas, thanks for reporting this bug when $unique_check='both'. I did a few changes in doqueries.php (see http://www.wiki4games.com/index.php?title=Wiki4Games:RatingBar/doqueries.php), hopefully it's solved now :) Cheers Franck Dernoncourt 18:55, 20 April 2009 (UTC)

Hi Franck, thank you very much for the fast response and fix to the problem. The changes you made solved the "you voted %" problem, thank you! There was just a slight error in the code: on line 133, 141 and 143 of doqueries.php. Which was caused by the ' sign in didn't, I changed these lines to "You did not vote on this yet" and it worked splendidly! Although I might have caught another bug in the voting mechanism. It seems that when the setting in doqueries is set to "both", it displays that a vote has been made by a not logged in user with the same IP when a logged in user is at the same voting page, and it says that "you voted before logging in". But if the logged in user tries to vote again, the vote is recorded and the number of votes are increased by one. Somehow the script recognizes that it's a user with the same IP, but doesn't stop that same IP from placing a new vote if it goes by a new username than which placed the vote before. Does the same thing happen for you when testing it? Thanks again, I appreciate your help very much. Sincerely, --Jonem 10:38, 21 April 2009 (UTC)
 * For the errors on line 133/141/143 it's because you copy/pasted MediaWiki's output instead of the source: in the source the ' are defined as their xhtml code (eg &amp;#39;), in the output they display like string containers thus create errors. As for the other "both" behavior problem, I'm not sure, but maybe this is related to the max number of votes per IP. But as I said earlier, the specification for this $unique_check still needs to be defined accurately before we can say whether the extension behaves as specified or not... Patheticcockroach 11:37, 21 April 2009 (UTC)