Sean Conklin

This plugin stopped collecting abandoned carts when we moved to the Checkout Block. We certainly see Draft orders flowing in, but they aren’t making it into this plugin’s database.

Too bad! The Checkout Block has existed for a few years already and it became the default experience last Fall.

Hi @mrclayton and sorry to hear that you’re facing trouble on this one. Have you considered loading the Express Checkout payment methods in alphabetical order? That-is, in the JS file where these methods load trigger Apple Pay before Google Pay so that it shows first.

Of course other payment plugins could load before or after your script, but within your script I imagine you could decide the ordering.

Thanks for this suggestion, @gonte

Yes I agree that Stripe’s Migrate payment methods to the Dashboard configuration is a great way to go. It looks from their documentation that I can now offer a Default option (blank value) to support this, and I will plan to test this change soon.

It’s unclear whether this works for subscriptions, but I have a setting to separate the payment method choice for subscriptions anyhow. I’ll test that one as empty and see if it works. I imagine that it will, but only for supported payment methods within your settings.

This project has no funding so it’s just something that I work on in spare time or as bugs arise that would affect my own site running this plugin. Thanks for your patience and support.

Hi @jerrybarry and thanks for posting.

I see that my plugin is using the WooCommerce line item’s product record price rather than the line item price itself. I’d call that a bug! I’ve released a fix for this in version 1.5.2 just now.

Thanks again for reporting.

Hi @jerrybarry – thanks for reporting this.

Apologies for the delay. I never received an email notification about this ticket. I’ll check to see what’s going on with that. It used to work!

Stripe Checkout allows use of a single coupon. It’s not a 1:1 relationship with WooCommerce coupons. I checked to confirm that this remains to the case as-of this writing. They document the process here: https://docs.stripe.com/payments/checkout/discounts

I had developed a PHP filter method for applying coupons. That filter is ccom_stripe_checkout_discounts and it passes the order line items to your custom filter and accepts an array result of one or more discounts containing the name and percentage of each. From there it generates a single Coupon ID within Stripe Checkout and applies that to the payment process.

In my original use case (my own site) I was setting the coupon amount based on line items and custom business rules rather than a WooCommerce coupon or two, so this is why I built it that way.

I can certainly see a benefit to augmenting this to apply all WooCommerce coupons on the order as well. Luckily I see that they accept both percent_off and amount_off discount methods, which should generally match to WooCommerce coupons after other rules were applied by WooCommerce during the Pending order creation.

I’ll take this as a feature request, however I make a living doing this work and must await funding from somewhere while I have billable work to prioritize. This feels like a few hours of work to code, sandbox test it, and release it.

This topic can get more complex when factoring in subscriptions. There’s also some concern about generating these session type coupons versus re-using a previously generated coupon ID where the scheme (the combination of coupons therein) matches. I don’t have a solution for these more complex areas yet, but I see no reason for that to delay the basic support of WooCommerce coupons.

I was quite sure that WooCommerce PayPal Payments was compatible with the Checkout Block. After all, the Checkout Block has been the default experience for months now, and preexisting stores have been slowly upgrading to the new Blocks technology that represents the future of WooCommerce (and WordPress itself). Well when testing a client site running the latest everything in March 2024 it definitely shows PayPal Payments as incompatible.

Super! Thanks for confirming that, and for taking the time to report the problem.

Okay all fixed in version 1.5.1. Please let me know how it works for you. Also note that WooCommerce has a currency filter that should be obeyed now if you use a Currency Switcher plugin or wish to program something dynamic for that. That filter is woocommerce_currency.

Hi @jerrybarry,

Thanks for bringing this to my attention. Thus far I’ve been using the plugin on USD sites. I’m happy to adjust the plugin to show the currency that WooCommerce is set for and will do so shortly.

I figured I’d ask here, do you use a currency switching plugin or have any currency logic? I figure while at it I’ll add a PHP filter so developers can manipulate the currency based on the cart items, etc. I’m curious though if there’s any other variables from popular currency plugins to account for here as well.

Hi @sarankumar,

Sorry for the delay, never received the notification email.

Good news here – I fixed that issue recently. It was a namespace conflict when other plugins use the same JavaScript variable names. Please let me know if you experience any problems with the latest version 1.5.

I’ll go ahead and close this one out as my client has paid twice since this issue without problems. It’s a weird one to reproduce!

Also, I deployed the Checkout Block and can’t use this plugin anymore due to its incompatibility there. I’m now sending folks over to the Online Pay Links (by GoDaddy Payments / Poynt) in place of the plugin.

This PHP crash is still showing up in the WooCommerce > Status > Logs several times a day.

Here’s the stack trace. It looks to me this comes from admins looking at the WooCommerce orders list and an AJAX request firing off their browser.

Imagify is the only plugin that I could find that calls the missing function convert_to_screen(). I would say to have your developers check where they’re hooking into WordPress. There must be somewhere that’s too general and allowing AJAX to execute their code surrounding the convert_to_screen call.

