Ian Misner

Pretty sure this is all fixed up now and has likely been for a while – sorry for not keeping it up to date here 🙂

Thanks so much for this, and for running CheckoutWC across your client sites.

Theme updates can shift things around on us all, and when it turns out to be a bug on our end, the job is to get you a working fix as quickly as possible!

Glad the team has come through for you on that, we try to avoid it happening, but there’s just so many themes out there 🙂

Anytime something comes up, we’re here. Thank you for the 10/10.

Hi there,

I definitely see your points around trust-conscious merchants. It’s a fair UX consideration, especially if you’re particularly sensitive to trust signals and privacy. I’m not 100% sure this is a behavior we should change in the CheckoutWC plugin, however.

We try to strike a balance here: we default to respecting your explicit uncheck, but we assume a change to the email could signal a different choice.

Most merchants want the checkbox to re-enable if the email changes because different email = potentially different customer intent. It’s also the standard pattern in identity-first checkouts, as you’ve noted. This is generally because the data shows that this has no negative impact on checkout conversion but has a positive correlation with either identifying or generating repeat buyers on a store.

We’re definitely open to continued UX refinements if we see a larger pattern of feedback around this.

In the meantime, we do actually offer a code snippet in our documentation to solve for changing the checkbox behavior on email validation. It allows you to set the default state for that checkbox to unchecked.

Please let me know if you had additional questions or feedback. We really appreciate it!

Cheers,

Ian

Hi there,

We’ve run a few tests and are unable to replicate this issue. I’ll close this out as resolved as you have not followed up, but if you have any further difficulties, please don’t hesitate to open a new thread or reach out to our team directly. We’re more than happy to help!

Cheers,

Ian

Hey there,

Thanks so much for sharing the solution here! This line removes the Kalium theme’s function kalium_woocommerce_single_product_add_to_cart_handler from the woocommerce_add_to_cart_redirect hook – so it looks like they have some custom cart handling in their theme that we’re not accounting for.

I’ve sent a message to the team over at Kalium to see if we can get this fixed up through improved compatibility on one side or the other.

In the meantime, let us know if you have any other questions!

Cheers,

Ian

Hey there,

Thanks for contacting us regarding Custom Add to Cart for WooCommerce. I’m happy to help!

I just tried this out on Storefront with WooCommerce and our plugin on the most recent version and things are working as expected. You could also try navigating to the correct fields by going to the plugins list and clicking the Settings link next to our plugin.

If that does not work, would you mind confirming what versions of Storefront and WooCommerce you’re using?

Thanks!

Ian

Hey there!

Ian here, jumping in for Juan. Thanks so much for reporting this issue! This is a bit of a quirk as a result of some underlying changes in WooCommerce that we haven’t addressed, as no one has reported any concerns. We’ll get a fix queued up to make this behavior more standard in an upcoming release. In the meantime, Juan’s code snippet should work.

We’ll drop a note here when the fix should be available for anyone who happens on this thread in the future. In the meantime, let us know if you have any questions!

Cheers!