I'm working on some code to automatically create a product when a product display is created. Basically, it just populates the $product object from the $node object, then passes it off to db crud (I'm having a little trouble integrating this with the controller class and am just using db_ubdate, etc for now).

I imagine the configuration options as something like this:

1. Content type to mirror as Product
2. Fields to add to Product (eg title, price, sku, etc)
3. Any additional operations to perform on field-data (if there's a compelling reason to do this)

Once configured, when the node is updated, created or deleted, the associated product is also. At this point, assuming a use-case similar to mine, the end-user needn't be bothered with the semantic division set up by commerce between business logic and presentation (a very programmery way of thinking).

Any thoughts on this?

Comments

aweizd’s picture

Love the idea! Commerce really needs some help to "unify" products with their nodes.

starsinmypockets’s picture

Well, this is a very rudimentary stab at what I'm trying to do. I think for my own use case that this may be close...

function my_product_displays_form_alter(&$form, &$form_state, $form_id ='' ){  
  //prepopulate & hide product reference
}

function my_product_displays_node_insert($node) {
	switch($node->type) {
	  case 'record_display' :
	    {
	      $product = commerce_product_new($type = 'record_product');
		  $product->sku = $node->nid;
		  $product->product_id = $node->nid;
	      $product->title = $node->title . '-' .$node->field_artist['und'][0]['name'];
	      $product->commerce_price[LANGUAGE_NONE][0]['amount'] = $node->field_price['und'][0]['value']*100;
	      $product->commerce_price[LANGUAGE_NONE][0]['currency_code'] = 'USD';
	      //@todo - version id
	      commerce_product_save($product);
	   	}	
	}
}
function my_product_displays_node_update($node) {
  switch($node->type) {
    case 'record_display' :
      $product = commerce_product_load($node->nid);		  
      $product->title = $node->title . ' ' . $node->field_artist['und'][0]['name'];
      $product->commerce_price[LANGUAGE_NONE][0]['amount'] = $node->field_price['und'][0]['value']*100;
      $product->commerce_price[LANGUAGE_NONE][0]['currency_code'] = 'USD';
      dpm($product);
      commerce_product_save($product);
  }
}

function _product_exists($product_id) {
  $result = db_query("SELECT * FROM {commerce_product} WHERE product_id = :id", array('id' => $product_id))->fetchField();
  return($result);	
}

I'm doing some funny stuff with nid, product_id & sku, but I'm really just going for a proof of concept. If there's any interest in this solution I'd be happy to develop it further.

mefisto75’s picture

Certainly a needed feature. I have no idea how to explain to store owners the concept of product node and product entity. Left apart a need to fill out both.
There is a thread to use Rules to do the same http://drupal.org/node/971484
But contrib, in my view, is a more viable approach.

Stalski’s picture

I have committed an enhancement already in dev to clone products from another and to add products in their displays.
It's already a step in that good direction.

sven.lauer’s picture

This approach sounds quite terrible to me. If that is what you want, you really should take it up with commerce guys and try to convince them that the separation is not right.

HOWEVER that does not mean that one could not have an UI that hides the display node/product distinction sufficiently (though I am not sure if it might not actually work out nicely to have this distinction, if commerce_bpc where ready for prime time---which I know all to well it is not. Then saying to a store owner "This is how you create bundle of products---and now you can enter some presentational details ...".)

IF you want to take the display node / product distinction out of the equation (at least UI wise), it seems to me that what might work is to go the other way round and automatically create minimal display nodes. If you really want, you could even easily display all products through a single display node, using additional path segments to identify the products to display.

The idea that "products are not nodes" sounds very right to me, even from a non-geek standpoint. In using übercart, it was usually quite HARD to get people to accept that if they want to create a product, they have to go to "create content" or having them show up as content etc.. Having them instead go to "Store->Products" and dealing with products instead of nodes is a big step forward.

A much cleaner (and more useful, generally speaking) approach to get rid of display nodes (if you so choose) is to write a way to directly display products in the frontend.

sven.lauer’s picture

This approach sounds quite terrible to me. If that is what you want, you really should take it up with commerce guys and try to convince them that the separation is not right.

HOWEVER that does not mean that one could not have an UI that hides the display node/product distinction sufficiently (though I am not sure if it might not actually work out nicely to have this distinction, if commerce_bpc where ready for prime time---which I know all to well it is not. Then saying to a store owner "This is how you create bundle of products---and now you can enter some presentational details ...".)

IF you want to take the display node / product distinction out of the equation (at least UI wise), it seems to me that what might work is to go the other way round and automatically create minimal display nodes. If you really want, you could even easily display all products through a single display node, using additional path segments to identify the products to display.

The idea that "products are not nodes" sounds very right to me, even from a non-geek standpoint. In using übercart, it was usually quite HARD to get people to accept that if they want to create a product, they have to go to "create content" or having them show up as content etc.. Having them instead go to "Store->Products" and dealing with products instead of nodes is a big step forward.

A much cleaner (and more useful, generally speaking) approach to get rid of display nodes (if you so choose) is to write a way to directly display products in the frontend.

starsinmypockets’s picture

For my use case, at least, there is a lot more information needed in the display than is needed in the product to process the transaction. In my case, it makes sense for the content administrator to enter the display, and for the product to be quietly created (/updated/deleted) in the background, in order to satisfy Commerce module's requirements to handle the transaction.

starsinmypockets’s picture

I created a sandbox project for this:
http://drupal.org/node/1233798/

sven.lauer’s picture

You probably also want to keep an eye on this sandbox project, which does something similar (but without duplicating the fields on node and product:

http://drupal.org/sandbox/rszrama/1181848