Sage 10 & WooCommerce + Mollie

[abel-sch]

Hi there,

I’ve been breaking my head around this for a few days; I’m working on a e-commerce website built around Sage 10 with WooCommerce. Somehow the PSP plugin ‘Mollie for WooCommerce’ is broken with Sage 10. Works perfectly fine with Sage 9 but with a clean installation of 10 any payment method of Mollie returns the error ‘undefined index: query’.

I’ve had contact with support of Mollie and according to them this means the Mollie API doesn’t know which payment method is selected. Because this problem only rises with Sage 10 and not with any of the default WC themes (2021 & Storefront) or even Sage 9 this must be something within the codebase of Sage 10, I think.

I’m not sure what conflict Sage 10 could cause with WooCommerce + Mollie’s payment flow, anyone here has a clue?

I’ve found that an older version of the plugin does work but not being able to update a payment plugin doesn’t seem like the safest bet to me.

Thanks in advance!

note:
this only applies to Mollie’s payment methods, any of the default methods work just fine.

[carlosfaria]

Wich package are you using to integrate WooCommerce with Sage10? Sage10 and WooCommerce doesn’t speak to each other unless you install sth like https://github.com/generoi/sage-woocommerce

Did you try installing that?

[abel-sch]

I am using Generoi’s WC package. I managed to solve the problem; as I installed more plugins the ‘undefined index: ###’ error seemed to keep popping up here and there breaking the plugins functionality.

As it turns out Sage 10’s error page was the problem; it was exiting PHP for usually ignored errors (notices / warnings). Tweaking the error handler solved this.

[carlosfaria]

@abel-sch how did you solved that error? I had the same problem and fixed it using this solution:

https://gist.github.com/cfaria/7eb83ca2853cb062fd7f6365c9bd6de2

Just curious about your approach…

[Twansparant]

Thanks for your gist @carlosfaria, very useful!
The only drawback for me is that you will keep having these error messages on every admin page load, since most of the errors are caused by 3rd party plugins.

[carlosfaria]

At least they don’t break the site…

[Twansparant]

100% true
I added a conditional around it, to only display my own caused theme errors:

// Only show errors from theme
if (!strpos($file, 'plugins')) {
	$error_output = view('admin.error', [
		'error_label' => $error_label,
		'message'     => $message,
		'file'        => $file,
		'line'        => $line,
	]);

	if (is_admin() && !wp_doing_ajax()) {
		add_action('admin_footer', function () use ($error_output) {
			echo $error_output;
		});
	} elseif (!wp_doing_ajax()) {
		add_action('footer', function () use ($error_output) {
			echo $error_output;
		});
	}
}

[abel-sch]

My solution was actually quite similar but less elegant then yours:

	add_action('after_setup_theme', function () {
		if (WP_DEBUG) {
			$previous_handler = set_error_handler(null);

			if (!empty($previous_handler[0]) && $previous_handler[0] instanceof \Roots\Acorn\Bootstrap\HandleExceptions) {
				set_error_handler(function ($level, $message, $file = '', $line = 0, $context = []) {
					error_log("PHP Error: " . $message . " error level: " . $level . " " . " line: " . $line . " ");
					if ($level != E_NOTICE && $level != E_WARNING) {
						throw new ErrorException($message, 0, $level, $file, $line);
					}
				});
			} else {
				set_error_handler($previous_handler);
			}
		}
	}, 6);