I need a voting plugin, will pay

[gregman]

When I said it should remain unchanged, I meant the graphical version should calculate exactly the same as the text version.

Ok I fixed this. I thought it would be complicated to get the text based score calculated the right way. Now I know it wasn't. I just had to "add" 3 points.

perhaps it would be a good idea to have a configuration option for whether or not to allow voting from overview pages???

This option already exists.

I also added a dropdown to the configuration display.

[Don Chambers]

Just downloaded the latest, and am getting this:

Code: Select all

Warning: Division by zero in /my server path/plugins/serendipity_event_karma/serendipity_event_karma.php on line 685

And for the record - you are saying that the stored/saved calculation is identical for both text and graphical based voting, correct???

The drop down looks good.... perhaps not display the .png portion?

Finally - I think the plugin needs the ability to select the glow image separately from the main image. Right now, you have a green image as the "glow" image for a yellow diamond... but I foresee the probability that you could have several different color diamonds, and perhaps someone wants a regular image to be red, and perhaps glow is yellow...... make sense?

[gregman]

Hi,

ok, I eliminated the division by zero bug.

The scores are now identical, which means the voting always ranges from -2 to 2 and is stored in the database this way. In order to get the right amount of stars on a relatively scale from 1 to 5, the score has to be calculated as follows: a "3" is added for each vote (simulating a voting range from 1 to 5) and then the sum has to be divided by the amount of votes.
Example: Two best votes (2) and one worst vote (-2) is 2 + 2 - 2 = 2; (2 + 3 * 3) / 3 = 3,67 which means three and a half stars.

Changing the colors of the images is simply possible by adding a new set of files. I don't see the need to include a separately configuration option for this and can't imagine how this could be implemented, sorry.

Greg

[Don Chambers]

1) Div by zero bug gone.

2) Calculation for text version and graphic version:

• a) A vote of 5 stars, or '++' stores a value of 2 for each vote in the database, correct?
  b) 5 of these votes would record a karma value of 10, correct?
  c) To determine the graphical rating, the calculation would be (2 points *5 votes =10) + (3 points * 5 votes = 15 more points), subtotal is 25 points, divide that by 5 votes which equals 5 diamonds, stars or whatever.... correct?

If my assumptions above are correct, then I would think the whole calculation matter has been resolved.

3) "Glow" color: Using the example graphics of diamonds, you have the current vote score shown in yellow, and a potential vote shown with green. But let's say that the color scheme of my site makes it so that red would be a preferable choice to green for the "glow" state. Right now, that means I would have to generate another 16 graphics (or copy the existing ones to a new name) changing only diamonds_glow.png to a red color. Everything else would remain visually identical.

Let's say you instead started with 2 (or 3, 4, whatever) complete sets of images. Now I could select any combination I wanted (from those available) for the current/possible vote. I could have green on yellow (like now), I could have yellow on green.... red on green, etc.

The only complication I see is that there would probably need to truly be a color on color "glow" version of the graphic - ie, if I want to use an all green color scheme, but need to see the difference between the glowing green, and a regular green.

One possibility for implementation of this MIGHT be to have a y/n radio button (default: no) to "Use alternate "on" image for glow state" followed by a dropdown select field for all image file names in the folder, and use the "_on" version of that file if the radio button value is "yes". Or no radio button, but the first choice/default in the dropdown is the "whatever_glow" version, and the rest are the "_on" alternatives. Does this sound reasonable, or is this level of flexibility/featureset too complex?

4) Is anyone else testing this plugin or have input on functionality or code?

[Don Chambers]

Links:

1) I see the old plugin showed a href of just # until clicked, whereas the new one shows the full path to the vote. Was that deliberate, or an oversight?

2) I think the voting block needs a unique anchor for each entry so that once clicked, and the page is reloaded, it is repositioned right at the karma div.

3) This final issue might be modification related, or might be the difference between using URL rewriting. I have the old version installed on a site that does not use URL rewriting. I have the new version on a site that does use rewriting. The links below are for example purposes - they do not lead anywhere.

Start here
http://www.examplesite.com/blog/archives/P2.html

