This is a great little module, with one exception - it doesn't store my product attributes (size/color etc), rendering the wishlist unusable, as anyone making a purchase from the wishlist will not know what product to purchase for the user. It would be nice if an update could address this problem - it's a fairly major issue as far as it goes. Thank you very much.

Comments

mcmikee3’s picture

I agree with Jay - the Wish List is a great module but without being able to save Attributes, it's not half as useful as it could be. It would be superb if an update could be introduced as soon as possible to rectify this issue. Many thanks, Mike

artatum’s picture

I cannot disagree with this :)

scott.mclewin’s picture

I'm not really sure that there is added value in making this data structured - as in dedicated fields to size and color. There are so many things that could be placed on a wishlist that it would be hard to figure out where to stop adding structured fields. In fact, I think the eventual complexity that would lead to would reduce the value of the module.

Any of this information can easily be put into the description, which is free form text.

What value do you see in making this structured data? A visitor following the link to the site with the item is sold is still required to read the data off your site and select the right size/color/etc choices on the commerce site. There's no standard way to pass that sort of information along to commerce sites in the URL.

Perhaps I am missing some context. Explain where having fields for specific attributes that might not apply to a large number of wishlist items overall is a good thing.

scott.mclewin’s picture

Status: Active » Closed (works as designed)

Closing issue due to lack of response to design questions to submitter. I cannot see tremendous value in adding structured fields that won't apply evenly across any item that can be tracked in this general purpose wishlist module. I'm not opposed to having further debate on the subject.

jaypan’s picture

Status: Closed (works as designed) » Active

Ideally, the module would take the selected attributes, save them, and present them on the form. So if I chose an XL Blue [something], on my wishlist it would show: [something] XL Blue.

Right now it just shows [something]. As such, the person looking at my wishlist has no idea as to what size and/or color the item would be.

This can all be done dynamically. When the button is clicked, the attributes are scanned, and their lable can be attached with the value. This could in turn be serialized and stored in the database, or even stored simply as text.

scott.mclewin’s picture

Status: Active » Postponed (maintainer needs more info)

That sounds like what taxonomies are for and don't strike me as appropriate to add to the wishlist module directly.

Define, using your example, two taxonomies. Color and Size. Associate those taxonomies with the wishlist nodes on your site, and I believe you have what you need.

Is this a solution you've explored? If no, consider it. If yes, were there non-layout related shortcommings?

jaypan’s picture

Ubercart doesn't use taxonomies, it uses attributes that are defined within Ubercart.

scott.mclewin’s picture

Ok.

Ubercart also drives behaviors off those attributes that are directly related to the purchase process, like price differences for the purple widget vs the black one, which Drupal taxonomies do not model. And Ubercart needs to apply those attributes to repeated classifications of products distinctly because the same thing is sold over and over again, but each classification may require different attributes. It's an entirely different model with different needs.

For the purposes of communicating to somebody which specific color of shirt to purchase on an external site from your wishlist none of that additional workflow is required, and it is easily communicated in the description, for starters.

This is a simple module that focuses on letting people check items off a shared list of desired items for special events and holidays. It is not an ecommerce engine.

Furthermore any attributes could not be passed along to any arbitrary ecommerce web site, so your user still needs to follow a URL and know to pick the color you want themselves.

I acknowledge that you feel strongly about this, and we have a difference of opinion. I don't characterize this as an issue at all, certainly not a major issue and far from rendering the module unusable. I've been open to being convinced of your use case, but so far I see nothing that you cannot do by blending taxonomies and the wishlist module, or by simply entering "I want the XL zombie protest shirt from thinkgeek.com".

Perhaps I've misunderstood how you are using the module. I'm open for another round of discussion.

jaypan’s picture

I've realized that this module is just unusable with ubercart. I'll just code my own specific to Ubercart. This one is not compatible with it, and you apparently don't see the need to add that compatibility, which is fair enough as it's your module.

scott.mclewin’s picture

Now I see more clearly that your concerns were specific to wishlist module and ubercart working together - you are looking for a wishlist functionality out of your own store, for customers of that store to track and share items they want out of the store on your site, sort of like amazon.com wishlists.

Yes, it's not useful for that. I agree.

The wishlist module was not built with that in mind, and it's not something I had even thought of.

If you think you see a path starting with the current wishlist functionality that adds what is necessary to support being a wishlist tied into ubercart for items from a store on the same site let's discuss that. Here is fine, via email is fine (start with my contact form and we'll go from there). While it's not something I'd build myself, if you can offer up a patch that fits your needs and is general enough I can see that being a valuable extension to the wishlist module.

So your call. I'm open to design ideas that lead to a patch, and I'm also fine with you cutting your own custom piece of work to get to where you need.

What was never clear to me in this entire discussion was your context - your use cases. I think now I've seen it and I agree with you. This module as it stands does not work for what you want.

scott.mclewin’s picture

Status: Postponed (maintainer needs more info) » Closed (works as designed)