Support from Acquia helps fund testing for Drupal Acquia logo

Comments

BlakeLucchesi’s picture

I 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.

BlakeLucchesi’s picture

Status: Active » Needs review
FileSize
1.14 KB

Attached is an initial version of a patch to add a scoring factor for average vote score. Tests need to be written to verify.

BlakeLucchesi’s picture

Re-rolled, sorry that first one wasn't even close to working.

BlakeLucchesi’s picture

FileSize
2.55 KB

Patch 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.)

BlakeLucchesi’s picture

Project: Search Ranking » Voting API
Version: 6.x-0.x-dev » 6.x-2.0-beta6

moved to votingapi module issue queue.

eaton’s picture

Status: Needs review » Needs work

I 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...

Drave Robber’s picture

Title: Voting API Integration » hook_ranking() implementation for Voting API
Version: 6.x-2.0-beta6 » 7.x-2.x-dev
Assigned: Unassigned » Drave Robber

I'm working on this. ETA unknown.

Drave Robber’s picture

There 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.)

eaton’s picture

(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.)

Way 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!

Drave Robber’s picture

Excellent, 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.)

eaton’s picture

Personally, 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!

Drave Robber’s picture

Patches for A and B attached. (history of polishing here)

Drave Robber’s picture

I 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.

pifagor’s picture

Issue summary: View changes
Status: Needs review » Closed (outdated)