I've gotten used to two features I've re-done in Links 1.1x -- tracking ratings by user, and doing the top_nn searches for the day or week, etc.
I've tackled the ratings one tonight.
I've modified rate.cgi to track ratings by Username/LinkID. It will allow each user to vote on each link only once. After voting, it recalculates the votes/rating for each link in real time. This might slow down some larger sites that get a lot of rating activity.
I've removed the codes that do ClickTrack checking (since we don't expunge these records) and made some other changes.
It takes the standard input, but requires a user to log in.
It then checks the Rate_Log to see if that user voted on that Link before (Username/LinkID).
If they have, an error is generated. If not, the vote is registered (LinkID, Username, IP, Time, Rating) and the program then selects all votes for that ID:
Select Rating from Rate_Log where Username=$USER->{'Username'} and LinkID= $id
It marches through the found results, and counts $votes and $total. It then divides the $total/$votes and saves that and the new $votes count back to the Links table.
I'll be adding in a feature that will show the user their curent vote, and allow them to change it. In otherwords, they won't seen a "error" message, but will be shown their current vote for that link, and asked if they want to change it. They will still be allowed ONE vote per link, but they can change it, and the Ratings/Votes recalculated.
Because this required a rewrite of rating.cgi I can't even begin to figure out how to make this a plug in! It requies adding a table via SQLMonitor and replacing the rating.cgi
Any bugs? Probably <G> But you'll find them, and I'll fix them.
Let me know if you want this.
This probably won't be portable (meaning if the rate.cgi is changed) you'll have to manually do changes.
Alex: You might want to consider merging something like this into the rate.cgi, and allow an option "quick ratings". That way, the program will function the way it is now, or by tracking complete rating data. It's probably more efficient to make the "build ratings" a cron job, or part of the "build" procedure so that the ratings are only recalculated intermittantly.
PUGDOGŪ
PUGDOGŪ Enterprises, Inc.
FAQ: http://pugdog.com/FAQ
I've tackled the ratings one tonight.
I've modified rate.cgi to track ratings by Username/LinkID. It will allow each user to vote on each link only once. After voting, it recalculates the votes/rating for each link in real time. This might slow down some larger sites that get a lot of rating activity.
I've removed the codes that do ClickTrack checking (since we don't expunge these records) and made some other changes.
It takes the standard input, but requires a user to log in.
It then checks the Rate_Log to see if that user voted on that Link before (Username/LinkID).
If they have, an error is generated. If not, the vote is registered (LinkID, Username, IP, Time, Rating) and the program then selects all votes for that ID:
Select Rating from Rate_Log where Username=$USER->{'Username'} and LinkID= $id
It marches through the found results, and counts $votes and $total. It then divides the $total/$votes and saves that and the new $votes count back to the Links table.
I'll be adding in a feature that will show the user their curent vote, and allow them to change it. In otherwords, they won't seen a "error" message, but will be shown their current vote for that link, and asked if they want to change it. They will still be allowed ONE vote per link, but they can change it, and the Ratings/Votes recalculated.
Because this required a rewrite of rating.cgi I can't even begin to figure out how to make this a plug in! It requies adding a table via SQLMonitor and replacing the rating.cgi
Any bugs? Probably <G> But you'll find them, and I'll fix them.
Let me know if you want this.
This probably won't be portable (meaning if the rate.cgi is changed) you'll have to manually do changes.
Alex: You might want to consider merging something like this into the rate.cgi, and allow an option "quick ratings". That way, the program will function the way it is now, or by tracking complete rating data. It's probably more efficient to make the "build ratings" a cron job, or part of the "build" procedure so that the ratings are only recalculated intermittantly.
PUGDOGŪ
PUGDOGŪ Enterprises, Inc.
FAQ: http://pugdog.com/FAQ