In fivestar_field_widget_info (in fivestar.field.inc) a 'select' widget type is declared. When creating new content on our site, all taxonomy terms in the content creation form were replaced with this widget , so we couldn't select taxonomy terms (but instead could only select from a popup menu of 1 star / 2 star / etc.).

I changed the widget label to 'fivestar_select' on lines 174 in fivestar_field_widget_info() and 232 in fivestar_field_widget_form() and the proper selection of taxonomy terms in content creation pages returned.

Files: 
CommentFileSizeAuthor
#4 1285456-4.patch1.13 KBBrockBoland
#3 FivestarBug.png14.44 KBBrockBoland

Comments

ericduran’s picture

Yea, we should be pre-fixing the names with fivestar.

a.luiz.n’s picture

same here.

BrockBoland’s picture

StatusFileSize
new14.44 KB

Seeing the same thing. Screenshot attached to demonstrate:

Fivestar Bug

BrockBoland’s picture

Status:Active» Needs review
StatusFileSize
new1.13 KB

Confirmed that the proposed solutions works, and created the attached patch for it. If one of you can confirm this patch applies cleanly, I think it'll be ready for RTBC.

ericduran’s picture

Status:Needs review» Needs work

This is also going to review an update hook.

bigjim’s picture

+1 for patch in #4, needed to clear the cache.

ericduran’s picture

Yea, this can't go in without an update hook. It'll break everyones else site.

BrockBoland’s picture

I can't for the life of me replicate this bug now, using Fivestar 7.x-2.x (commit 88f430) and Drupal 7.10. Was this fixed in the course of other bug fixes?

ericduran’s picture

I've personally never been able to replicate this issue. The number of people having this issue seems pretty low as I would imagine if this issue was real it would have a lot more people having this issue.

But I do think prefixing the widget with fivestar would be a good idea. But I won't commit this with out an update hook.

BrockBoland’s picture

Agreed. I'm happy to write it, but I'm not really clear where in the DB it would need to be updated. Can you point me in the right direction?

bigjim’s picture

The database fix is in the field_config _instance table's data field ( field_config_instance.data ). The issue will be it's a serialized array, I know PIA. I think it would be something like $instance['widget'] if $instance is the array form the data field. You can get the list of fivestar fields form the field_config table.

For me this is easy to reproduce, I simply have to add a term reference field to a node an voila, it's showing the fivestar option list.

ericduran’s picture

@jalama are you on the latest dev version?

bigjim’s picture

When I applied the patch I was working in an older version, I'll have to look tomorrow (it was at work), though it would have been a version from Nov/Dec. It's worth noting we are on a site that migrated form D6->D7 and we have tons of fields that are using the select widget provided by the Select module in fields.

digibrill’s picture

I am receiving the same error. I have a list of terms called Site Section and the drop down is showing Fiverstar ratings.

digibrill’s picture

Also, the module is greyed out on the module page, so I cannot disable it and uninstall normally. Next to Fivestar on the module page is also "Required by: Drupal (Field type(s) in use - see Field list)" Something has its wires crossed. I just updated to the most recent dev version. Do I have to change DB tables manually or? This is a test site where we moved from D6 to D7.

ikke’s picture

Same issue here - 2.x-dev doesnt fix it. I also upgrade a 6 to 7 site. Patch work for me.

ericduran’s picture

Status:Needs work» Fixed

Thanks BrockBoland for the initial patch.

I added an update hook to update any old "select" widget to fivestar_select.

This is now fixed on the latest dev.

Thanks.

--
http://drupalcode.org/project/fivestar.git/commit/a46866c

InTheLyonsDen’s picture

Upon downloading and updating the database for the latest dev version all of my votes were hosed. The data was in the voting table but I could not get the votes to appear or recalculate. I tried changing Voting API to calc on cron, flushing caches, etc. I ended up reverting to a pre-update backup.

BrockBoland’s picture

Status:Fixed» Needs work

That's probably no good. Did you keep a copy of the hosed DB? If not, would you be willing to re-do it on a dev site? It will probably help identify what went wrong if someone (probably ericduran) can review the DB contents.

ericduran’s picture

Oh really? That doesn't sound good.

Are we sure the db got hosed from this update? I'll do some testing to check.

InTheLyonsDen’s picture

I'll need to set up a dev copy and run it again. I took a gamble on a production update to attempt to fix a problem I was having similar to #1393812: AJAX / SQL error - one solution. Was thankful to do a SQL dump first. Oddly, the code did seem to fix the "PDOException: SQLSTATE[21S01]: Insert value list does not match column list" issue but all votes/stars went to zero. The site is an inhouse project that we launched this week. http://socdir.com - With the revert I'm now stuck with the PDOException issue. I should have some time to work on it tonight. Thanks!

InTheLyonsDen’s picture

Good news / Bad News. I went through the process of updating the database and newest version and noticed that the widget types had changed in the content types for the two content types I was using. I changed these widgets back to 'display stars" and wallah all the voting was back! So it appears it was just a post-update configuration reset.

The bad news... Users are not able to vote due to the PDOException error #1393812: AJAX / SQL error - one solution. I'll take that cause up on another thread. Thanks!

BrockBoland’s picture

ericduran: I see the problem. In the change you made in the install file:

<?php
// If the widget type is select, lets change it.
if ($instance['widget']['type'] = 'select') {
?>

Should be a double ==, because right now, it's resetting all Fivestar fields to use the select method.

ericduran’s picture

Doh, I see that. Thanks. Fixing asap now.

ericduran’s picture

Status:Needs work» Fixed

Thanks for that @BrockBoland I was also sure to give you both credit on the commit message and on the git author attribution :)

This is now fixed with this commit: http://drupal.org/commitlog/commit/2490/fbdfd17b6ffb677501a2eb9071313835...

Ok now this is really fixed.

ericduran’s picture

Actually I also decided to make a tiny change. There really is no reason to change the instance if it's not a select widget so I changed this:

<?php
  
foreach($instances as $instance) {
     
// If the widget type is select, lets change it.
     
if ($instance['widget']['type'] == 'select') {
       
$instance['widget']['type'] = 'fivestar_select';
       
// Update the instance
     
}
       
field_update_instance($instance);
?>

to this:

<?php
   
foreach($instances as $instance) {
     
// If the widget type is select, lets change it.
     
if ($instance['widget']['type'] == 'select') {
       
$instance['widget']['type'] = 'fivestar_select';
       
// Update the instance
       
field_update_instance($instance);
      }
?>
BrockBoland’s picture

That makes sense. Thanks again ericduran!

Status:Fixed» Closed (fixed)

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

digibrill’s picture

Still not fixed for me. I uninstalled Fivestar because of this conflict.

a.luiz.n’s picture

Is this fix in the dev version of 14th march?

a.luiz.n’s picture

Yeah, I installed the last dev version and it's working fine.