Closed (outdated)
Project:
Voting API
Version:
7.x-2.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
1 Jul 2008 at 01:41 UTC
Updated:
18 Feb 2018 at 21:13 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
BlakeLucchesi commentedI started working on integration with votingapi, based on the table structure for votingapi there needs to be modification to the way hook_ranking works to allow WHERE clauses or data needs to be stored in another way so that total votes and averages can be joined on to the node table directly without WHERE clauses.
Will follow up more on this later, but for now its late.
Comment #2
BlakeLucchesi commentedAttached is an initial version of a patch to add a scoring factor for average vote score. Tests need to be written to verify.
Comment #3
BlakeLucchesi commentedRe-rolled, sorry that first one wasn't even close to working.
Comment #4
BlakeLucchesi commentedPatch rerolled for the votingapi module instead of fivestar. The patch adds hook_ranking for the votingapi module so that nodes can be ranked based on average voting score during search. The query joins votes that are tagged as 'vote'. (this is the default tag for vote data stored in votingapi, and is how fivestar module stores votes in votingapi.)
Comment #5
BlakeLucchesi commentedmoved to votingapi module issue queue.
Comment #6
eaton commentedI definitely like the idea, unfortunately this will break when voting modules like VoteUpDown or Plus1 are used -- they work with total counts rather than averages...
Comment #7
Drave Robber commentedI'm working on this. ETA unknown.
Comment #8
Drave Robber commentedThere is now some some code in the sandbox.
Needs more documentation, though.
(Did it indeed take me ~4 hours to basically solve a 4-year old issue, or am I missing something essential? Apart from the obvious facts that a) real men do not use core Search, and b) the example for
hook_ranking()is broken which might have stopped someone from doing this.)Comment #9
eaton commentedWay back in the day, the concern was that alternate voting styles wouldn't work well with it. Using all of the available tags and functions is a great solution to that! Also, after the initial D7 port was done a number of years ago, I haven't had a lot of time to put into new features. This looks like a great solution!
Comment #10
Drave Robber commentedExcellent, I'll go back to polishing this and will probably ask for a formal review in a week or so.
Which mode of release (A: stuff the code into
votingapi.module, B: keep in a separate module but ship with Voting API, C: release as a separate project) seems better? (Moi, j'ai doubts about A as a separate README.txt would be quite useful for this feature.)Comment #11
eaton commentedPersonally, I'd lean towards A -- it's a clean enough implementation that it won't clutter up the codebase too much, and it's a valuable feature to have centralized. A chunk can certainly be added to the README, though!
Comment #12
Drave Robber commentedPatches for A and B attached. (history of polishing here)
Comment #13
Drave Robber commentedI still lean more towards B - for four years, the public wasn't exactly screaming for this feature, suggesting there won't be many users for it; on the other hand, the few interested in this might want MOAR features, such as:
...which would be easier to implement under B.
Comment #14
pifagor commented