iugoau

Sorry that was a typo – this is for Groundhogg.
Mailgun is listed as supported however the missing integration for mailgun bounce reporting is an issue. Other options such as wooninja add ons dont actually cover the requirement of receiving bounce reports to the mailbox or to the GH reporting dashboard when mailgun is the sending service provider.

Hi Jonayad,

I think this should be handled at the WooCommerce level, as we got this reply from the Events Calendar support :

Since you’re offering both free and paid tickets, it makes sense to keep Stripe and WooCommerce enabled. In that case, switching to Tickets Commerce or disabling payment methods isn’t really a viable option.

That said, the behavior you’re seeing, where WooCommerce asks for payment details even when the cart total is $0, does appear to be inherent to WooCommerce itself.

Unfortunately, since WooCommerce controls the checkout process, it’s outside the scope of what we can directly change on our end. With Tickets Commerce, which is our native system, this doesn’t happen; free tickets skip the payment details entirely.

As a potential workaround, you can try adding the following snippet to your site. It tells WooCommerce to skip the payment step if the cart total is zero:

add_filter( 'woocommerce_cart_needs_payment', function ( $needs_payment, $cart ) { if ( $cart && 0 == $cart->get_total() ) { return false; } return $needs_payment; }, 10, 2 );

Could you please update the code as it’s happening on every site and not showing the products in the admin panel?

Howdy,

Further to the above, it looks like the plugin should probably be using the WP provided JSON class instead? The plugin’s class seems to be a copy from an older version of WP.

In campaign-monitor-wp/providers/campaignmonitor/campaignmonitor/class/serialisation.php:

Instead of –

if (!class_exists('Services_JSON', false)) {
    require_once dirname(__FILE__).'/services_json.php';
}

It could be –

if ( ! class_exists( 'Services_JSON' ) ) {
    require_once ABSPATH . '/wp-includes/class-json.php';
}

(This whole class is actually marked deprecated since WP 5.3.0 in favour of the built-in PHP functions, json_encode and json_decode.)

A developer could optionally circumvent the Array and string offset access syntax with curly braces is no longer supported error by adding the following to a custom plugin (or a must use plugin):

$class_file = ABSPATH . '/wp-includes/class-json.php';
if ( file_exists( $class_file ) ) {
	require_once $class_file;
}

This would ensure that WP’s version of the class is always loaded instead (though it might trigger a bunch of WP deprecation notices)