New answers tagged

0

You cannot work with those classes like with drupal´s fieldable entities There is this nice little hint in your debug output that shows which class is used e.g Drupal\commerce_order\Adjustment So i dont know commerce plugin but i can look into the source, i just searched for the classes in the online available source-code and see that Adjustment has the ...


0

This is a common use case in Commerce, and as you've suggested, it's resolved not by using a single variation per combination but through custom fields added to your line item type exposed on the Add to Cart form mode. Your primary challenge will be determining which options should be available for which product, as in the case of a particular mug not being ...


0

That setting means the customer may have multiple profiles of that type assigned to their uid, not that every profile reference field can itself be used for multiple value references. That said, I'm not aware of a field in Commerce Core called customer_profiles. Is this something custom? You might just need to update its definition to be able to put multiple ...


1

You are right about race condition, but onReturn does not modify order at all This is what happens in the background: the commerce_payment.checkout.return route on commerce payment module is called which at first it let order payment gateway plugin to create an payment for order then no matter what happens in the onReturn method of plugin order checkout ...


0

Did you ever find the issue with this? I am having the same problem, my cart used to show the product name under item and now it's showing "Price £9.99".


1

I think you would do it like this (if I'm understanding your scenario correctly): {{ node.field_price_value.entity.field_price.value }} Also this question has been asked and responded to before, you may find this helpful: Twig get value of field in entity reference Good luck!


0

A product attribute in Drupal Commerce only ever refers to a field on the product type (Commerce 1.x) or product variation type (Commerce 2.x+) that differentiates one variation from another on a display. These fields are always explicitly declared - in Commerce 1.x using the checkbox on the field configuration and in Commerce 2.x using the attribute ...


-1

As I thought, I've ended up to create a patch for this feature. Reminder, this not a hotfix, it's specific for my website. diff --git a/modules/cart/src/CartManager.php b/modules/cart/src/CartManager.php index 3b27ae77..b81db592 100644 --- a/modules/cart/src/CartManager.php +++ b/modules/cart/src/CartManager.php @@ -108,7 +108,8 @@ class CartManager ...


1

This patch works beautifully for me, with both Display taxes of this type inclusive in product prices. under tax types and Prices are entered with taxes included. under store unchecked.


0

That issue is resolved with the latest dev version of Address, see https://www.drupal.org/project/address/issues/3126733


Top 50 recent answers are included