Allow order types to have no carts

Using Drupal 10 and commerce 8.x-2.x-dev with patch #141 throws the following error:

TypeError: Drupal\commerce_checkout\EventSubscriber\CheckoutCartEventSubscriber::checkRedirectIssued(): Argument #1 ($event) must be of type Symfony\Component\HttpKernel\Event\FilterResponseEvent, Symfony\Component\HttpKernel\Event\ResponseEvent given in Drupal\commerce_checkout\EventSubscriber\CheckoutCartEventSubscriber->checkRedirectIssued() (line 131 of modules/contrib/commerce/modules/checkout/src/EventSubscriber/CheckoutCartEventSubscriber.php).

This patch solves the TypeError issue and small coding standards issues.

✨ Add an option to disable the add to cart message on a certain order type Fixed is in, so CheckoutCartEventSubscriber can now be implemented without overriding CartEventSubscriber.

I had to re-roll #152 to latest dev and test on 2.36.

Test failed because of wrong arguments in CheckoutCartEventSubscriber.
Here's another try.

Instead of altering the session and the order manually, the CartProvider::finalizeCart can be used.

I think this would make it more future proof and simplify the code.

I have noticed that finalizeCart is only called in the event commerce_order.place.pre_transition (and therefore the order->cart is set to false). So the cart flag is true until the end of the checkout process.

With the current patch, functions that depend on the flag being set at the end break. For example the commerce_cart_expiration. Uncompleted order will therefore never expire.

Instead of altering the session and the order manually, the CartProvider::finalizeCart can be used.

I think this would make it more future proof and simplify the code.

Nice idea! CartProvider::finalizeCart also clears a static cache in CartProvider.

@coffeemakr I'm not sure how the test passed but there is an error introduced by the patch in #154
$order = Order::load(2);+ $this->assertEquals(0, $order->get('cart')->value);
And a nit pick for the space on the docblock in the test dropped a space before the /**.

Thank you for the clean-up btw!

@joelpittet: Of course thats correct. Here's a fixed version.

Thank you @coffeemakr, I'll set this back to RTBC

+1 for RTBC

Any idea when this will be merged? We're using this code and it works flawlessly.

I don't understand why this patch became so complicated... Can't we simply handle this via a form state redirect? I don't like the fact that we swap the cart subscriber like this... Which could be decorated/removed on custom installations...
Also, what about Headless sites? Will that cause a redirect too? This should only apply to the form, not every add to cart, even ATC made outside of the form context?

I would expect code similar to this https://www.drupal.org/project/commerce/issues/2907461#comment-15316055 ✨ Redirect to a cart after a cart item is added to the cart Active to handle the redirection... (i.e. an extra submit handler that does the redirect, added by the commerce_checkout module).

I'm wondering if we can't support both redirecting to cart/checkout at the same time? Perhaps the cart module could define a "redirect_to_cart" setting as well?
Or we allow specifying a path to redirect... The only problem might be the required route parameters...

Wasn't the complicated patch also due to the need to suppress the unwanted cart message? We now have this #3317738 so perhaps this could indeed be revisited?

Oh you're right, that could be the reason, so I believe the patch can be greatly simplified.

@jscksick Yes, the most relevant comment would be #125 https://www.drupal.org/project/commerce/issues/2810723#comment-13832755 ✨ Allow order types to have no carts Needs work
where are the changes occurred

All changes have been moved to the commerce_checkout module, and back then we still had added to cart message which is not configurable

now it's needed to swap that, and should be separated

This is the patch without altering the event subscriber. It adds changes to the "Add to cart" form in form_alter. The custom submit handler adds a redirect to the checkout step

1. +++ b/modules/checkout/config/schema/commerce_checkout.schema.yml	(date 1701375521101)
   @@ -5,6 +5,9 @@
   +    checkout_direct:
   

   I wonder if we should rename this to "checkout_redirect", but I'll defer to @rszrama for this.

2. +++ b/modules/checkout/commerce_checkout.module	(date 1701375828203)
   @@ -181,6 +191,24 @@
   +    $order_type_resolver = \Drupal::service('commerce_order.chain_order_type_resolver');
   +    $order_type_id = $order_type_resolver->resolve($order_item);
   +    /** @var \Drupal\commerce_order\Entity\OrderTypeInterface|null $order_type */
   +    $order_type = \Drupal::entityTypeManager()->getStorage('commerce_order_type')->load($order_type_id);
   

   Can't we get the order from the order item here??

3. +++ b/modules/checkout/commerce_checkout.module	(date 1701375828203)
   @@ -181,6 +191,24 @@
   +      $form['actions']['submit']['#submit'][] = 'commerce_checkout_direct_checkout_form_submit';
   

   maybe rename this to commerce_checkout_add_to_cart_form_submit()?

@tBKoT: Thank you for this patch, I'm still wondering if we could include within the same patch the ability to redirect to the cart page as well.. Or perhaps we could simply expose an url to redirect to after adding to cart though it may be problematic due to the route parameters etc...

Ok what about the following proposal:

We add a new checkbox under the "Cart settings" fieldset that says:
[x] Redirect the customer after an item is added to the cart.

When the checkbox is checked, we expose a "Redirection destination" select list where we have 2 options:
* Cart
* Checkout.

The setting is added from the cart module and the redirect is done from AddToCartForm::submitForm() directly.

Note that we don't have to store 2 new settings, but we can default the checkbox to TRUE only if we have a value for the redirection destination.
We can call the setting "cart_redirect" (See screenshots below):

After discussing this with @rszrama on Slack, we think this setting should be moved to other similar settings (such as the "combine" setting), which means putting this setting back as a formatter setting....

Here is the patch that provides redirect to cart|checkout in the "Add to cart" field formatter settings.

Do we really need to recreate an order? I'm confused?
Sure we need all of this??

      /** @var \Drupal\commerce_order\Entity\OrderInterface $order */
+      $order = $this->entityTypeManager->getStorage('commerce_order')
+        ->create([
+          'type' => $order_type_id,
+          'store_id' => $store->id(),
+          'uid' => $this->currentUser()->id(),
+          'cart' => FALSE,
+        ]);
+      $order->addItem($order_item);
+      $order->save();
+
+      // Add the order as a completed cart to allow anonymous checkout access.
+      // @todo Find a better way for this.
+      if ($this->currentUser()->isAnonymous()) {
+        $this->cartSession->addCartId($order->id(), CartSessionInterface::COMPLETED);
+      }

Btw, the idea was to go with a single setting. We add a "redirect_destination" setting, and the "redirect" checkbox is checked if it's not empty.
Also, let's use #states so we don't display the select if no redirect destination is set?

This patch adds only one setting to the field formatter - "redirect_destination".
The "Destination" field uses #states and will be shown when the "redirect" checkbox is checked.
The default value for the "redirect" checkbox depends on the "redirect_destination" value.
Also, there is a custom validation method to clear "redirect_destination" when the "redirect" checkbox is unchecked.

Add fixes to coding style and tests

@jsacksick
We need to create a new order instead of a cart, as the main idea in this issue is to avoid cart creation and go to the checkout step directly
There is a new patch with a check if the user already has the "draft" order for the selected item to avoid duplicates and use existing order for checkout.

The last patch in #180 was incorrect because has a creation of a new order but the variable is not set in the file "AddToCartForm.php".

The next patch solves the problem.

ONLY FOR COMMERCE 3.0.x
Patch 181 does not apply to (default) 3.0.x. I attach here a new one, no real code changes, just the indexes.