from ubertcart 1.0 until 4.x, there is a table:

 $schema['uc_products'] = array(
    'description' => 'Product information for nodes.',
    'fields' => array(
      'vid' => array(
        'description' => 'The {node}.vid of the product.',
        'type' => 'int',
        'unsigned' => TRUE,
        'not null' => TRUE,
        'default' => 0,
      ),
      'nid' => array(
        'description' => 'The {node}.nid of the product.',
        'type' => 'int',
        'unsigned' => TRUE,
        'not null' => TRUE,
        'default' => 0,
      ),
      'model' => array(
        'description' => 'SKU or model number.',
        'type' => 'varchar',
        'length' => 255,
        'not null' => TRUE,
        'default' => '',
      ),

I think we need change it now, My idea is :
create a product field, which contain three columns only: sku, cost, sell price,
If a node type has this fied, it is a product type, if it does not has , it is a normal node type.

other attributes in uc_products table, such as weight, weight_units, length,....
In a lot of real project, i have never used them, I have to use your uc powerfull tools to hide them.
In the future, ifwe need a weight attribute, we could add a custom field for it.

using a field replace uc_products table is modern enough in Drupal8, and it is much lightweight than using a entityreference.
OG module has a similar code architecture in drupal 6, it drupal7, it use a field to indicate a OG group.

Comments

g089h515r806 created an issue. See original summary.

g089h515r806’s picture

g089h515r806 CreditAttribution: g089h515r806 commented
Issue summary: View changes
g089h515r806’s picture

g089h515r806 CreditAttribution: g089h515r806 commented

I wish Ubercart4.x in Drupal 8 support this featue.

g089h515r806’s picture

g089h515r806 CreditAttribution: g089h515r806 commented

Entity which has a sell price is a product.

Commerce: A node which has a product entity reference is a product
Ubercart: A node which has model,cost, price, weight ... atributes is a product

Future Ubercart: A node which has a price field is a product

Future Future Ubercart: Entity which has a sell price is a product.

It is simple enough, and flexible enough.

g089h515r806’s picture

g089h515r806 CreditAttribution: g089h515r806 commented

related issue: https://www.drupal.org/node/2223617,

g089h515r806’s picture

g089h515r806 CreditAttribution: g089h515r806 commented

After i download the latest code of Ubercart 4.x, I think there still a lot of work to do
for issue "Modernise product fields", the uc_products table still exist, the attributes still exists.
The path "admin/store/products/classes" still exists.
It is the same with Drupal7.

longwave’s picture

longwave
he/him
Primary language English
Location UK
CreditAttribution: longwave commented

This is a good idea, but there are lots of implications. What would happen if you added a product field to an order entity, or a cart item entity? How would we add images (or other fields) to products for use in the cart or elsewhere? What would happen if you had a multi-valued product field? What if you added two different product fields to an entity?

The idea of a product feels a bit more fundamental than just having a field. It does make sense for OG membership but I am not yet convinced it a field covers everything we need from a product.

g089h515r806’s picture

g089h515r806 CreditAttribution: g089h515r806 commented

1,What would happen if you added a product field to an order entity, or a cart item entity?
we could control it, does not allow some entity type, it is simple.
2,How would we add images (or other fields) to products for use in the cart or elsewhere?
Developer could use image field, and control it in views, developer could decide which image field is product image and add it to cart views.
3,What would happen if you had a multi-valued product field?
For this field type we only support single value.

4, What if you added two different product fields to an entity?
we use field name control it. Node which have 'sell_price' field name is a product,
If they add several product fields to en entity, the field could use to override the real sell price.
we could add a silver price, a golden price each for different roles, if user have golden role, when he add product to cart, we could use golden price override the 'sell_price' .

g089h515r806’s picture

g089h515r806 CreditAttribution: g089h515r806 commented

We need a big change for ubercart compare with Commerce, we have failed the battle of Ubercart VS Commerce at Drupal7.
If we still use the old method in Drupal8, ubercart will be replace by Commerce in Drupal8.

I have some other idea about the ubercart in Drupal8:
1, replace all cart pane, order pane, checkout pane with Drupal8's block plugin.
2, for page "cart", 'cart/checout','cart/checkout/complete', 'user/%/orders/%',we could build them base on page manager and layout module
3, remove 'cart/checkout/review' page, make checkout simple.
4, move payment button to 'cart/checkout/complete' page, like amazon.
5, Does not support anounymous checkout from Drupal8,
6, use taxonomy field replace country and zone for address, add a address entity, order could reference it.

TR’s picture

TR CreditAttribution: TR commented

You can't do product attributes with fields ... Fields are also a very inefficient/expensive mechanism to use when there is a lot of required data, which is why we use properties on the product node type in D7 (these are now called "base fields" in D8). It's very cheap to have many base fields on an entity even if you don't use them, but having to attach a lot of non-base fields for a physical product is a huge drag on the DB.

The main issue that has to be addressed is #525612: Allow any node type to become a product ... I don't think fields are the answer for that. Allowing any content type to be a product should be achievable in D8 since we can do away with the weird node-type-specific hooks that previous versions of Drupal used.

Most of the things on your list are already being done or in progress for the D8 version of Ubercart - you should look into it more closely and help out if you can. A lot of architectural changes have already been made and are in the works, but the first priority is to make all the pieces functional in D8 (we are pretty close to that right now), then to spend more time re-engineering the pieces.