This is something the D7 commerce_order_types module had, and it makes sense. Some order types shouldn't be carts, because a site will send the user directly to checkout (or perform the checkout directly on the product page). Trainings, for example.
How to use the patch (from #126 on)
1. Apply the patch.
2. Go to the order types admin screen: /admin/commerce/config/order-types/
3. Click edit on the order type that you want to enable direct checkout.
4. Check the box for direct checkout at the bottom of the edit screen.
5. Save.
Comment | File | Size | Author |
---|---|---|---|
#180 | 2810723-180.patch | 15.45 KB | tBKoT |
#172 | cart-redirect-select.png | 18.65 KB | jsacksick |
#172 | cart-redirect-checkbox.png | 11.16 KB | jsacksick |
#160 | interdiff_156-160.patch | 1.01 KB | coffeemakr |
#160 | 2810723-160.patch | 11.07 KB | coffeemakr |
|
Issue fork commerce-2810723
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
Londova CreditAttribution: Londova commentedSounds good.
We need such for selling "virtual goods", where is a single line per order.
Comment #3
scotthooker CreditAttribution: scotthooker at TES Global commentedLooking into this a bit more. I guess the start would be to supply a new version of the add to cart form.
Comment #4
bojanz CreditAttribution: bojanz at Centarro commentedWe would need a setting on the order type.
The cart provider would not provide carts of that type (this might break a few things).
The add to cart form would check the setting, and rename the submit button to Checkout instead of Add to cart, go to checkout directly.
Comment #5
scotthooker CreditAttribution: scotthooker at TES Global commented- this is a contrib solution - https://github.com/scotthooker/commerce_checkout_direct
I'll take a look at your suggestions for it in core.
In addition it would need to not display an item added to cart message.
Comment #6
mglamanSo one problem
Do we only show this setting, this modification, if
commerce_checkout
is enabled?EDIT: IMO this is kind of squirrely. I'd almost rather defer to https://github.com/scotthooker/commerce_checkout_direct which can be used out of the box by pointing a variation type to that order item type and "it just works", or it at least provides sample code. It's something I wrote then handed to scotthooker which he graciously packaged up nicely :)
Comment #7
bojanz CreditAttribution: bojanz at Centarro commentedThe linked module doesn't resolve the main issue, which is that you simply don't want to have a cart in certain cases (whatever is bought in one go, trainings, donations, etc).
Plus, we definitely need such behavior to be attachable to existing order types, you can't force people to use a single order type just to get this.
Comment #8
scotthooker CreditAttribution: scotthooker at TES Global commented"The linked module doesn't resolve the main issue, which is that you simply don't want to have a cart in certain cases (whatever is bought in one go, trainings, donations, etc).
Plus, we definitely need such behavior to be attachable to existing order types, you can't force people to use a single order type just to get this."
Absolutely - I could hear you saying that as I wrote they YML for the order type. Its entirely restrictive and removes the flexibility of having multiple order types. It wants to be an option on the order type so its generic.
HOWEVER, this will do for now and keep this feature request ticket open whilst I look at a more generic solution.
Comment #9
scotthooker CreditAttribution: scotthooker at TES Global commentedhttps://github.com/drupalcommerce/commerce/pull/597
Comment #10
mglamanThe more I think about this, it's more of a contrib module. We need something which adds third party settings to an order type and allows it to skip carts. At the same time, it could provide a "direct to checkout" form alongside the event subscriber.
We need a "bridge" module which is aware of Cart and Checkout, without actually coupling those two together in core, I feel like.
Comment #11
scotthooker CreditAttribution: scotthooker at TES Global commentedJust feels a bit out of place to have to install contrib to skip over a feature of core. I want to skip the checkout. Should be do-able from core?
Comment #12
bojanz CreditAttribution: bojanz at Centarro commentedI have no doubt that this feature should be in core.
I've used the equivalent commerce_order_types feature in several D7 projects.
I'll try to figure out a clean way for this once shipping is done (so, february most likely)
Comment #13
scotthooker CreditAttribution: scotthooker at TES Global commentedHappy to review when you have sir.
Comment #14
mglamanCommerce product owns nearly all the components we need. What if Checkout provided its own form like add to Cart that went straight to checkout?
Comment #15
JMOmandown CreditAttribution: JMOmandown commentedI think it's important to be able to remove the cart module all together under this scenario which would mean varying away from the standard add to cart button and overwriting or resetting the defined route to get to the checkout page directly. With that said, it almost makes sense based on the comments to move towards what used to be the old add to cart by url module. I would do something like the following to give the most flexibility to the end user:
https://www.drupal.org/sandbox/jmomandown/2844445
Note this was put together rather quickly and is not up to standards nor full featured.
Comment #16
mglamanI think the proper approach isn't an order type setting, but something of a direct to checkout button, provided by the checkout module.
The direct to checkout would add the current item to a new order, with specified quantity and bring them immediately to checkout. There'd be no cart, combining of order items, etc. Just make a new order and bring them to checkout to finish purchasing what they selected. This would be a new formatter, like the add to cart formatter. It'd help provide a similar "one click purchase" that Amazon provides.
Comment #17
BerdirGoing to give this a try. I'll start with adding an option to the existing formatter/form then, the alternative is to copy/extend/refactor the formatter, lazy builder service and form. While that makes sense, e.g. to get rid of the cart dependency, checkout right now actually depends on cart anyway, so it's not like you can have a checkout and not install the cart module at all.
Comment #18
BerdirSome things I noticed while working on this:
* not sure if a static to ensure a unique form ID is reliably (what if a new product is added to a list between displaying and submitting a form?), but also not sure about a better alternative, so far I only had to deal with pre-configured multiple forms like blocks. Maybe product id + settings or so, even if that would exist multiple times on a page it wouldn't matter as it actually would be the same form then.
* the settings summary for combine is pretty long, often that's not full sentences but just keywords.
* the combine setting doesn't make sense with direct checkout as it is guaranteed to be a new order that doesn't have anything in it yet.
* AddToCartForm obviously makes no sense for a form/formatter that doesn't add something to cart. but we can still refactor things.
* The standard question when not using cart is how to deal with access for anonymous users, related to #2824320: Checkout access is incomplete commerce 1.x now has a hook for this I think to be more flexible but then we probably need to store this in a separate session key or support a allowed-access-but-not-cart default session key.
All those things aside, doing this with a formatter setting is pretty trivial, at least for authenticated users. For anonymous users, this currently results in an access denied after clicking the button.
Will work on tests tomorrow hopefully. Or rework it when I get feedback to got with a different approach.
https://github.com/drupalcommerce/commerce/pull/669
Comment #19
Berdirhttps://github.com/drupalcommerce/commerce/pull/669 is now passing.
I added tests for authenticated and anon users. Anon users currently works with a similar trick that I often used in projects in 7.x, I added the order id to as a *completed* cart.
As commented in IRC, dependencies are tricky, as the formatter now really requires commerce_checkout and cart does not (can't because checkout requires cart), I had to add commerce_checkout to the cart browse tests.
There are still various issues and it is a bit messy, but it seems to work quite well, so I think ready for a review.
Comment #20
dubcanada CreditAttribution: dubcanada commentedWhat about if you don't want to go to the checkout page?
Say you want to use the order types for something that should never be able to checkout (example wishlist or something).
Comment #21
bojanz CreditAttribution: bojanz at Centarro commented@dubcanada
Wishlists should be their own entities (in fact, commerce_wishlist already implements its own entity type).
Entities are quick & cheap in D8 and there's no reason to hijack existing entity types.
Comment #22
dubcanada CreditAttribution: dubcanada commentedOkay.
Is there any use case where a user would not want to be sent to the checkout form? If not I reviewed #19 and it does what it says it does.
Comment #23
BerdirPatch against beta7 if someone needs that.
PR has some test fails but a review of the general approach would be great before I focus on fixing the tests.
Comment #24
smazWith this approach:
* What happens if the user then visits /cart? It appears they'd still be able to view their cart, correct?
* What happens if the user adds a second item to their cart?, i.e. goes from checkout back to the store
@scotthooker took care of that with his module:
https://github.com/scotthooker/commerce_checkout_direct/blob/master/src/...
Thinking of the use case of buying one of a set of options, like a subscription (1 month, 3 month, 12 month etc), or web hosting packages & so on.
* What happens for carts that don't use products?
Not sure this is in scope / up for consideration yet, but it's possible. https://www.drupal.org/node/2853280
Comment #25
BerdirThis currently does one simple thing. It creates a new order, creates an order item in there for the product and goes to checkout.
* Multiple products isn't supported
* it doesn't do anything about /cart
* Non-product order items isn't relevant because this is a product formatter, so there is a product.
Comment #26
ptmkenny CreditAttribution: ptmkenny commentedI re-rolled the patch for 2.0, but after applying, when I try to add a product to a cart, I get:
I'm guessing this is related to these notices:
Comment #27
ptmkenny CreditAttribution: ptmkenny commentedOk, here is a working patch for Commerce 2.0.
Minor changes I had to make to Berdir's patch:
$order_type is now $order_type_id.
drupal_set_message() is no longer used to show the "cart added" message, so that part can be deleted.
How to use this feature (reminder to myself)
1. Apply this patch.
2. Go to the Product Types -> Edit Display page for your product type that you want to skip the cart for (/admin/commerce/config/product-types/my-product-type/edit/display).
3. Look for the "Product Variations" field, the format of which should be "Add to cart" form. Click the little gear icon on the right.
4. Check the box for "Skip cart" and press "Update".
Comment #28
sorabh.v6Comment #29
sorabh.v6Comment #30
sorabh.v6Comment #31
mglamanThis should still use the cart provider. Cart should be true, so that checkout works.
Why is this marked completed?
This adds a hard dependency to the checkout module. We really need the checkout module to just provide a "direct to checkout" formatter and form. The issue is how do we extend Cart or prevent duplicated code.
Comment #32
sorabh.v6Comment #33
BerdirThanks for the review @mglaman.
In my use case, I did *not* want users to have a cart, but it's currently not possible to have a checkout without the card module. Or at least it wasn't in march when I worked on this. That's why I used cart FALSE and added it as completed, that's the old trick to allow anonymous users checkout access. See #19, which also explains the dependency thing.
Maybe the cart behavior should be a setting? But in most cases I think you don't want a cart with a direct-to-checkout feature?
Comment #34
BerdirComment #35
mglamanWe're dancing on the issue where checkout and cart are too coupled. I think the solution is a checkout formatter which, unfortunately, has to mimic part of the cart form. Maybe we can move the order item from (AddToCartForm) to order as order item form? Not sure. Moving that into two formatters (Add to Cart, Direct to Checkout) helps solve part of the problem. Checkout access can then only care if it is a draft order. Maybe allow cart to interject.
Comment #36
ptmkenny CreditAttribution: ptmkenny commentedRe-rolled #27 for Commerce 2.2.
Bad patch, ignore.
Comment #37
ptmkenny CreditAttribution: ptmkenny commentedRe-rolled #27 again for Commerce 2.2 (previous patch had an unncessary file).
Concerns in #31, #33, and #35 have not been addressed; this re-roll is simply to supply a patch that can be used with the latest version of Commerce to keep sites already using the (needs work) patch up-to-date.
Comment #38
ptmkenny CreditAttribution: ptmkenny commentedAs an example of a different approach to solving this,
@steveoliver wrote an article about using an EventSubscriber to go direct to checkout.
Comment #39
mygumbo CreditAttribution: mygumbo commentedDo you have the patch for Commerce 2.3? Thanks for working on this.
Comment #40
xSDx CreditAttribution: xSDx at Websolutions Agency commentedAdding patch for 2.4
Comment #41
streger CreditAttribution: streger at Websolutions Agency commentedThanks @xSDx
It works as expected on Drupal 8.4.5 and Commerce 2.4 when I enabled 'Skip cart, create a new order and immediately start the checkout process.' on field views and field display formatter.
Comment #43
shaalPatch #40 works great (Drupal 8.4.5, Commerce 2.4), Thank you!
I used it for a license+subscription product. A "Checkout" button appears instead of "Add to Cart".
Clicking on "Checkout" button loads the checkout page.
It took me some time to find the specific comment that explains how to make 'skipping cart' work (after applying this patch).
To save you some time, here's how you enable the skipping cart feature -
Comment #44
shaalThe patch #40 was working on Drupal Commerce 2.4,
but now it's is failing with Drupal Commerce 2.5
:(
Comment #45
Maxime Gilbert CreditAttribution: Maxime Gilbert as a volunteer and commentedAdding patch for 2.5.
Comment #46
shaal@Maxime Gilbert, Thank you for the patch #45! It worked as expected on Drupal 8.5, with Drupal Commerce 2.5
Comment #48
Maxime Gilbert CreditAttribution: Maxime Gilbert as a volunteer and commentedCorrected redirection pattern on
AddToCartFormTest::testSkipCart()
:Comment #49
Maxime Gilbert CreditAttribution: Maxime Gilbert as a volunteer and commentedUpdated patch: I have forget one another pattern test.
Comment #50
Maxime Gilbert CreditAttribution: Maxime Gilbert as a volunteer and commentedAgain, wrong patch: the redirection URL is not the same for authenticated user and anonymous user:
checkout/{order_id}/order_information
VScheckout/{order_id}/login
.Comment #51
joachim CreditAttribution: joachim at Torchbox commentedThis seems like an odd place to put this setting.
I would have expected it to be a property of the order type. Or the product variation type, if more granularity is required.
We have these bundle entities which can easily hold configuration, so it seems weird to bury functionality in the widget settings.
Comment #52
Maxime Gilbert CreditAttribution: Maxime Gilbert as a volunteer and commentedI totally agree with @joachim even if in some cases it make sense to handle the form displayed from the formatter settings. It allows us to choose what to display according a particular context.
But we don't really have the choice and the need to require the Cart module is very weird when we don't use any of its features in any way.
The Cart module should not be a dependency of the Checkout one. But this will require to refactor some part of the Commerce module more than this patch do it. We should have the choice of both an "Add to cart" form from the Cart module and a "Direct checkout" form from the Checkout module. Maybe for an another version.
I needed the "Direct checkout" feature very quickly so I ported the patch from 2.4 to 2.5 (all thanks go to @Berdir, @ptmkenny and @xSDx).
Comment #53
mlecha CreditAttribution: mlecha commentedWondering if the patch in #50 can be applied cleanly to the new release of Drupal Commerce 2.8 on Drupal 8.5.6?
A longterm solution for skipping the cart would be ideal.
Comment #54
iamdroid CreditAttribution: iamdroid commented@mlecha, #50 works for me on 2.8/D8.5.6
Comment #55
usarthur CreditAttribution: usarthur commented#50 also worked on 2.7/D8.5.3
Comment #56
shaal#50 patch failed for Drupal 8.6.1 + Commerce 2.10
Comment #57
zenimagine CreditAttribution: zenimagine commentedThe "Add to cart" button should be replaced by "Buy" and deactivate the quantity
Comment #58
willeaton CreditAttribution: willeaton commentedPatch needs rerolling for commerce 2.10. The patch no longer applies however worked fine previously
Comment #59
mlecha CreditAttribution: mlecha commented@zenimagine Is your suggestion is possible with Drupal 8.6.1 + Commerce 2.1.0, or you're just making a suggestion of future development for Drupal Commerce?
Should it be possible to adjust patch #50 for Drupal 8.6.1 + Commerce 2.1.0?
There doesn't seem to be another solution for direct checkout functionality.
Comment #60
idiaz.ronceroYep, it's not working anymore.
I also think this functionality should be on Commerce's core or a contrib module. It is a really common case. In my example, i'm selling different kinds of subscriptions and the typical user will only buy one, so the cart page is an completely unnecesary step.
Comment #61
joachim CreditAttribution: joachim commentedThis line should be in the condition block for using a cart, as it's pointless if we're not using a cart.
Comment #62
BerdirNo it is not pointless. It is required to give anonymous users permission to be able to go through the checkout of that order.
It's not a nice solution, it's basically something I also did in D7 projects, by putting direct-checkout orders into the cart order list as completed.
Comment #63
willeaton CreditAttribution: willeaton commentedIve re-rolled the patch so at least it doesn't fail now
Comment #64
shaalConfirming #63 patch is working on Drupal Commerce 2.10 with Drupal 8.6.2
Thank you @willeaton
Comment #65
joachim CreditAttribution: joachim commented> No it is not pointless. It is required to give anonymous users permission to be able to go through the checkout of that order.
So are you saying that calling getCart() has side-effects which are necessary in the if() block for skip_cart? If so, the call to getCart() needs a comment to explain that, otherwise a future developer might think the same thing I did, which is that it can be moved to the else{} block as that's the only place $cart is used.
Comment #66
remaye CreditAttribution: remaye commentedThe patch in #63 doesn't work with DC 8.x-2.9 as in /modules/cart/src/Form/AddToCartForm.php :
has been changed to :
The patch works again if modified as following :
lines 40 and 41 :
EntityRepositoryInterface $entity_repository>>> EntityManagerInterface $entity_manager
line 42 :
parent::__construct($entity_repository, $entity_type_bundle_info, $time);>>> parent::__construct($entity_manager, $entity_type_bundle_info, $time);
But is it safe doing it that way... ?
.../... I tried it and it seems to work well...
Comment #67
flocondetoile@remaye The safe and right way is to update DC on latest version 2.11.
Comment #68
ElusiveMind CreditAttribution: ElusiveMind commentedUpdated to work with v2.11
Comment #69
ElusiveMind CreditAttribution: ElusiveMind commentedIt helps if I upload the right file. Sorry
Comment #70
Jeff Veit CreditAttribution: Jeff Veit commented#69 works for me on 2.11.
Thank you.
Comment #71
kclarkson CreditAttribution: kclarkson as a volunteer and commented#69 works great for me on 2.11.
Much appreciated. It makes it so much smoother for end users. Thanks again!
Comment #72
johnvenpin CreditAttribution: johnvenpin commentedGot working also with commerce-direct-checkout-69.patch and 8.6.4-2.11 Commerce 2.11
To spare a bit of clicking around the following worked
../admin/commerce/config/product-types
then select your product type
then Manage display
then cog on Variations field
then check Skip cart, create a new order and immediately start the checkout process.
Comment #73
MrPeanut CreditAttribution: MrPeanut commentedI'm on 2.11 but I get the following error when applying the patch from #69:
Comment #74
drupgirl CreditAttribution: drupgirl commentedJust an FYI: I had this working with the patch awhile back but had to abandon this route due to folks being able to use the back button or just click out of the workflow. If you're using licenses the license gets applied before they checkout. So if the user isn't truly committed to checking out and starts hoping out of the workflow -- using the back button, using another link -- then they cannot find their way back to checkout/#, and there's no cart to provide them a new path to get there. In this case you may want to consider going on the order type fullfillment path. Idk, I didn't try that before I abandoned this option.
Also, as far as applying patches -- try moving the ones you want to apply cleanly to the top of you patch stack. I know currently between commerce/license/recurring the patch list is long. Reordering has saved me many times.
Comment #75
Mohsen Molaie CreditAttribution: Mohsen Molaie commented#69 works great for me on 2.12.
Thanks.
Comment #76
mygumbo CreditAttribution: mygumbo commentedI've applied #69 to 2.12 and it's working. However, the view Checkout Order Summary does not display on the checkout page, eg /checkout/260/order_information, except for user 1.
Comment #77
Londova CreditAttribution: Londova commentedIs there any reason why this issue is NOT closed and implemented in the Commerce Core?
Comment #78
namitasaxena CreditAttribution: namitasaxena commentedI tried patch of comment #50
then "Add to cart" button disappeared, there is no any button on product page after applying patch
Can anyone please help???
Comment #79
miiimoooPatch applies cleanly with 2.13.0 / 8.7.3 and works as expected
Seems even to come with a test. Could this be committed or is the approach the problem?
Comment #80
lawxen CreditAttribution: lawxen commented@miiimooo patch of #69 can't be applied to commerce:2.13 or newest commerce:2.x-dev
Comment #81
lawxen CreditAttribution: lawxen commentedRe-roll #69 for newest commerce:2.x-dev
Comment #83
AjitSRemoving the tag as the patch was rerolled.
Comment #84
muaz91Thank you @lawxen, patch #81 is working for me.
How to use:
1. go to your product display settings (/admin/commerce/config/product-types/default/edit/display)
2. in Variations field, click the gear icon located at the of the field
3. The gear when clicked, you will get format settings displayed on the Format column
4. Tick Skip cart, create a new order and immediately start the checkout process
5. Do not forget to click Update on the Format column, and then save the display
To tried out the setting, go to the product page (eg: /product/1) and click checkout. you will automatically redirect to checkout page
Comment #85
muaz91Comment #86
joelpittetI'll give a big +1 RTBC to this latest patch it works great.
Comment #87
joelpittetReroll just some minor fuzz
Comment #88
joelpittetThere is a @TODO in there, I'm comfortable with it but maybe the maintainers have a better approach in mind?
Comment #90
Anas_maw CreditAttribution: Anas_maw as a volunteer commented+1 for RTBC
Comment #91
renguer0 CreditAttribution: renguer0 as a volunteer commentedTried #69, #81 and 87 and their didn't apply. I'm in last dev of Commerce.
Thanks for all you work.
Comment #92
baikhoReroll against HEAD of dev
Comment #93
baikhoComment #95
renguer0 CreditAttribution: renguer0 as a volunteer commentedWell, I saw this module: https://www.drupal.org/project/commerce_cart_redirection and it's working good.
I didn't test it deeply, maybe you want to check by your own.
Comment #96
hodba CreditAttribution: hodba commentedThe patch is not applying against 2.19. Can anyone help with it?
Comment #97
rob_eyre CreditAttribution: rob_eyre as a volunteer commentedNeed to modify the patch file around line 67 (sorry, I'm a hopeless newbie, don't know how to upload this revised patch)
Comment #98
floydm CreditAttribution: floydm at Affinity Bridge commentedAttached is an attempt to reroll the patch from 92 against commerce 2.19. I did a three way merge and then accepted the changes from the previous patch where I could.
Apologies that I am unfamiliar with the history of this patch and how best to test it. I'm bringing a site I've inherited (but am unfamiliar with) up-to-date. Previously it was running Commerce 2.16 patch from 69.
I hope this works for folks.
Comment #99
mlecha CreditAttribution: mlecha commentedPatch #98 applied cleanly for me on Commerce 2.19 with Drupal 8.9. Tested direct checkout/skip cart in test mode with Stripe with no issues here on a local dev site.
Thanks for the patch update floydm. Much appreciated.
Comment #100
fishfree CreditAttribution: fishfree commentedI also applied Patch #98 against Commerce 2.19 with Drupal 8.9. Everything works perfectly. Many thanks!
Comment #102
piggito CreditAttribution: piggito as a volunteer and at Skilld commentedThere was a tabbing error in config schema, attached patch should fix it.
Comment #104
valicI think we should have more options for skipping carts, then just on add to cart form
* Per order type - case where you create automatic orders, send to the customer and he lands directly on checkout, without ability to use cart
(like some specific fees, I had case for warranty fees)
- this would provide more general ability to skip cart
* Per product type - case where you have specific product which does not need cart, but also there is no need for separate order type
- this would provide more granular ability to skip cart
Comment #105
ptmkenny CreditAttribution: ptmkenny commentedComment #106
joelpittet@valic re #104 Those might be better suited for a separate/follow-up feature request or do they tie in with the current patch?
We've been using the patch in here for quite some time and wonder what is needed to finish it and get it committed? My guess is the test failures need to be resolved (if they are related), but if so would this feature be considered?
Comment #107
joelpittetMinor cleanup of the reroll, removed the ending else so the patch is easier to follow, which help catch that
$this->entity
assignment was accidentally removed.Comment #109
ptmkenny CreditAttribution: ptmkenny commentedEdit: Comment removed because I found the cause, and it wasn't this patch.
Comment #110
Berdirre #104, this is configurable in the formatter, so it already *is* per order type and product type?
re #109: Yeah, there are also tons of test fails that kind of indicate that there's something broken on the page. That said, the serialization error is not your problem, that just happens while handling the actual error, the first one is the problem you need to look at.
Comment #111
joelpittetThanks @berdir, the manual testing without the cart shows that the errors are probably due to the API for the extra param
$skip_cart
forpublic function addToCartForm($product_id, $view_mode, $combine, $skip_cart, $langcode) {
I'll see if I can remove it easily
Comment #112
joelpittetI'm not sure where I can get the
$skip_cart
inside the\Drupal\commerce_product\ProductLazyBuilders::addToCartForm
without passing it in, I'd guess it's possible but anybody know off hand?Comment #113
Berdira bit hard to see from context, but this is the list of arguments passed to the lazy builder, so that seems to be here?
Comment #114
Berdirthis seems to be the problem, I don't remember exactly why I made this change, but for some reason, there are tests that enable commerce_cart but not checkout to test product add to cart form, and the result of this is that the form doesn't show up. Not quite sure what the best way forward is. This setting _does_ depend on commerce_checkout. So maybe needs a different implementation, not sure.
That doesn't explain why it doesn't work on your actual site I would assume, but maybe there's a conflict with another patch or customization?
Comment #115
Berdir> So maybe needs a different implementation, not sure.
Yeah, I suspect that a way forward would be a subclass of \Drupal\commerce_cart\Form\AddToCartForm in commerce_checkout and instead of passing the argument in, \Drupal\commerce_product\ProductLazyBuilders::addToCartForm() would be one of the two forms, plus conditional visiblity of the checkbox in \Drupal\commerce_product\Plugin\Field\FieldFormatter\AddToCartFormatter.
Comment #116
valicUpdated patch, with going back on settings per order type. Now cart / checkout are not tied (in regards of future removal of dependency among them).
If commerce_checkout is not enabled, cart module would work as is, and for that reason I moved tests from cart to checkout module.
We don't need to test cart, but checkout. Without checkout module cart can't have skip cart option.
One test still should failed (checkout text button problem)
TODO
- altering Add to cart -> in Checkout. We can't do this now easily. We could, but we would skip order item resolving.
Form alter is not going to work. We could do the resolve on lazy builder, and push as before skip_cart settings (this seems now easiest)
With regards of event subscriber and checkout button, maybe we should do swapping class for AddToCart, even with pushing through lazy builder would be simpler for now
Comment #117
valicLet's confirm test failure (one hopefully)
Comment #119
valicMy mistake, running locally Drupal 9.x. Small change to the patch.
Comment #120
valicComment #122
valicRerolling patch from #119 with final change for ability to change "Add to cart" button text.
We can easily overwrite that button within checkout module.
Order item is inside form object available (forgot on that, it was late yesterday), therefor we can do resolving. And check if resolved order type have skip cart enabled.
Tests should be green now.
TODO
- naming: do we use skip_cart key, or maybe direct_checkout naming, while everything is inside checkout module
Impact on cart should be non existing, even still not sure if we should do inside createCart this
But don't see other way, without changing AddToCart form, which we haven't now touched. And keep almost all changes in commerce_checkout
Comment #123
valicRenamed key from
skip_cart
tocheckout_direct
, but in UI we show to users "Direct checkout"(checkout_direct as key seems more logical, as there is checkout_flow, etc.. even direct_checkout is probably proper - native speakers can decide that better).
Adjusted tests a little, and added additional check that order is not visible on cart.
What is left is to decide if someone changes setting on order type to disable direct checkout, and then later enable, existing cart's are going to be carts then still. But I would rather left that now as is. It's up to each person maybe to handle these specifics, not sure we need to force it here? (I see slim chanches that setting on order type is going to be updated regularly, causing incosistency in behavior).
When the checkout module is not going to depend anymore on cart, we can add wrapper or force default value for direct checkout with moduleExists.
Comment #124
valicWe can completly decoupled the logic from cart provider, patch coming in a half hour
Comment #125
valicReroll of #123 with removing all changes from commerce_cart.
Now all logic resides in commerce_checkout.
Added service provider to swap
CartEventSubscriber
withCheckoutCartEventSubscriber
when commerce_cart is enabled.That event subscribers handles all logic around direct checkout, and if is not enabled it pass back to original CartEventSubscriber
(so we removed as well that message when direct checkout is enabled).
Service provider in a way does not make sense now while checkout depends on cart, but when this lands https://www.drupal.org/project/commerce/issues/2948332, then it will not break anything (because of DI related to cart module).
(but then we would need to split that event, so that without cart module enabled we can make an redirect to checkout directly)
Comment #126
valicCleaning unused namespaces
Comment #127
ptmkenny CreditAttribution: ptmkenny commentedUpdating IS to include documentation on how to use the latest patch.
Comment #128
ptmkenny CreditAttribution: ptmkenny commented(Edit) Tested #126 manually on my commerce store; direct checkout functionality works as expected, but I can't use the module with webprofiler (see next post).
Comment #129
ptmkenny CreditAttribution: ptmkenny commentedWhen I enabled the webprofiler submodule of the Devel module, Commerce Checkout breaks with the following error:
Steps to reproduce
1. Enable Commerce modules, including Checkout.
2. Enable Webprofiler module.
3. Go to any page of the site.
Comment #130
valicSorry, fixed. It should be working now with devel
Comment #131
valicAnd correct interdiff attached
Comment #132
deminyI tried patch #130 tonight; unfortunately it seemed not working when using a PayPal method as the only payment gateway. In this case, an order is created without making a payment through PayPal.
Comment #133
ptmkenny CreditAttribution: ptmkenny commented@deminy Could you explain how you configured Commerce? It would be great if you could provide step-by-step instructions, preferably from a fresh Drupal install, so that the error can be reproduced and fixed.
Comment #134
deminyIt will take some time to look into the issue with my current settings and using a fresh installation. I will try to provide more details this week. Thanks
Comment #135
deminyI did some more tests before the holiday, and here is what I found.
First, the patch is exactly what I was looking for for my use case (I'd say it's the best solution comparing to some other attempts I found previously).
The problem is related to the Commerce PayPal module I installed. There are two options to create a new checkout flow:
The first one works fine, but the second one (PayPal Checkout) doesn't work. If I use the "PayPal Checkout" checkout flow and try to checkout, I can click the "review", "checkout" buttons to complete checkout directly (without seeing a PayPal popup).
I'm not sure what caused the issue since it happened with PayPal only; it might not be an issue from the patch. I also tried to reproduce the problem with a fresh installation; however, there were too many modules/steps involved, so I gave up doing that.
As said, the patch doesn't work with the "Multistep - Default" workflow. Thanks
Comment #136
interlated CreditAttribution: interlated as a volunteer commentedThis patch applies against dev. The add to cart button generated by a view does not work, and I can't see an alternative 'direct checkout' button.
Comment #137
cferthorneyThe patch at #130 is working with 2.28. Requires one more for RTBC
*edited to reflect update to 2.28 working as expected*
Comment #138
Rob230 CreditAttribution: Rob230 as a volunteer and at CTI Digital for The Chartered Society of Physiotherapy commentedPath #130 working well for me on D9. Required reconfiguring because we previously had an older patch where it was configured on the product type display.
Comment #139
ptmkenny CreditAttribution: ptmkenny commentedUnfortunately after the 2.30 release, this patch no longer applies. Needs a reroll.
Comment #140
scotthooker CreditAttribution: scotthooker at TES Global commentedComment #141
scotthooker CreditAttribution: scotthooker at TES Global commentedComment #142
geek-merlinRun, testbot!
Comment #143
scotthooker CreditAttribution: scotthooker as a volunteer commentedGo for it I just needed the patch pretty sharpish ;)
Comment #144
GlarDupPatch 141 does exactly what I needed. Thanks!!!
Comment #145
RgnYLDZ CreditAttribution: RgnYLDZ commentedI can also confirm that patch 141 works perfectly with commerce 2.31
Comment #146
ibis CreditAttribution: ibis as a volunteer commentedUnfortunately after the 2.32 release, this patch no longer work. Needs work.
Comment #147
znerol CreditAttribution: znerol commentedPatch in #141 still applies fine to 2.32, no need to reroll.
Comment #149
znerol CreditAttribution: znerol commentedOh, so applies fine but now produces test errors. Needs work then.
Comment #150
jsacksick CreditAttribution: jsacksick at Centarro commented@znerol: The test errors are unrelated. putting this back to needs review.
Comment #151
znerol CreditAttribution: znerol commentedOpened #3317738: Add an option to disable the add to cart message on a certain order type in order to avoid having to replace the
commerce_cart.cart_subscriber
.Comment #152
balis_m CreditAttribution: balis_m commentedUsing 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.
Comment #153
znerol CreditAttribution: znerol commented#3317738: Add an option to disable the add to cart message on a certain order type is in, so
CheckoutCartEventSubscriber
can now be implemented without overridingCartEventSubscriber
.Comment #154
Yasser SammanI had to re-roll #152 to latest dev and test on 2.36.
Comment #155
Yasser SammanTest failed because of wrong arguments in CheckoutCartEventSubscriber.
Here's another try.
Comment #156
coffeemakr CreditAttribution: coffeemakr as a volunteer commentedInstead 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.
Comment #157
coffeemakr CreditAttribution: coffeemakr as a volunteer commentedI have noticed that
finalizeCart
is only called in the eventcommerce_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.Comment #158
znerol CreditAttribution: znerol commentedNice idea!
CartProvider::finalizeCart
also clears a static cache inCartProvider
.Comment #159
joelpittet@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!
Comment #160
coffeemakr CreditAttribution: coffeemakr as a volunteer commented@joelpittet: Of course thats correct. Here's a fixed version.
Comment #161
joelpittetThank you @coffeemakr, I'll set this back to RTBC
Comment #162
Anas_maw CreditAttribution: Anas_maw as a volunteer commented+1 for RTBC
Comment #163
RyanCMcConnell CreditAttribution: RyanCMcConnell as a volunteer commentedAny idea when this will be merged? We're using this code and it works flawlessly.
Comment #164
jsacksick CreditAttribution: jsacksick at Centarro commentedI 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?
Comment #165
jsacksick CreditAttribution: jsacksick at Centarro commentedI would expect code similar to this https://www.drupal.org/project/commerce/issues/2907461#comment-15316055 to handle the redirection... (i.e. an extra submit handler that does the redirect, added by the commerce_checkout module).
Comment #166
jsacksick CreditAttribution: jsacksick at Centarro commentedI'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...
Comment #167
rgpublicWasn'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?
Comment #168
jsacksick CreditAttribution: jsacksick at Centarro commentedOh you're right, that could be the reason, so I believe the patch can be greatly simplified.
Comment #169
valic@jscksick Yes, the most relevant comment would be #125 https://www.drupal.org/project/commerce/issues/2810723#comment-13832755
where are the changes occurred
All changes have been moved to the commerce_checkout module, and back then we still had "add to cart message" which is not configurable
now it's not needed anymore to swap that, and should be separate subscriber perhaps
Comment #170
tBKoT CreditAttribution: tBKoT at Lemberg Solutions commentedThis 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
Comment #171
jsacksick CreditAttribution: jsacksick at Centarro commentedI wonder if we should rename this to "checkout_redirect", but I'll defer to @rszrama for this.
Can't we get the order from the order item here??
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...
Comment #172
jsacksick CreditAttribution: jsacksick at Centarro commentedOk 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 "Destination" setting 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 destination.
We can call the setting "cart_redirect" (See screenshots below):
Update: On the screenshot, the select list says "Redirection destination", let's just skip "Destination".
Comment #173
jsacksick CreditAttribution: jsacksick at Centarro commentedAfter discussing this with @rszrama on Slack, we think this setting should be moved next to other similar settings (such as the "combine" setting), which means putting this setting back as a formatter setting....
Comment #174
tBKoT CreditAttribution: tBKoT at Lemberg Solutions commentedHere is the patch that provides redirect to cart|checkout in the "Add to cart" field formatter settings.
Comment #175
tBKoT CreditAttribution: tBKoT at Lemberg Solutions commentedComment #176
jsacksick CreditAttribution: jsacksick at Centarro commentedDo we really need to recreate an order? I'm confused?
Sure we need all of this??
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?
Comment #177
tBKoT CreditAttribution: tBKoT at Lemberg Solutions commentedThis 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.
Comment #178
tBKoT CreditAttribution: tBKoT at Lemberg Solutions commentedAdd fixes to coding style and tests
Comment #179
tBKoT CreditAttribution: tBKoT at Lemberg Solutions commentedComment #180
tBKoT CreditAttribution: tBKoT at Lemberg Solutions commented@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.