Hope to get Ryan's input on this one...I know he does a ton of work for churches and faith-based orgs, this is a critical function for donations for them and other non-profits and uc_varprice was created to accommodate those needs. Any idea if a version of this module will be contributed to Commerce module or be an optional included part of Commerce?
Comments
Comment #1
mattyoung commentedsubscribe
Comment #2
rszrama commentedI'm not sure yet exactly how this should work... on the one hand, it should be fairly trivial to accomplish something similar, where a particular product or product type is given the ability to become a "Variable priced product". However, it could also be that instead of using a product there's some other line item type that gets created that is added to the cart through its own form instead of the normal add to cart form. That might wreak havoc on the site building process, though... haven't really thought it through much. : )
Will have to give it some more thought, as it's something I've thought about but didn't plan on even attempting until the bigger fish were fried. : P
I'm very open to ideas.
Comment #3
scotwith1tthanks Ryan, i had just gleaned from your blog and the fact that you created modules like this that this was a big factor for you (and projects like open church and such), so wanted to get that conversation going; it certainly seems a bit trivial to worry about this until the basics work, but still. thanks for considering it in the future...wish i could contribute. one day i'm going to tackle php and put in my fair share! you guys rock.
Comment #4
rszrama commentedPutting this into a new "Component" for contributed modules and marking postponed until after 1.0 is out. Anyone can feel free to take this on if they have the time.
Comment #5
Jackinloadup commentedSubscribe
Comment #6
ldweeks commentedJust saw this post. I just closed a duplicate post that I had added on this issue: #1140118: Donation Module. You've got the right idea here: It's not that the product needs to be a "donation". The key issue is that a product should have a variable price, regardless of what it's used for.
I've been looking at this for some hours now, and my initial optimism that I could figure it out has been dashed. :-P Oh well.
I did figure out along the way, though, that it's fairly easy to set up tiered pricing for any given product. You can even start that pricing at 0. That means that you could offer a product where people can choose the price (that's pretty standard), but you could simply start at 0 if it's a donation. The customer could choose to pay $0, $5, $10, $25, etc.
Not as flexible as a textfield, but it does the trick.
Comment #7
hunziker commentedWith the module Commerce Option and with some rules you can implement this.
You create option set with a textfield. You assign the option set to a product. Then setup a rule, which calculates the selling price. The selling price depends on the entered data in the textfield. I have done something similar already, only that I had to multiply the textfield with some other field.
Comment #8
berenddeboer commentedJust need this as well, trying your approach now hunziker.
Comment #9
Sunflowers11 commentedWhy not just create a unit priced product and use the quantity field as the "amount" of the donation? Create a custom layout to hide the amount field from the end user and present the quantity field as the amount.
Comment #10
berenddeboer commentedTried this, but this is not going to work for me actually. What I need is that at time of node (product) creation, you can set a price. And this is optional.
Comment #11
drupalsteve commentedsubscribe
Comment #12
Bcwald commentedsubscribe.
Comment #13
jrust commentedI looked into trying to resolve this -- seems simple enough, but unfortunately no so much. I thought it would involve:
1. Hook into the Add to Cart formatter info and add a "Show Price" option, similar to "Show Quantity"
2. Hook into the add to cart form and add the textfield.
3. Hook into the add to cart submit process and modify the price accordingly. However, commerce_cart_product_add() only takes a product_id, so modifying the price would have to take place through a rule. Additionally, there is the problem commerce_cart_product_add() combines identical products into one line item by default which is not what you want when the price for each product could be different.
That's where I stopped and am now leaning more towards the route outlined in this post of creating new products on the fly since that is known to work and apparently has the endorsement of commerce guys as the best practice.
Comment #14
rszrama commentedYou can also do what I do with UC Variable Price - store the value entered in your custom price textfield in the line item's data array and then create an action that can set a price to whatever value is stored in the data array. It'll just be a little annoying to have to deal with the custom price in a pricing rule if it needs to interact with other pricing rules.
Comment #15
jrust commentedGood idea, Ryan, which hadn't occurred to me. Since line items are entities I could hook into the saving and loading of them to alter the price. What I still don't see is how to access the textfield value when the line item is being saved so that I can store the varprice in the data array. Even if I override commerce_cart_add_to_cart_form_submit() (which I'd rather not do) in order to call commerce_cart_product_add() from within the module I still have no way to pass in the extra data to be stored in the line item's data array. Am I missing some other hook? :)
Also, do you think implementing hook_field_formatter_info() is the way to go for adding the settings related to varprice? I haven't looked at how I'll access all the formatter variables in my hook_form_alter(), but theoretically it seems possible. I don't see anything similar to Ubercart Features, so I assume those are gone, correct?
Comment #16
ronald_istos commentedWithout having spent too much time on this I would have thought that given the ability to change prices with rules it is a question of having some source (textfield, etc) that feeds into a rule which then modifies the price before it goes into the cart. But really just subscribing for now :-)
Comment #17
jrust commented@ronald_istos, I thought about that, with my idea being adding a new Field to the line item entity, but the problem I encounter is still a way to cleanly add the form submit data to the line item.
Even so, it seems there needs to be some sort of re-implementation of hook_add_to_cart_data() that existed in Ubercart. A simple and clean way to modify the add to cart form and then get those submitted values into the line item's data array. I looked into how the commerce_product_attributes did it and it is similar to what I outlined in #15 -- overriding both commerce_cart_add_to_cart_form_submit() and commerce_cart_product_add() which seems like a lot of rewriting for something so simple, plus I don't see how that method could play well once you have multiple modules wanting to all modify the add to cart form. I've put in an issue to this effect: #1190654: Add hook that allows line item to be modified by add to cart's form values.
Comment #18
berenddeboer commentedLet me detail my very custom solution: I just created a new price field which you can add to a node.
If you save the node, a new product is created (and updated when you edit the node), taking the set the price as the price for that product.
Comment #19
artatac commentedsub
Comment #20
sreynen commentedI eventually got a donation-type product working. This is a pretty custom setup, but hopefully it's enough to be useful for someone else.
First, I used Commerce Option to add a price field to the add to cart form. I was a little confused at how this works at first, so I'll go through that in more detail. After enabling Commerce Option, there's a new "Commerce Option Sets" tab under store > products. I created a new set, put the price field in there, and then added an "Option Set Reference" field to the product type pointing at the set.
Next, I created a rule action component to change a line item price to a given price. Export for that:
Then I created a custom rule action in code to pull the price out of the commerce option based on the given line item. This is maybe possible somehow in the Rules UI, but I couldn't figure out any way to do it other than custom code. Here's the code I usd for that, which I put in module_name.rules.inc:
Finally, I added both rules actions to a new pricing rule, and set the data selectors to the line item and the generated "Fetched price" variable. This works fine for one donation, but it multiplies the value by the quantity, so I'm still working on how best to deal with multiple donations under the same product.
Comment #21
aaronbaumansubscribe
Comment #22
pixelsweatshop commentedsub
Comment #23
JefferyMac-dupe commentedsubscribing
Comment #24
Oboklob commentedHi Scott,
Thanks for that code. Helped a lot - once I realised that the Option Set needs to be named "amount" for your example to work, or change the line
$query->condition('a.bundle', 'amount', '=');appropriately e.g.
$query->condition('a.bundle', 'your_option_set_name_here', '=');Comment #25
BrendanP commentedsub
Comment #26
rszrama commentedI should've come back to this after Randy posted his excellent tutorial / screencast. Donation products with variable amounts are now totally possible just by adding a custom price field to a product line item type and exposing it to the Add to Cart form. The value can then be swapped in as the price for the donation product in a product pricing rule.
See Randy's tutorial here: http://www.commerceguys.com/resources/articles/238
Comment #27
emjayess commented3 years after the initial request/inquiry, this is still the best advice for getting donations set up. That's a bummer.
Comment #28
pixelsweatshop commentedUm, no...
https://drupal.org/project/commerce_donate
Comment #29
hjulien commentedI wanted to set up variable pricing in a different way but have no idea if it's possible.
The subscription product is for government profiles and the cost depends on the population in that government's jurisdiction. Smaller governments get charged less and larger ones get charged more.
Technically, I see 2 major components - a census population file for cities to be used as data and a calculation based on tiered prices for different population ranges.
The code would have to look at which range the government in question falls into to calculate the price. And then the subscription price remains static until the next census.
Does this sound feasible? Could this be done with rules or would it require a custom module?