Ignore / delete product display entity and just use product entity

Yes, you can delete it. You opted to include example store content, and that included the product display node type. However, you should definitely do some reading to understand the abstraction here. I recommend:

http://drupalwatchdog.com/1/1/building-commerce-product-display
http://drupal.org/node/1199602#comment-5365636

That said, you're free to devise any strategy for displaying products that you want. At Commerce Guys, we've used nodes, Views, Panels, and Search API in different combinations to display products, with several of our sites not using node based product displays at all.

Right, the point of the second link is that the developer basically started thinking it was "overengineering" to separate products from the product displays but then basically re-implemented the exact same architecture hacked onto Ubercart. When he realized this, he returned to Drupal Commerce. : )

I've written a lot elsewhere on the division, obviously didn't have the space in that one magazine article to go into it. Here's the blurb I use in my training document:

Separation of Product & Product Display

A product in Drupal Commerce can represent one of several things:

●	A single item for sale on the site
●	A variation in a group of items for sale on the site (e.g. one size of a t-shirt)
●	A non-tangible product reserved through the site (e.g. event registration)
●	An item that is not purchased but which represents the purpose of payment for a particular order (e.g. donation account or campaign)

Depending on the product and the site’s needs, products may be displayed on unique pages, on pages grouping multiple products together (e.g. all the sizes of a t-shirt), on multiple different pages or Views, or not at all.  For this reason, Drupal Commerce enforces a separation between the definition of a product and the product display.

This separation allows you to:

●	Track stock for a single product regardless of what display it’s purchased through (especially important for multilingual / multi-domain sites).
●	Use a different display strategy to fit the site (e.g. a node per product, a single View listing all available products, etc.).
●	Easily manage the import and update of particular product data without worrying about updating related display settings.
 
Attribute Fields

Fields attached to products can be exposed on Add to Cart forms as attribute fields.  These are common fields among a group of products whose allowed values may be used to select a particular product from the group to add to the cart.

The settings for attribute fields are built into the field edit form.  These are typically List fields and Taxonomy term reference fields, because they have a discreet number of options.  Attribute fields can use select list or radio button widgets on the Add to Cart form.
 
Referenced Product Field Injection

Additionally, any field attached to a product may be rendered into the display of an entity (i.e. node) containing a product reference field.  This feature must be enabled in the product reference field’s settings form.  We call this field injection, because the field is attached to the product itself but can be displayed in the referencing entities to make this extra product data visible to customers.

Because these are fields attached to the product itself, you must update the field display settings on the product type to change the display formatter and/or the field’s global visibility.  Then in the field display settings for each entity type that contains a product reference field, you will see all available product reference fields to reorder them relative to other fields on the entity or hide them.

Example use cases

The most obvious example is the basic price field attached to products.  In most cases, you will need the price displayed along with the product description and Add to Cart form.

Another use case is the product image field created during the Commerce Kickstart installation.  This is especially the case for groups of products where each variation contains a unique image (e.g. for a different color of the product, such as a lipstick).  You will want this image rendered into the node display that groups these products together.

When the customer updates the Add to Cart form for a group of products to select a different product from the group, the price, image, and other injected fields will be updated to represent the newly selected product.

But as I said above, if you don't need product display nodes, Drupal Commerce is designed so you don't have to. It's completely legitimate and recommended to not use that paradigm if you don't need it. : )

If you don't want product display nodes, why are you looking for products in node listings (admin/content)? Makes no sense.

As for the views handler, you can extend it to do what you want (or use regular Views options to wrap data in an arbitrary link). Right now products are not exposed directly (there's no product/%commerce_product URL), so there's no option of linking to them.

It was my understanding Commerce goes the Drupal way, meaning it uses whatever Drupal has. I would consider a product just like a regular content type that would appear in admin/content. I think it makes perfect sense that a Drupal admin would think of a product as a content type.

You are misunderstanding the Drupal way :) admin/content is a listing of nodes. No other entity types are shown. Products are not content, just like users are not content. That's Drupal 6 thinking.
And I'm not sure how this is even relevant, since Commerce ships with a Products listing view (that can be extended with VBO, added to other paths, or whatever).