Stack trace:
#0 wp-content/plugins/woocommerce/src/Internal/Admin/Orders/ListTable.php(74): WP_List_Table->__construct(Array)
#1 wp-content/plugins/woocommerce/src/Internal/DependencyManagement/Definition.php(28): Automattic\WooCommerce\Internal\Admin\Orders\ListTable->__construct()
#2 wp-content/plugins/woocommerce/lib/packages/League/Container/Definition/Definition.php(212): Automattic\WooCommerce\Internal\DependencyManagement\Definition->resolveClass('Automattic\\WooC...')
#3 wp-content/plugins/woocommerce/lib/packages/League/Container/Definition/DefinitionAggregate.php(94): Automattic\WooCommerce\Vendor\League\Container\Definition\Definition->resolve(false)
#4 wp-content/plugins/woocommerce/lib/packages/League/Container/Container.php(157): Automattic\WooCommerce\Vendor\League\Container\Definition\DefinitionAggregate->resolve('Automattic\\WooC...', false)
#5 wp-content/plugins/woocommerce/src/Internal/DependencyManagement/ExtendedContainer.php(158): Automattic\WooCommerce\Vendor\League\Container\Container->get('Automattic\\WooC...', false)
#6 wp-content/plugins/woocommerce/lib/packages/League/Container/Container.php(178): Automattic\WooCommerce\Internal\DependencyManagement\ExtendedContainer->get('Automattic\\WooC...', false)
#7 wp-content/plugins/woocommerce/src/Internal/DependencyManagement/ExtendedContainer.php(158): Automattic\WooCommerce\Vendor\League\Container\Container->get('Automattic\\WooC...', false)
#8 wp-content/plugins/woocommerce/src/Container.php(110): Automattic\WooCommerce\Internal\DependencyManagement\ExtendedContainer->get('Automattic\\WooC...')
#9 wp-content/plugins/woocommerce/includes/admin/list-tables/class-wc-admin-list-table-orders.php(48): Automattic\WooCommerce\Container->get('Automattic\\WooC...')
#10 wp-content/plugins/woocommerce/includes/admin/class-wc-admin-post-types.php(100): WC_Admin_List_Table_Orders->__construct()
#11 wp-includes/class-wp-hook.php(326): WC_Admin_Post_Types->setup_screen('inlineeditnonce')
#12 wp-includes/class-wp-hook.php(348): WP_Hook->apply_filters('', Array)
#13 wp-includes/plugin.php(517): WP_Hook->do_action(Array)
#14 wp-includes/pluggable.php(1343): do_action('check_ajax_refe...', 'inlineeditnonce', false)
#15 wp-content/plugins/wordpress-seo/src/conditionals/admin/doing-post-quick-edit-save-conditional.php(25): check_ajax_referer('inlineeditnonce', '_inline_edit', false)
#16 wp-content/plugins/wordpress-seo/src/loader.php(270): Yoast\WP\SEO\Conditionals\Admin\Doing_Post_Quick_Edit_Save_Conditional->is_met()
#17 wp-content/plugins/wordpress-seo/src/loader.php(208): Yoast\WP\SEO\Loader->conditionals_are_met('Yoast\\WP\\SEO\\In...')
#18 wp-includes/class-wp-hook.php(324): Yoast\WP\SEO\Loader->load_integrations('')
#19 wp-includes/class-wp-hook.php(348): WP_Hook->apply_filters(NULL, Array)
#20 wp-includes/plugin.php(517): WP_Hook->do_action(Array)
#21 wp-settings.php(643): do_action('init')
#22 wp-config.php(57): require_once('/www/...')
#23 wp-load.php(50): require_once('/www/...')
#24 wp-admin/admin-ajax.php(22): require_once('/www/...')
#25 {main}
  thrown in wp-admin/includes/class-wp-list-table.php on line 149

Please confirm – you’re not getting this crash in WordPress 6.4 running this plugin and viewing the Imagify interfaces?

I’ll make it a point to deactivate Klaviyo whenever I setup a sandbox environment to prevent it syncing a sandbox URL catalog. I’m moving any “problem” plugins to a wp-content/plugins-available/ folder so they don’t get accidentally reactivated in sandbox whenever I refresh the database from production.

I always recommend that clients do not create staging sites when they run self-hosted commerce, but the reality is that I come across it often and many hosts make it very easy to spin these site copies up.

I’m sure that the issue I’m reporting here will come up again. I hope that folks catch it before orders show up in their staging environments causing all kinds of confusion for the customer support reps.

I recommend that Klaviyo adds a staging site safety measure regarding product catalog sync.

We observed what appears to be the same PHP crash, occurring a half dozen times a day.

We’ll try this v2.4.2-rc2 linked above and see if it resolves the matter. Thanks!

CRITICAL Uncaught ArgumentCountError: Too few arguments to function WooCommerce\PayPalCommerce\OrderTracking\Integration\ShipStationIntegration::WooCommerce\PayPalCommerce\OrderTracking\Integration\{closure}(), 1 passed in /wp-includes/class-wp-hook.php on line 326 and exactly 2 expected in /wp-content/plugins/woocommerce-paypal-payments/modules/ppcp-order-tracking/src/Integration/ShipStationIntegration.php:74