Add to cart different variations of same product not working

Do you mean:

1. 3 or more quantity of one variation
2. 3 or more variations of different products
3. 3 or more variations of the same product

Hi, I've same issue.

Hi, I think is something connected with form id changed by the module via ajax.

Here's my use case:
- when pages are refreshed via http change you can add as many variations as you like
- when you change product variation via ajax you can add only one variation, each time you try to add another variation the system remove the last added.

This is the case:
- view product
- add variation to cart (you can add as many variation of this type as you like)
- change variation via ajax
- add this variation (you can add as many variation of this type as you like)
- change variation via ajax
- add this variation: the system replace the last one with this

If you refresh the page you can restart from the first step

The best way to debug this is to write a FunctionalJavascript test to reproduce the bug.

Thanks Matt. I will whip up some tests.

By the way. After debugging I found that during the third time it is not creating a new order item. But using the last (second) one. And it gives the sense that the lastly added item is replacing the second last one -- which is the bug.

Hi subhojit777, thanks for your suggestion.
As you noticed the problem is linked with new order items. It seems that changing the form via ajax, in some way, doesn't reset the order_item_id and the order item uuid.
At the moment I've done a dirty trick. I override in your module the submitForm method and reset inside of it the keys.

This my dirty code (in AjaxAddToCartForm.php):

  public function submitForm(array &$form, FormStateInterface $form_state) {
    //$form_state->cleanValues();
    $this->entity = $this->buildEntity($form, $form_state);
    $this->updateChangedTime($this->entity);


    /** @var \Drupal\commerce_order\Entity\OrderItemInterface $order_item */
    $order_item = $this->entity;
    /** @var \Drupal\commerce\PurchasableEntityInterface $purchased_entity */
    $purchased_entity = $order_item->getPurchasedEntity();

    // Reset the order item id and set new UUID
    $order_item->set('order_item_id', null);
    $uuid = \Drupal::service('uuid');
    $uuidData = $uuid->generate();
    $order_item->set('uuid', $uuidData);


    $order_type_id = $this->orderTypeResolver->resolve($order_item);
    $store = $this->selectStore($purchased_entity);
    $cart = $this->cartProvider->getCart($order_type_id, $store);
    if (!$cart) {
      $cart = $this->cartProvider->createCart($order_type_id, $store);
    }
    $this->cartManager->addOrderItem($cart, $order_item, $form_state->get(['settings', 'combine']));
    // Other submit handlers might need the cart ID.
    $form_state->set('cart_id', $cart->id());
  }

Sorry, but I'm not a debugger and I'm not able to create patches.
I hope my code can be usefull and you can resolve the bug asap, your module is great! And I need it for a project of mine ;-)

Not a problem at all. Thanks for the effort.

Added the tests https://github.com/subhojit777/dc_ajax_add_cart/commit/5cf062b42baaded36...

@l_v If this is blocking your project you can upload a patch of the code in #9 and then use the patch using composer-patches. Since this is a workaround so it won't be committed to the module. I am looking for the core problem. Commits will be made after identifying the core problem.

After more debugging I figured that the reason that new order item is not being created is because the form build id is not getting refreshed. Although, as per the code RefreshPageElementsHelper::updateFormBuildId() should be called every time a product is added to cart, but it looks like it is using the stale build id - when the variation is changed the second time. I am not sure why it is happening only the second time. I think I have to dig into the variation switcher as well. Maybe it is not refreshing the add to cart form build id - which it should - and it relies on the page reload to get the new build id, and it fails when the add to cart form button is ajaxed. I will ask Bojan again for some hints.

The reason behind the bug occuring the second time because the ajax add to cart form build id is updated successfully only once, after a variation is added to cart for the first time. In subsequent requests, the build id is not updated, i.e. RefreshPageElementsHelper::updateFormBuildId() is not called.

      $response->addCommand(new UpdateBuildIdCommand($form['#build_id_old'], $form['#build_id']));

I added this inside ProductVariationWidgetBase::ajaxRefresh() but it is still not working. RefreshPageElementsHelper::updateFormBuildId() is not getting called either the second time.

I tried fixing this using commerce_product.variation_field_renderer's replaceRenderedFields(), but no.. still not working. I am running out of ideas here. But I am quite sure that this is happening due to stale form build ids.

But I am quite sure that this is happening due to stale form build ids.

Actually. I am not entirely sure on that. To prove my assumption, I had put a UpdateBuildIdCommand() inside ProductVariationWidgetBase::ajaxRefresh(), after the event dispatcher - but it didn't work.

I have a custom AJAX cart module which I made before dc_ajax_add_cart for D8 was released and I'm having exactly the same problem.

The problem is caused by the way Add to Cart form works.
It was not intended to be submitted multiple times; thus, it's not AJAX compatible by it's nature.

The AddToCartForm class inherits ContentEntityForm class which stores entity object (order item in our case) as a property.
Drupal serializes form_state while saving form cache and so it stores AddToCartForm object instance with existing order item entity inside.

As a workaround, I've added the following submit callback to a submit button:

  $form_object = $form_state->getFormObject();
  if ($form_object instanceof AddToCartForm) {
    /** @var \Drupal\commerce_order\Entity\OrderItemInterface $order_item */
    $order_item = $form_object->getEntity();
    if (!$order_item->isNew()) {
      /** @var \Drupal\commerce_order\OrderItemStorageInterface $order_item_storage */
      $order_item_storage = \Drupal::entityTypeManager()->getStorage('commerce_order_item');
      $form_object->setEntity($order_item_storage->createFromPurchasableEntity($order_item->getPurchasedEntity()));
    }
  }

This is not a correct way to fix this issue (since that's just a hack which replaces stored object), however, adding to cart will work.

I've rolled #9 into a patch.

Can confirm this resolves the issue.

See attached

I didn't post #19 as a patch since it's not a correct way to fix an issue. Please remember it's a hack.

I am having the same issue. Patch at #20 solved my problem. I'm currently using this patch and I am able to successfully add different variations of the same product via the ajax add to cart button.

See #21.

The patch at comment #20 comes from #9 not #19. Please read carefully.

Similar to #19, I'm facing this issue with custom ajax functionality. I agree with the assessment about the stale entity that is associated with the form. And that goes back to how AddToCart form works, as it's not built for ajax (in the way commerce panes are for example). My sense is that a more durable solution is to rebuild/refresh the form as part of the ajax operation. That would refresh the build_id or replace the associated entity. I'm not sure what is required to achieve that exactly. But it seems @subhojit777 was trying to find a fix in that direction.

If anyone can provide guidance on how that is done with ContentEntityForm or another, I would be happy to work on it.

The patch at #20 works for me - thank you for submitting

My colleague posted a fix for this to commerce over in #3232344: Make it easier to ajax submit the default cart form, do not re-use order items since you can run into this problem if you make the add to cart form submit using ajax not using this module.

It's a simple two line fix for commerce, or it could be incorporated here in the middle of the code in #20 rather than the uuid specific code that's there at the moment if desired.