I am facing a use case where I might need several wishlists to be available to the user. Since the commerce order system allows multiple simultaneous orders per user (you can also have multiple carts #1350342: Multiple cart instances), this should be possible as well.
This would introduce a new database table containing a wishlist name and the corresponding order id (and probably uid for fast indexing). The add to wishlist submission needs some rewriting and hook_menu might need some changes to allow sub-pages, together with some smaller changes.
But it would allow more options for people to, for example have a separate birthday and Christmas wishlist. Combined with public viewable wishlists, this could be a strong feature where you could share one link with a certain group of people and another link with another group.
I am willing to investigate and write the required changes for this, if you would agree on implementing this.
Comments
Comment #1
aramboyajyan commentedSounds good! I was thinking about that actually, but it was far off from the project I needed the wishlist for in the first place, so I didn't do it.
I'll think about it these days and keep this issue posted with any ideas / outline.
Comment #2
neograph734Great. I made a start with it already and expect to have something within a few days.
Comment #3
aramboyajyan commentedHere are some quick thoughts till I didn't forget:
- The add to cart element should be altered to include a select list of user's wishlists. If the user doesn't have any wishlists, we can display a textfield instead where the user can enter the name for new wishlist.
- We need a new Views field element that will expose the Wishlist title; this might be necessary for the search/filter functionality
- Regarding the
hook_menu(): the subpage can be atuser/%user/wishlistand will list user's wishlists. If the user has only one wishlist order, we can take the visitor directly there.- Single wishlist view can be at
user/%user/wishlist/%commerce_orderComment #4
neograph734We should perhaps also add a variable for storing the latest wishlist, so it is pre-selected when the user browses to another item. This could be the last wishlist a product was added to.
Yes and no. It is improved user experience, but Drupal has many pages where an "add new ..." link is shown at the top of the page. People might expect it to be at the wishlist overview page but then get redirected.
Comment #5
neograph734Committed. I've made some big changes, so I am not sure it is fully backwards compatible. And I still need to implement some proper access checks for some of the pages but let me know what you think.
Comment #7
aramboyajyan commentedThanks for the commit, will check it and keep you posted.
Comment #8
neograph734Looking forward to your reply. Here are some things I still want to look at.
Still left to do:
Show a textfield (or other option for creating a wishlist) on the product page, this needs to be done from the account for now.Store the last used wishlist in the session and preselect this wishlist for subsequent product displays.Improve lay-out of product display as the dropdown kinda breaks it. (I thought or moving the wishlist selection dropdown to a sidebar block displaying also the contents, but then we would need to split the form over multiple blocks. If the block is not present on the page fall back to a dropdown above the button.)Fix the form elements on the wishlist page as they no longer work.Future ideas:
Comment #10
neograph734Only thing left to is access checks.
Comment #11
neograph734Closing this is favor of #2505843: Implement access checks