Product reference is displaying disabled products

Do you mean it's listing disabled products in the widget or showing referenced disabled products on display? It should still include them in the widget's select list but not show them on the front end... however, it'd be nice to include a widget setting to not show disabled products. Even with that on, though, we need to make sure that if the current referenced product on a node should become disabled, when the widget form element is built that product should always be an option.

Same(?) here. Referenced 4 products in a product display node. Than disabled two of that products. After that all four products are still selectable in the display node. One can click on the "Add to cart" button of a disabled product and got a message: "... added to your cart". It is not added to cart really, but it is very confusing.

I think there should be options to choose the behavior of disabled products:
1| disabled product is hidden from display
2| disabled product is shown, but there is no "Add to cart" button (neither price(?)) and the system displays a (configurable) message about that the product is not available. (Something like "Not for sale" of UC)

I think that makes sense not to display disabled products in the user view, but keep them in the selection form of the administration for product displays.

We could also make this an option of the field settings

Repo: git.drupal.org:sandbox/pcambra/1081200.git
Branch: 1029518
Diff: http://drupalcode.org/sandbox/pcambra/1081200.git/commitdiff/8ddb0856096...

The fix for the cart form looks fine, but for the display formatter it's incorrect. You're ditching an API function that returns an array containing just a product SKU / title per product ID instead of a full product object even though the data is still referenced later via the array. That said, I don't think we need to change the non cart form display formatters anyways, since those are really administrative only. Even so, it is probably still a good idea to ditch this single use API function (_commerce_product_reference_get_product_data()) in favor of just using commerce_product_load_multiple() and updating the references to the $products arrays after that to reflect this.

Ok, so here's a version that ditches the api function.
I've let the status check anyways, I'm not sure if there could be some use cases to use those not only for administrative purposes, feel free to take it out :)

Repo: git.drupal.org:sandbox/pcambra/1081200.git
Branch: 1029518
Diff: http://drupalcode.org/sandbox/pcambra/1081200.git/commitdiff/d515db6c950...

I'm going to commit this, but a quick fix to a PHP notice this introduced is now going to introduce a regression in cases where a non-Add to Cart form display formatter is used for a disabled referenced product. The Product Reference module renders product fields in the node's content array when it detects a product reference field set to display as an Add to Cart form or when it is hidden. This is another of those areas where I relied on "magic" settings (as in "Product attribute fields"). I've filed a patch to address the regression and am marking this issue complete.

See: #1105352: Add an option to product reference fields for "importing" product fields

Hi,
If it is ok, I open this issue.
My usecase is the following. I import products and rely on their information. Sometimes the price of a product is zero, and then I have to set the status of this product to disabled. This works through rules. That is working.

Now I have already available product-displays with those disabled products with price of zero.
But the product-displays still show the disabled products! So customers can buy disabled products. This is not expected behavior.
I would expect that when I disable a product, the node-display of the product should not render the add-to-cart form.
Am I correct in this assumption?

I use latest commerce 1.8 and all commerce-modules in latests versions.
Thanks a lot in advance for your reply, and sorry if you want me to open new issue. But this issue is exactly referring to this problem I think.
Greetings, Martijn

Hi,
I found this rule: http://dropbucket.org/node/78
It seems to try to do what I want to achieve. Setting nodes to disabled when the product-entity itself is set to disabled.
No go..

How can I see which nodes should be changed because of this?
What could be the problem please?

// Get new status from product
$new_status = $commerce_product->status;

// Get all nodes that reference this product
$query = new EntityFieldQuery();
$query->entityCondition('entity_type', 'node')
  ->entityCondition('bundle', 'product_display')
  ->fieldCondition('field_product', 'product_id', $commerce_product->product_id, '=');
$result = $query->execute();

if (isset($result['node'])) {
  $nids = array_keys($result['node']);
  $nodes = entity_load('node', $nids);

  // Change status on nodes
  foreach ($nodes as $node) {
    $node->status = $new_status;
    node_save($node);
  }
}

Greetings, Martijn

Let's leave this issue closed, as it represents an actual bug that was fixed some two years ago. It sounds to me like you just need support with your import configuration. Disabled products are not purchasable, though they may still be displayed, and that part is by design.

Hi @rszrama, thanks for update. I agree disabled products should be displayed, but the "add-to-cart-button" should not be displayed with it.
This is now the case.
Greetings, Martijn

It's not the case in any of my testing, so it must be a configuration thing or else perhaps an Add to Cart form that references more than one product and only one is disabled.

Hi @rszrama, I will test more. I have above rule in #9 working! My product displays name was not "product_display" but "product". Thanks to your remark here: http://www.drupalcommerce.org/questions/3167/if-i-have-product-object-ho...
If you installed using Commerce Kickstart, then your product reference field is named field_product and your display node type is product_display.
I didn't install using Kickstart...so thats why I have another name.
Greetings, Martijn