Vote on one of the entries (which happens to be entry #30) on page 2 with a "very good" (ie 2) rating, and land here:
http://www.examplesite.com/blog/blog.ph ... rma_vote30
I no longer see page 2 - this takes me back to my base page. I WOULD see page 2 if archives was preceeded by a slash. In the old version, without URL rewriting, archives IS preceeded by a slash. Is this URL rewriting, or something overlooked in the revised code?

Start again with page 2
http://www.examplesite.com/blog/archives/P2.html

Select permalink/detailed page for entry #30:
http://www.examplesite.com/blog/archive ... entry.html

Vote on the entry with a very good rating again:
http://www.examplesite.com/blog/blog.ph ... rma_vote30
Still no slash before archives, but I still see the detailed page of entry 30.

Another example:
Start at base site: http://www.examplesite.com/blog/

Vote "good" (ie 1) on entry that appears on base site and land here:
http://www.examplesite.com/blog/blog.ph ... rma_vote38

While still on that URL, vote "good" on different entry and land here:
http://www.examplesite.com/blog/blog.ph ... rma_vote36

despite the appended URL, the vote does count.

[Don Chambers]

Hey Greg - I have one more idea.

Right now, the plugin contains a single option to track & display hits. I think it would be a great idea to separate those options. Keep the existing variable for whether or not to track hits, but add a new variable that works as a minimum threshold before hits are shown (default 0).

Having a blog, it is great to see that an entry received 400 hits.... but it can be misleading to see 0 hits, or a really low number....

[judebert]

I'd just use the $track_visits_of_loggedin_users variable. Change it from a boolean to a int (and update the descriptive text). Then, if it's 0, don't track visits. If it's positive, track visits and use the value for the minimum before you display it.

[judebert]

I just checked out the output of the plugin. The inline JavaScript is making it nearly unreadable.

If I were implementing this, I'd use the CSS Star Rating method. It uses CSS for the rating hover, so you lose the JavaScript and make everything more readable. It even degrades for text browsers, and it uses links for the ratings, just like the current plugin.

[Don Chambers]

I'd just use the $track_visits_of_loggedin_users variable. Change it from a boolean to a int (and update the descriptive text). Then, if it's 0, don't track visits. If it's positive, track visits and use the value for the minimum before you display it.

That's a great idea judebert - but for the record, there are 2 variables with respect to counting visits/hits - one for regular users, and an additional one that determines whether to also count visits for logged-in users. I suspect your idea would be applied to this first variable - $visits_active... is this correct?

EDIT: I also took a bit of time to check out that css method - very slick!! The above link is the 2nd of 3 articles that author wrote on the subject.... so all 3 really need to be read to understand how the author arrives at his ultimate solution. In that final version, I think the best solution for this plugin will be either the classic rater, or the small rater. Some how we need to preserve the ability to change the size of the image. I look forward to Greg's input on this.

[judebert]

there are 2 variables with respect to counting visits/hits - one for regular users, and an additional one that determines whether to also count visits for logged-in users. I suspect your idea would be applied to this first variable - $visits_active... is this correct?

Hmmm. I missed that. Yes, I'd probably apply it to the $visits_active.

EDIT: I also took a bit of time to check out that css method - very slick!!

Yeah, I actually wrote a little test page of my own to examine how it works. VERY slick. And almost designed for our purpose.

Some how we need to preserve the ability to change the size of the image. I look forward to Greg's input on this.

That's all handled in the CSS. Just set the various classes to the appropriate left and width. It could even be determined automatically from the image width and height (by someone who has experience with that kind of thing).

[Don Chambers]

Agreed - nearly perfect for this use!!! Need to restructure the HTML to an unordered list, but other than that, it looks fairly straight forward. I would move this forward a bit on my own but this plugin is being modified by Greg locally - he is not using subversion. Additionally, I really hate plugins that set variables to contain a string of html... then finally get around to emitting that string. It is definitely not Greg's fault for that - the original plugin uses that method. I would just be able to make a more immediate change if I could play around in MY world of html and css instead of tripping over all this php script that guys like you and Greg know so much better than myself!!!

Automagically detecting the image size would be awesome, so 3rd parties (like me) could create new images that do not necessarily have the same size as the originals. Using this css technique as an example, which stacks 3 image states within a single graphic image file would require dividing the height by 3.

[judebert]

Don - I've been experimenting a little more, and I've got some refinements to the original method that provide some niceties. Only one image is required, meaning there's no lag in image loading. The stars don't have to match; I even made a little demo with stars that have faces. You could make it animated, if you wanted.

While the CSS needs to know the star width, the rating doesn't.

I'll upload the example to my website, as soon as it's back up.

[Don Chambers]

Awesome Jude!!! I'm sure Greg will appreciate your input!!!! I know *I* do!!!!

[carl_galloway]

Just a heads up, I've finally caught up with this thread and it looks like some very exciting work being done. Thanks guys, I'm looking forward to seeing the finished result. I've downloaded a version from Greg's site but haven't had the time to play with it yet, but I'll try to do this in the next couple of days.

[gregman]

Hi,

very good news. Actually, I was searching for a sole css method too, but couldn't find some. The only problem I see, is compatibility (looking at the comments on the komomedia blog). Also aligning it right is pretty complicated. IMHO it might be better to use the DOM level 2 API for changing the images. But what I really like is the use of background-repeat in combination with a variable width for displaying the rating. Therefore you can display any fracture of the rating, not only full and half stars.

You can get the image size automatically by getimagesize($string) and store it in a class variable. The css event hook does recognize this.

Greg