It is not just the views handler, I also noticed I cannot set paths for products, only product displays. It seems like I would need to extend Commerce to do something Drupal content types do out of the box.

Yes. You disliked the assumptions Commerce made with nodes, now you dislike the fact that there are no assumptions. The amount of code needed to actually use products directly is small, but not non-existing. And that's of course only if you don't have multiple product variations (such as t-shirt sizes).

I'm not going to go over this old debate with you again. The fact is that there needs to be a separation between a product and its variations. Call it however you want. It's the same problem in Commerce, Ubercart, Magento, and no silver bullet, only various architectural and interface solutions.
I realize that there are UX problems with separate add forms, which is why we're preparing a module to solve that: http://drupal.org/sandbox/rszrama/1181848 for cases where people don't want to care about the separation.

I can whine here day and night, I guess the decision has been made so either I digest it or look at Ubercart which was closer to having one product entity for a real world product.

Correct. Have a nice day.

I also see you pointed to the stackoverflow site, and replied to itamair's comment. You should read his followup:
http://drupal.org/node/1199602#comment-5365636

The difference is in Ubercart products were already nodes, but we had invented another term (product class) to refer to an existing concept (node type). The problem was the confusing duplication in terminology, whereas with Drupal Commerce we've already committed to a different architecture entirely. : )

It already is usable by itself if you build a View or Panel to use it. : )

In fact, I think there's a patch in the queue to allow Panels to accommodate multiple-value Add to Cart forms; don't quote me on that, though! : P

Well, I see what you're saying, but it's still not necessary to have a separate product entity. Using both Panels and Views you can craft URLs that include product IDs (or even use product titles and translate them into IDs) and then render the entity to the page with whatever other information you need. There is no path in the module itself, but it's easy enough to create on your own.

For example, I whipped this up in a couple minutes:

$view = new view;
$view->name = 'products';
$view->description = '';
$view->tag = 'default';
$view->base_table = 'commerce_product';
$view->human_name = 'Products';
$view->core = 7;
$view->api_version = '3.0';
$view->disabled = FALSE; /* Edit this to true to make a default view disabled initially */

/* Display: Master */
$handler = $view->new_display('default', 'Master', 'default');
$handler->display->display_options['title'] = 'Products';
$handler->display->display_options['access']['type'] = 'none';
$handler->display->display_options['cache']['type'] = 'none';
$handler->display->display_options['query']['type'] = 'views_query';
$handler->display->display_options['query']['options']['query_comment'] = FALSE;
$handler->display->display_options['exposed_form']['type'] = 'basic';
$handler->display->display_options['pager']['type'] = 'some';
$handler->display->display_options['pager']['options']['items_per_page'] = '1';
$handler->display->display_options['style_plugin'] = 'default';
$handler->display->display_options['row_plugin'] = 'entity';
/* Field: Commerce Product: Product ID */
$handler->display->display_options['fields']['product_id']['id'] = 'product_id';
$handler->display->display_options['fields']['product_id']['table'] = 'commerce_product';
$handler->display->display_options['fields']['product_id']['field'] = 'product_id';
/* Contextual filter: Commerce Product: Product ID */
$handler->display->display_options['arguments']['product_id']['id'] = 'product_id';
$handler->display->display_options['arguments']['product_id']['table'] = 'commerce_product';
$handler->display->display_options['arguments']['product_id']['field'] = 'product_id';
$handler->display->display_options['arguments']['product_id']['default_action'] = 'not found';
$handler->display->display_options['arguments']['product_id']['title_enable'] = 1;
$handler->display->display_options['arguments']['product_id']['title'] = '%1';
$handler->display->display_options['arguments']['product_id']['default_argument_type'] = 'fixed';
$handler->display->display_options['arguments']['product_id']['default_argument_skip_url'] = 0;
$handler->display->display_options['arguments']['product_id']['summary']['number_of_records'] = '0';
$handler->display->display_options['arguments']['product_id']['summary']['format'] = 'default_summary';
$handler->display->display_options['arguments']['product_id']['summary_options']['items_per_page'] = '25';
$handler->display->display_options['arguments']['product_id']['specify_validation'] = 1;
$handler->display->display_options['arguments']['product_id']['validate']['type'] = 'php';
$handler->display->display_options['arguments']['product_id']['validate_options']['code'] = 'return commerce_product_load($argument);';
$handler->display->display_options['arguments']['product_id']['break_phrase'] = 0;
$handler->display->display_options['arguments']['product_id']['not'] = 0;

