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

mattyoung’s picture

subscribe

rszrama’s picture

I'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.

scotwith1t’s picture

thanks 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.

rszrama’s picture

Component: Price » Contributed modules
Status: Active » Postponed

Putting 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.

Jackinloadup’s picture

Subscribe

ldweeks’s picture

Just 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.

hunziker’s picture

With 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.

berenddeboer’s picture

Just need this as well, trying your approach now hunziker.

Sunflowers11’s picture

Why 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.

berenddeboer’s picture

Tried 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.

drupalsteve’s picture

subscribe

Bcwald’s picture

subscribe.

jrust’s picture

I 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.

rszrama’s picture

You 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.

jrust’s picture

Good 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?

ronald_istos’s picture

Without 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 :-)

jrust’s picture

@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.

berenddeboer’s picture

Let 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.

artatac’s picture

sub

sreynen’s picture

I 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:

{ "rules_test" : {
    "LABEL" : "Set line item price to given price",
    "PLUGIN" : "action set",
    "REQUIRES" : [ "commerce_line_item" ],
    "USES VARIABLES" : {
      "given_line_item" : { "label" : "Line Item", "type" : "commerce_line_item" },
      "given_price" : { "label" : "Price", "type" : "commerce_price" }
    },
    "ACTION SET" : [
      { "commerce_line_item_unit_price_amount" : {
          "commerce_line_item" : [ "given-line-item" ],
          "amount" : [ "given-price:amount" ],
          "component_name" : "base_price"
        }
      }
    ]
  }
}

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:

/**
 * Implements hook_rules_action_info().
 */
function custom_donation_rules_action_info() {

  return array(
    'custom_donation_get_price' => array(
      'parameter' => array(
        'commerce_line_item' => array(
          'type' => 'commerce_line_item',
          'label' => t('Line item'),
        ),
      ),
      'provides' => array(
        'price_fetched' => array('type' => 'commerce_price', 'label' => t('Fetched price')),
      ),
      'group' => t('Donation'),
      'label' => t('Fetch price from line item'),
    ),
  );

} // custom_donation_rules_action_info

/** 
 * Gets a price from a commerce option named
 * 'field_amount' associated with a line item.
 */
function custom_donation_get_price($line_item) {

  $price = commerce_price_field_data_auto_creation();

  $query = db_select('commerce_option', 'o')
    ->condition('o.line_item_id', $line_item->line_item_id, '=');

  $instance = $query->join('field_data_field_amount', 'a', 'a.entity_id = o.option_id');

  $query->condition('a.bundle', 'amount', '=');
  $query->addExpression('SUM(a.field_amount_amount)', 'total_amount');

  $amounts = $query->execute();

  foreach ($amounts as $amount) {
    $price['amount'] += $amount->total_amount;
  } // foreach

  return array('price_fetched' => $price);

} // custom_donation_get_price

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.

aaronbauman’s picture

subscribe

pixelsweatshop’s picture

sub

JefferyMac-dupe’s picture

subscribing

Oboklob’s picture

Hi 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', '=');

BrendanP’s picture

sub

rszrama’s picture

Status: Postponed » Closed (works as designed)

I 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

emjayess’s picture

3 years after the initial request/inquiry, this is still the best advice for getting donations set up. That's a bummer.

pixelsweatshop’s picture

3 years after the initial request/inquiry, this is still the best advice for getting donations set up. That's a bummer.

Um, no...

https://drupal.org/project/commerce_donate

hjulien’s picture

Issue summary: View changes

I 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?