Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.The commerce checkout flow appears to be resolved only the first time a cart enters checkout. I believe the resolved checkout should be reset once the products in the cart/order change.
I have created an entity trait that requires an extra step during checkout. This trait is attached to a product variation and a custom CheckoutFlowResolver scans through the purchased entities, looking for this field; returning a different checkout flow if the field is detected. (I think this is a valid use case unless there are better options?)
Reproduce:
- Add a regular product to the cart
- Enter checkout
- See the default checkout flow
- Leave checkout (navigate to catalog)
- Add the special product to the cart
- Enter checkout again
- Still see the default checkout flow, where the custom checkout is expected.
The other way around; if the product is on the initial cart and removed later, the checkout is stuck in the custom checkout flow instead.
I'd like to provided a patch, but I do not know where this reset should be done. Since the checkout is stored in the order, I suppose an order event subscriber should clear the checkout flow if order items, quantities, prices, more(?) change?
I don't think a cart event subscriber would suffice as orders can exist without a cart.
| Comment | File | Size | Author |
|---|---|---|---|
| #18 | 3083384-18.patch | 1.81 KB | jungle |
| |||
| #14 | 3083384-14-resolve_checkout_flow_on_order_change.patch | 1.81 KB | Renrhaf |
Comments
Comment #2
Neograph734This should be a good start.
Comment #3
Neograph734Hmm, I suppose I should have subscribed to the OrderEvents::ORDER_ITEM_DELETE event as well. But let's see for now.
Comment #6
Neograph734Adding the event subscriber in services, subscribing to order item deletion and actually saving the order after the event fired.
Comment #8
Neograph734Seems like is misinterpreted the OrderEvents::ORDER_ITEM_INSERT and other events. Those trigger when the order item entity is created/updated/deleted. Instead, this patch should respond to changes on order items attached to orders; similar to CartEvents::CART_ENTITY_ADD, CART_ORDER_ITEM_UPDATE and CART_ORDER_ITEM_REMOVE.
However I feel this should not apply only to cart orders. There could be situations where an item is sent straight to checkout. So I suppose the Cart events should have a similar event within the order, and then this EventSubscriber should use those events instead.
Comment #9
Neograph734I suppose we need some way to know when the order contents have changed. Created a new issue for that.
Comment #10
Neograph734Thinking of it, we could also use the Order::recalculateTotalPrice() method to trigger the CheckoutFlowResolver? That would also include changes that happened as the result of an order adjustment. Theoretically there are so many things where a developer might expect the checkout flow to be reset that I am not sure where to draw the line...
Comment #11
bojanz CreditAttribution: bojanz at Centarro commented#3086876: Allow handling order changes on order level instead of in the cart is a huge refactoring, we can't block a bug fix on it.
An order presave subscriber could detect that an order item has disappeared or was added at least. For updates we'd still need an order item presave subscriber.
Comment #12
Neograph734Thanks for the reply, but then what should be the criteria for clearing the checkout flow? For instance would changing the profile also justify a checkout reset?
UPDATE
I guess changing alterations and profiles should not reset the checkout flow for as they can be set during a checkout flow.
Using pre save would be undesirable as well because we would need all kinds of exceptions for changed/completed dates etc.
I think I'll proceed with the events introduced in #3086876: Allow handling order changes on order level instead of in the cart.
Comment #13
Neograph734Let's bring this in line with resetCheckoutStep for now by adding it to the cart manager and then revisit after #3086876: Allow handling order changes on order level instead of in the cart. This should (for now) be good for most of the use cases.
Comment #14
RenrhafThanks @Neograph734, patch rerolled for 8.x-2.x
Comment #15
RenrhafIn my use case, I have products that can be either bought or rented. If rented items are in the cart, the checkout flow contains an additional step : signing contracts. I needed to refresh the checkout flow whenever an item is added/removed from the cart. The patch works great!
Comment #16
jsacksick CreditAttribution: jsacksick at Centarro commentedYou can't RTBC your own patches :).
Comment #17
jsacksick CreditAttribution: jsacksick at Centarro commentedSorry, missed that this was a reroll.
Comment #18
jungleRe-rolled, keep RTBC
Comment #20
jsacksick CreditAttribution: jsacksick at Centarro commentedConsidering that we're doing the exact same thing for the checkout step, I'm fine with this approach, perhaps we could have moved the logic in the same method and rename it, but this is also fine. Committed, thanks!