The fivestar module excessively uses the variable table. This is likely a holdover from its drupal 5 days. It really should be using its own table now.
The fivestar module excessively uses the variable table. This is likely a holdover from its drupal 5 days. It really should be using its own table now.
Comments
Comment #1
james.elliott commentedThe attached patch does the following.
I apologize also because I built this patch on top of the patch in #1045896: Move all theme function to theme.inc
Comment #2
james.elliott commentedFound an error in the last patch
Comment #3
james.elliott commentedBah, I get started working on #1181942: Clean up code and I keep finding holes in my first patch.
This patch fixes the views integration.
Comment #4
james.elliott commentedPerhaps I should have let this patch sit a bit longer on my machine before I posted it.
Anyway, this fixes a logic error where fivestar_get_settings() would never return the default settings if none had been previously set.
Comment #5
ericduran commentedThis looks good, There's a couple of mistakes such as ..
Should be fivestar
But all it all it looks really good. I'm wondering if we want to have all those fields. Some of the settings are really minor, I'm not sure if its justified to have a position and a position teaser, we can just stash that in a settings field.
Also if we're going to switch to using a database, we might as well work with the return data as an object instead of an associative array, I find it easier. Any comments?
Powered by Dreditor.
Comment #6
james.elliott commentedPerhaps we could use a single display field for the position and position_teaser settings. This would allow for N number of display contexts.
I'm also mostly array/object agnostic so it doesn't matter to me either way. The $settings for fivestar is currently an array, so we would have to alter all the items that use it to use object property references instead of array indexes.
I don't think this is the complete solution to fivestar efficiency but at least it is a step in the right direction.
Comment #7
james.elliott commentedHmmm I wonder if we could just avoid the display settings altogether and expose each tag on the content type with hook_field_extra_fields() ?
Comment #8
ericduran commented@james.elliott no need. The fivestar field already has an tag support and there is an exposed star formatter that lets you pretty much replace the regular fivestar nodetype settings with a field that a user can vote against.
Which is why I would rather remove the entire fivestar/node_type settings and concentrate on the field as its way more robust.
At first I thought about using hook_field_extra_fields but then I decided that making the fivestar_field better would just be a better solution to all the current fivestar problems.
Comment #9
james.elliott commentedI completely agree with your reasoning. I'm going to reroll this to be a migration from fivestar/node_type to just fields.
Comment #10
james.elliott commentedComment #11
james.elliott commentedComment #12
ericduran commented@james, nice!, I'll be testing this today.
Comment #13
james.elliott commentedSomething I discovered while playing with / testing the patch from #11 was that fivestar as a D7 field isn't working entirely. A field can't vote on its attached entity. While working on that, I discovered some inconsistencies in the UI. Most significantly was the disconnect between setting the # of stars as a field setting and then setting a different # of stars on the exposed stars formatter.
The second patch here makes some changes to the way that fivestar fields are configured. These are the highlights of those changes.
I know this is becoming a bit of a monster patch, but I'm not sure how to break it into separate issues. It doesn't make sense to force an upgrade to fivestar fields if they don't provide the same functionality as the old non-fielded method of enabling fivestar ratings.
Still left to do in this issue would be to determine the upgrade path for previously created fivestar fields and add a second update function to migrate them to the new configuration.
Comment #14
ericduran commentedI'm applying this patch right now.
I know there's some incosistency with the field which is why I was thinking of moving everything to either the formatter or the instance settings. I agree that the instance settings does make more sense.
Also there is a missing target now, but not essentially self, but none. Which essentially would treat the field as just a cck widget and not so much a votingapi target.
I'll have more feedback once I apply this patch. Thanks for the great work.
Comment #15
ericduran commentedPatches doesn't apply cleanly :(
Comment #16
ericduran commentedComment #17
james.elliott commentedWeird that it was marking conflict on a section where the only action was deleting a huge section of code.
I did a hard reset to 7.x-2.x and rerolled the patch. This one should apply cleanly.
Comment #18
ericduran commented@james, I'm completely on board with almost all the changes you're requesting but some of these changes can be separated out.
This is it's own patch and can be its own issue.
This is another separate issue one witch is a duplicate of another already open issue.
Same as above.
Also an unrelated change.
Powered by Dreditor.
Comment #19
ericduran commentedAnother issue that can be resolve before this one, making this patch a lot smaller and easier to grok. #1203428: Better Fivestar access check for the exposed field
Comment #20
james.elliott commentedI just posted a patch for #1203428: Better Fivestar access check for the exposed field
I think perhaps the rest of the portions you called out are related to #1173814: Replace php target selection with something better and should be rolled into a patch for that.
Comment #21
james.elliott commentedHere's a slimmer version of the patch. It is built on top of the patch in #5 for #1173814: Replace php target selection with something better because it depends greatly on where and what data is stored.
Comment #22
james.elliott commentedblah, the last patch still had the stuff for #1203428: Better Fivestar access check for the exposed field in it. Fresh reroll here.
Comment #23
james.elliott commentedThis is another reroll of the patch based on the conversation here http://drupal.org/node/1173814#comment-4675342
Comment #24
james.elliott commentedMissed a spot and added the target selector twice.
Comment #25
james.elliott commentedNow it was my turn to have too many patches at once.
This is the real patch for this issue.
Comment #26
james.elliott commentedI've still been working on this as part of integration into Drupal Gardens. I've pulled quite a lot out of this and moved it into separate issues. The current patch order I've been using is as follows.
#1203428: Better Fivestar access check for the exposed field
#1212914: Implement hook_field_prepare_view() to add a default for all fivestar fields
#1205166: Field settings should be instance specific
#1173814: Replace php target selection with something better
#1198128: Convert fivestar/node_type pairings into fivestar field widgets
#1222330: Add an exposed stars widget and remove the exposed stars formatter
#1203392: Remove color picker
The latest is attached
Comment #27
marcoka commentedi applied all the patches according to #26
i run drush updb after every patch, but 0005 throws an error
7004 install throws an error
http://screensnapr.com/v/9bKoWs.png
you remove it at line 656
-function fivestar_get_suffix($node_type, $tag) {
and you call it later like at line 121.
got some warnings too:
Notice: Undefined index: node in fivestar_fivestar_target_info() (Zeile 1491 von /var/www/WORKSPACE_DRUPAL/drupal_test/sites/all/modules/contrib/fivestar/fivestar.module).
Warning: in_array() [function.in-array]: Wrong datatype for second argument in fivestar_fivestar_target_info() (Zeile 1491 von /var/www/WORKSPACE_DRUPAL/drupal_test/sites/all/modules/contrib/fivestar/fivestar.module).
Notice: Undefined index: node in fivestar_fivestar_target_info() (Zeile 1491 von /var/www/WORKSPACE_DRUPAL/drupal_test/sites/all/modules/contrib/fivestar/fivestar.module).
Warning: in_array() [function.in-array]: Wrong datatype for second argument in fivestar_fivestar_target_info() (Zeile 1491 von /var/www/WORKSPACE_DRUPAL/drupal_test/sites/all/modules/contrib/fivestar/fivestar.module).
Comment #28
hydra commentedsubscribing
Comment #29
marcoka commentedi did what has be done here #5
http://drupal.org/node/1173814
added a comment, votet, hit preview, verything ok, hit save, error
errors
http://screensnapr.com/v/LBU0Wv.png
Comment #30
james.elliott commentedNew patch to address the issue in #27. I stupidly was trying to use fivestar_get_suffix() in an update function when the patch was removing that function.
Comment #31
ericduran commentedHmm, trying to decide which one to tackle 1st, this one or #1222330: Add an exposed stars widget and remove the exposed stars formatter, this does remove all the complexities of having to support two different ways of using fivestar.
.....
Comment #32
ericduran commentedDecided to go with this one.
-- Here's a re-rolled.
Comment #33
ericduran commentedThis is now fixed. On to the next one.
--
http://drupalcode.org/project/fivestar.git/commit/89ab6b67b54d63efb19416...