Comments

james.elliott’s picture

The attached patch does the following.

  • Implements hook_schema to define a table of the values currently being put in the variable table
  • Converts the storage of the tags from a string to a serialized array
  • Provides an update function to convert the data and then remove the variables
  • Standardizes setting names (e.g. enable_unvote to allow_clear)
  • Removes the fivestar_get_suffix() function
  • Updates the fivestar_get_tags() and fivestar_get_settings() functions to match the schema
  • Updates the fivestar_node_type_tag_form to work with the new schema
  • Updates the fivestar_settings and fivestar_node_type_tag_form submit functions to properly save the settings
  • Adds a fivestar_default_settings() function to store the defaults in a single location
  • Changes theme_fivestar_preview() to use a single variable consisting of the settings array

I apologize also because I built this patch on top of the patch in #1045896: Move all theme function to theme.inc

james.elliott’s picture

Found an error in the last patch

james.elliott’s picture

Bah, I get started working on #1181942: Clean up code and I keep finding holes in my first patch.

This patch fixes the views integration.

james.elliott’s picture

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

ericduran’s picture

Status: Needs review » Needs work

This looks good, There's a couple of mistakes such as ..

+++ b/fivestar.moduleundefined
@@ -196,15 +195,10 @@ function fivestar_theme() {
+  db_delete('table')

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.

james.elliott’s picture

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

james.elliott’s picture

Hmmm I wonder if we could just avoid the display settings altogether and expose each tag on the content type with hook_field_extra_fields() ?

ericduran’s picture

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

james.elliott’s picture

I completely agree with your reasoning. I'm going to reroll this to be a migration from fivestar/node_type to just fields.

james.elliott’s picture

Title: Give fivestar its own db table » Convert fivestar/node_type pairings into fivestar field widgets
james.elliott’s picture

Status: Needs work » Needs review
StatusFileSize
new12.56 KB
ericduran’s picture

@james, nice!, I'll be testing this today.

james.elliott’s picture

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

  • Moved the text and star display options to the widget settings. I thought this made sense as it would apply to the fivestar field on the entity edit form as well as the entities view display. For example, the display settings would match when creating a node as when viewing the node.
  • Moved the feedback and allow clear settings to the widget settings. I did this with the same reasoning in mind as with the display options. The reason I didn't leave this in the field settings was that I could see a use case where unvoting wouldn't apply to multiple instances.
  • Changed the ordering of the field configuration form. It seems at this point the most important form elements here are the tag and the vote target. So I moved them up.
  • Changed the vote target "" option to be "Self". I think it makes more sense that way. I also added a conditional "Custom php" option that will reveal the php textarea when selected. I think it reduces the confusion in the UI while not removing any of the functionality.
  • Removed the exposed star formatter. Instead there is now an "expose" option that is enabled by default to configure the star formatter. All of the display options are set on the instance, so the only choice remaining here is whether to expose it to click voting.
  • Removed some unnecessary functions that were no longer being called
  • Altered the update function above so that it will properly set the field and instance options to match the new field configuration
  • I also had to update fivestar_fivestar_access to properly allow a fivestar field to vote on its own entity

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.

ericduran’s picture

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

ericduran’s picture

Patches doesn't apply cleanly :(

ericduran’s picture

Status: Needs review » Needs work
james.elliott’s picture

Status: Needs work » Needs review
StatusFileSize
new30.61 KB

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

ericduran’s picture

Status: Needs review » Needs work

@james, I'm completely on board with almost all the changes you're requesting but some of these changes can be separated out.

+++ b/fivestar.moduleundefined
@@ -467,21 +437,17 @@ function fivestar_validate_target($entity_type, $id, $tag, $uid = NULL) {
+  $fields = field_read_fields(array('module' => 'fivestar'));
+  ¶
+  foreach($fields as $field) {
+    if ($field['settings']['axis'] == $tag) {
+      $params = array(
+        'entity_type' => $entity_type,
+        'field_name' => $field['field_name'],
+      );
+      $instance = field_read_instances($params);
+      if(!empty($instance)) {
+        return TRUE;
       }
     }

This is it's own patch and can be its own issue.

+++ b/includes/fivestar.field.incundefined
@@ -56,25 +53,30 @@ function fivestar_field_settings_form($field, $instance) {
-  if (empty($dynamic_options)) {
-    drupal_set_message(t('No potential target fields are available for the %type bundle. Create a node reference field in this bundle to make it easier to assign a vote to a node.', array('%type' => $instance['bundle'])), 'warning');
-  }
-
-  $dynamic_options = array('' => '<'. t('none') . '>') + $dynamic_options;
   $form['dynamic_target'] = array(
     '#title' => t('Voting target'),
     '#type' => 'select',
     '#default_value' => isset($field['settings']['dynamic_target']) ? $field['settings']['dynamic_target'] : '',
     '#options' => $dynamic_options,
-    '#description' => t('The voting target will make the value of this field cast a vote on another node. Use node reference fields module to create advanced reviews. Use the Parent Node Target when using fivestar with comments. More information available on the <a href="http://drupal.org/handbook/modules/fivestar">Fivestar handbook page</a>.'),
+    '#attributes' => array(
+      'class' => array('fivestar-target'),
+    ),
+    '#description' => t('The item that this widget will case a vote on. Use node reference fields module to create advanced reviews. Use the Parent Node Target when using fivestar with comments. More information available on the <a href="http://drupal.org/handbook/modules/fivestar">Fivestar handbook page</a>.'),
   );
 
   if (user_access('use PHP for fivestar target')) {
+    $form['dynamic_target']['#options']['custom_php'] = t('Custom PHP');
+    ¶
     $form['php_target'] = array(
       '#type' => 'fieldset',
       '#title' => t('Voting target PHP code'),
       '#collapsible' => TRUE,
       '#collapsed' => empty($field['php_target']),
+      '#states' => array(
+        'visible' => array(
+          '.fivestar-target' => array('value' => 'custom_php'),
+        ),
+      ),

This is another separate issue one witch is a duplicate of another already open issue.

+++ b/includes/fivestar.field.incundefined
@@ -83,18 +85,21 @@ function fivestar_field_settings_form($field, $instance) {
-  else {
-    $form['php_target']['php_target'] = array(
-      '#type' => 'value',
-      '#value' => isset($field['settings']['php_target']) ? $field['settings']['php_target'] : '',
-    );
+  else if ($field['settings']['dynamic_target'] == 'custom_php') {
+    $form['dynamic_target']['#options'] = array('custom_php' => t('Custom PHP'));
+    $form['dynamic_target']['#disabled'] = TRUE;
+    $form['dynamic_target']['#description'] = t('This field has been configured using advanced settings that you do not have access to change.  Contact the site administrator if you believe this to be in error');

Same as above.

+++ b/includes/fivestar.field.incundefined
@@ -160,7 +165,8 @@ function _fivestar_field_helper($entity_type, $entity, $field, $instance, $langc
-  if (isset($field['settings']['php_target']) && !empty($field['settings']['php_target']['php_target'])) {
+
+  if ($field['settings']['dynamic_target'] == 'custom_php' && !empty($field['settings']['php_target']['php_target'])) {
     // Use eval rather than drupal_eval to allow access to local variables.
     $target = eval($field['settings']['php_target']['php_target']);
   }
@@ -176,8 +182,8 @@ function _fivestar_field_target($entity, $field, $item, $langcode) {

@@ -176,8 +182,8 @@ function _fivestar_field_target($entity, $field, $item, $langcode) {
       $target = $entity->$field['dynamic_target'];
     }
   }
-  elseif (isset($item['target'][0]['nid'])) {
-    $target = $item['target'][0]['nid'];
+  else {
+    $target = $entity->nid;

Also an unrelated change.

Powered by Dreditor.

ericduran’s picture

Another 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

james.elliott’s picture

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

james.elliott’s picture

Status: Needs work » Needs review
StatusFileSize
new28.33 KB

Here'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.

james.elliott’s picture

blah, the last patch still had the stuff for #1203428: Better Fivestar access check for the exposed field in it. Fresh reroll here.

james.elliott’s picture

This is another reroll of the patch based on the conversation here http://drupal.org/node/1173814#comment-4675342

james.elliott’s picture

Missed a spot and added the target selector twice.

james.elliott’s picture

Now it was my turn to have too many patches at once.

This is the real patch for this issue.

marcoka’s picture

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

hydra’s picture

subscribing

marcoka’s picture

i 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

james.elliott’s picture

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

ericduran’s picture

Priority: Normal » Critical

Hmm, 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.

.....

ericduran’s picture

StatusFileSize
new36.08 KB

Decided to go with this one.

-- Here's a re-rolled.

ericduran’s picture

Status: Needs review » Fixed

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.