The current fivestar methodology of using an "exposed stars" formatter does a poor job of handling the widget vs exposed form duality that fivestar creates. It is an uncommon use case that you will be adding a rating to an entity as you create it and also want viewers to be able to give it click ratings.

The solution I've come up with is to create an "exposed stars" widget that hides the field on the entity edit form and then creates the exposed form when the entity is viewed. It also adds an option to the stars formatter (on by default) that toggles the "exposed" bit of the "exposed stars" widget. This allows you to display the stars in a teaser while not making them clickable.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

james.elliott’s picture

Status: Active » Needs review
FileSize
14.67 KB
ericduran’s picture

I like this idea. I struggle with this issue. This also makes it a lot easier for the end user, as it's a lot clearer what kind of stars they'll be creating up front.

Is this patch dependent on any of the other patches? It'll be nice if we can get this one in before the others.

james.elliott’s picture

The patch I posted is built on top of some other patches I've posted. It could be rerolled to be applied to 7.x-2.x HEAD but the update function especially would need rerolling. My methodology has been to migrate the settings from field level settings to instance / formatter as is appropriate. The end goal being a simpler UX for adding exposed widgets as well as the ability to specify the widget styling for each instance of the "stars" widget and each formatter for the "exposed stars" widget.

I've found a few bugs in the first patch and have rerolled it. The other previous patches I have applied are attached as well. The patch for this issue is the last.

David_Rothstein’s picture

I rerolled the patch to fix some whitespace issues, and also to make two text changes (both suggested by Chris Brookins):

  • For the two widget names, instead of "Exposed stars" and "Stars", switched to "Stars (rated while viewing)" and "Stars (rated while editing)". Not sure if it would be a good idea to switch the machine names to match those also, but for now I left them at 'exposed' and 'stars'.
  • For the default value dropdown options, instead of "None/1/2/3...", switched to "No stars / 1 star / 2 stars...".

For those following along at home, the instructions to get this patch to apply have changed a bit from the above, since the first two patches have been committed. So now, apply patches 0003, 0004, and 0005 from comment #3 above, followed by the attached patch, in order to get it to work.

David_Rothstein’s picture

Just to give proper credit, I believe Jeff Noyes was partially responsible for these suggested text changes as well :)

David_Rothstein’s picture

Testing these patches further, there were some problems.

The non-exposed stars widget and the select list widget were both broken; if you tried to change the star rating while creating or editing a node (depending on the situation) your changes would be ignored.

This looks like it was due to a mixup between star number and percentage vote, and also due to an incorrect use of default values.

I've fixed those issues in the attached patch. I'm also attaching an interdiff file so you can see what changed from the previous version.

ericduran’s picture

Priority: Normal » Critical

I would almost rather deal with this patch before #1198128: Convert fivestar/node_type pairings into fivestar field widgets -- because that other patch changes so much and the entire methodology of how fivestar is used now. I just don't want to confused so many people.

We'll see how far I get.

ericduran’s picture

Status: Needs review » Fixed

Patch above coitted, minor changes to the target selection because we're now hiding the exposed field on the UI.

@David_Rothstein it looks like both patches are the same. Also I don't have the issue you describe above, should I worry about the interdiff?

/me goes write test.

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

David_Rothstein’s picture

The two patches are similar, but not exactly the same. It looks to me like you committed the correct one, though, so I think there shouldn't be any problems. Thanks!

Status: Fixed » Closed (fixed)

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