/* Display: Page */
$handler = $view->new_display('page', 'Page', 'page');
$handler->display->display_options['path'] = 'product/%';

The only coder thing I did in there was add custom PHP validation to ensure that valid product IDs are given in the URL. Without that, I just was seeing a blank page... I suppose the alternative would've just been to add some empty results behavior.

To link in to these pages, you can just make a separate View listing all the products out and linking to their individual pages. Additionally you could use the Search API module to index these custom pages and link to them from search results... plenty of things you can do here.

I think it would make a lot of sense to have a module that will provide a solution to this product vs product display dichotomy. I would suspect that most simple e-commerce websites don't need the extra confusion that this takes with it. I'm basically just doing one Commerce site now and I don't have enough experience nor time to build a module that might solve this. But still... I really feel that if Drupal Commerce wants to succeed it needs to resolve this. I'm running into silly issues for which I've seen the solution but even then it's far from straightforward to come up with it (and I consider myself pretty experience with Drupal).
I can definitely not recommend dealing with the Product Display / Product split (and thus Drupal Commerce) to any store that wants to set up an e-commerce site, with pain in my heart I would send them straight to Magento...

(I must add that I've tried Ubercart in D6 and I wasn't very happy with that either.)

It exists: http://drupal.org/project/inline_entity_form

I am trying the inline_entity_form now.
It looks ok (except #1598296-4: Add a simplified widget for fields that accept only one entity of a specific type)
Still, I am having mixed feelings about the separation.

-----------------------

I think it would not hurt at all to have product implemented as a first-class entity type with its own "product/%", "product/%/view" and "product/%/edit" paths, url aliases, etc, similar to node/% and user/%, and then have the "product display" thing on top of that.

We could even say that, by default, all the product/% stuff can be restricted to privileged users, and url aliases for product entity need to be enabled via a separate sub-module. This way, product display would remain the default way to view and buy products.

The site builder could then choose between product display and 1:1 product entity pages. The decision could even be done separately per product entity bundle.
Some contrib author might even come up with an alternative to product display, all based on commerce_product.

The panels example in #17 shows that we are not so far away from that, and we can get there without breaking anything.

------------------

In fact I am in the process of creating a module "productpage" which does just that, using hook_menu() and friends. I had some difficulty to make the ds layout work, and I am a little worried about future namespace collisions (e.g., I needed to name my theme function "theme_commerce_product")

One thing I just noticed is that the cart field is only implemented for product display (as a formatter for product_reference field), and I have to hand-code a shopping cart field for product/%.

One question I have:
Can it happen that one product shows up in different product displays? Is this supported, or will this create issues? Could there be a reason why someone would want this?

I think it would not hurt at all to have product implemented as a first-class entity type with its own "product/%", "product/%/view" and "product/%/edit" paths, url aliases, etc, similar to node/% and user/%, and then have the "product display" thing on top of that

http://drupal.org/sandbox/davereid/1643530

@bojanz (#23) / Dave: This is cool!
I commented in its own queue, #1664148: Some feedback. Does it work with Display suite?.

@Giorgio (#24):
I like view modes and use them all day. I just don't know how they can solve the problem that product displays attempt to solve.
It can be used to render the product reference as an embedded entity with its own view mode. But then you can't easily intermix product fields with product display fields.
If we use paths like product/%, then we will mostly just use the 'full' view mode (this is what the davereid sandbox thing does), or something equivalent.

Otherwise, we could use custom view modes
- if we have other paths such as product/%/about, or
- if we want to switch view mode dynamically based on some product attribute, or
- if we want to embed the product on other pages. this could be a "product display" or anything else.

Btw, some more thoughts over here,
#1187316-13: Line Item concept. It is there only because of the use case described in the issue.

Hi,
Did you start by kickstart 2 and then went back to commerce?
Could you tell Erich exact steps you did?
Do you still use backoffice for instance?

Thanks a lot in advance!
Greetings, Martijn

tzpo