Price Rule base on product additional field

After some mentor and guidance we can help maintain it for behalf of client as part of working solution

Hi Patryk, I find it a bit hard to follow and understand exactly what you are trying to accomplish. Can you give a specific example? e.g. a specific product with the attributes/options that you want to make available to customers, and the expected calculated pricing.

Yes. I take example from this: https://fineartamerica.com/featured/soft-blue-gradient-cubes-elisabeth-f...
As you can see:
- one single product
- field type change fields
- fields can be 1 to 6
- pricing change on options

Having variation in one product won't be possible.
I fix Product Builder but ths or native fields for customization (/admin/commerce/config/order-item-types/default/edit/fields) isn't consider into pricing.

We only see this as major obstacle and clear that this type of custom field (I can write ajax to send it into controller if that something out of scope for this module) should be adjustable by this module. Other Customization aren't available as 7.x have that feature

I will add example pic where field "TEST FRAME OPTION AS VIRTUAL WITHOUT SKU" don't have any engine to adjust pricing when we clearly need that. ( https://www.drupal.org/files/issues/2023-10-13/Zrzut%20ekranu%202023-10-... → )

What in one line will this add to module and whole range on new solutions:
✅ Pricing rule base customer customizable product (native commerce order items field)

Editable fields - they aren't supported and the data isn't save into cart
Product Builder - as a fields that don't change anything, only add option to separate list of fields into separate entity. Removing it will remove crucial information on order entry.
Customizable products - they exist on 7.x , we should downgrade to have same function as mentioned in term of fields etc.
Pricing can be handled only when having variant - no other option is available. There is more than 3M variants in this scenario

@krystalcode Can you only check if this is in context of this module? Do you know how I can achieve this? Need little guide :)

Issue is discuss there that is releated to this : https://www.drupal.org/project/commerce/issues/2897226#comment-15277336 ✨ Allow order item fields to modify the product price on ajax Active

Here are the different solutions that you have to review.

Order item fields

This is the solution that I understand you have been exploring most. You first need to understand how Drupal Commerce works.

An order item field requires an order item entity that is attached to, and an order item entity requires a parent order to be attached. The usual flow is the following:

- User browses the catalogue pages, may view default prices on the listing pages.
- User visits an individual product view page, and explore the different options i.e. select attributes and view the price for the selected attributes.
- User adds the product to the cart.

Until the user clicks the Add to Cart button, there is no order and there is no order item. This is because Drupal Commerce allows for a user to have multiple carts simultaneously of different type each. This is not a very common case, but Drupal Commerce needs to provide a generic framework that satisfies such need.

This means that you cannot calculate product prices based on order/order item data because prices need to be displayed before the order exists. This is why you cannot find such solution out-of-the-box and - to my current knowledge - in other contrib modules.

Such as solution could be implemented by implementing improvements and integration between the following two modules:
- This module ( Commerce Price Rule → )
- Commerce Cart Advanced → .

It is not a simple solution though and it will require significant effort, including architectural discussions first. Being the maintainer of both modules, I do not currently have any sponsorship for something like this so don't hold your breath.

Product variations

If you want the solution with the least development effort and best supported and battle tested features out-of-the-box, you need to go with product variations. In the products shown in the URL and the screenshot that you shared, I do not see anything that could be problematic using variations/attributes and this module - other than the potential large number of variations.

For defining the price for every combination of attribute values, there's two options. If they differ a lot and there's no logic to calculate them, they have to be added manually.

Alternatively, with Commerce Price Rule you can set the prices at the attribute level if the following logic satisfies your pricing model.

- Define attributes e.g. size, canvas type, frame etc.
- Add a price field on each attribute.
- For each attribute value you will need to add the extra price that this value adds to the base value of the product.
- Add and configure a price rule using the attribute-based calculation.
- When the user selects attributes on the product page, this module will calculate the final price as the sum of the base variation price plus all attribute prices.

For example:
- Base variation price $10
- Print size 17.5x20 costs $15, while 26x30 costs $20
- Canvas wrap 1.5" costs $5 while 5/8" costs $2
- Frame CF6 costs $12 while CFL3 costs $18

So when the user selects 26x30, 1.5" and CFL3, he will get the price $10 + $20 + $5 + $18 = $53.

If that works for your pricing strategy, that should work out-of-the-box with product variation/attributes and this module.

If you have too many variations in total (for all products) in the database, that's most likely not a problem - even millions. If you have hundreds of variations on the same product, then that could potentially cause performance issues.

For managing the large number of variations per product, you can look for a solution (module or custom code) that can automatically generate the variations for you, one for each possible combination of attributes - if that's your use case.

Again, from the link/screenshot that you shared, I do not see any problems with using attributes/variations, but if you have an example of cases where you would have too many options, please share.

Product options

As mentioned in the first solution, if you still do not want to have a variation for each combination of options, storing them in the order item is problematic. You would want to store them at the product/variation instead. There is the Commerce Option module that was developed so that for each parent product you only have one child variation and through that variation you make available the different options on the product page. Similarly to the solution with the attributes described above, you can define the price that each option adds to the final product value, when selected. When the order is placed, the selection of options is stored in a field on the order item.

However, this module was not fully tested and used on production and that's why I never published it on Drupal.org. If you decide to explore that path you should expect to encounter issues and/or to some development effort to make it work for your case.

I hope this helps.

Order item fields

Yes, you have right in one way to do it - the proper one i core.
"Until the user clicks the Add to Cart button, there is no order and there is no order item." <- there is product price and that we need change base on product options

What I see is simpler way for now in this steps:
1) alter form adding ajax callback : " https://www.drupal.org/docs/drupal-apis/javascript-api/ajax-forms → "
This way we get any change or fields into our controller.
(This I Don't know how)
2) Update price base on field and value
I create sample module to do it on Query and Page Refresh and work as designed
https://github.com/Art-Decor/commerce_pricing_options (some start but manage by front parameters, your module use resolver in better way)
Need to use Resolver on ajax call.
3) Force refresh variation template
JS call that variation is change even if not. Only to re-load template
(I do full page refresh but price is properly calculate and added to product base pricing)

This way we use composition on form to add capabilities by module (no need core changes) and have now calculation base on order item field value.

Product variations

"large number of variations" - milions aren't even possible to be properly handled by Commerce and Drupal due to some issue in optimization. That's why it isn't possible right now. That's why I'am here as was too shock how much it will needed.

Product options

I checking this and this is solution that need you to add as "you" on module in dev branch:
https://github.com/krystalcode/drupal8-commerce-option
We tested it and work as good as needed. Issues that are connected to it (but impotant and small one to fix):
- no ajax on changing attributes (feature is override add to cart with ajax capabilities but for now it work without)
- need option visible as duplicate to properly working when adding to cart
- pricing is added on second product when only first one should get updated (that's only one critical to be fixed - two products with customization aren't separated when price is added ;/)
- product options is cloned to order data? - my understand is that using proper commerce api we have it save as clone and not reference (older order won't change data after removing product options). That should be working in module properly, only asking.
- public it on module page with 7.x as 8.x? as dev branch but like to add fixes and work on it. More people will help maintain

Over that - module you provide is what we looking and plenty people too so don't hesitate and public as you (on " https://www.drupal.org/project/commerce_option → ") , we are glad to test it and help maintain it.

Fixed issue with pricing on pull request - https://github.com/krystalcode/drupal8-commerce-option/pull/13. Will be easier to add it into 8.x module where I can contribute fixes and help maintain. Module need some documentation too.
This publication will resolve this issue and on proper place will be fixes and isuess provided

Thanks for testing, I will try to upload it on Drupal.org at some point this week - when time permits.