mb00

Could you give me a rough estimate when it could be done? Weeks, months? The problem is that not only flexible shipping plugin does not work but I can’t use any plugins that depend on it ether.

I’m aware these are not error messages, but it has no place in production environment without option to opt out. This technically should be opt-in, not an opt-out as well.

I’ve listed multiple options how to address this in my first comment. It’s not very complicated.

It’s not related to text domain. console.log() is a JS function, it’s been triggered when payment method is changed:

#klarna_payments_pay_over_time_container
klarna_payments_pay_over_time
klarna_payments_pay_over_time

There is 27 places where this function is called in 6 different JS files.

• This reply was modified 2 months, 4 weeks ago by mb00.

I’ve ran into the same issue, but found a temporary solution. This does not fix the problem, but it stops the 300030 error loop. As @thetallone mentioned, the error seems to be only triggered when widget is added above pay now button, other options seem to work fine.

1. Check Advanced Settings -> Extra Failure Message checkbox.
2. Add error message (not sure if this step is really needed, but doesn’t hurt).
3. In simple-cloudflare-turnstile/inc/turnstile.php find function cfturnstileErrorCallback(), comment both lines out, and add return true; instead.

Bump.

The deprecated warning present in PHP8.1+. This warning is coming from passing null to add_submenu_page() method in admin/class-wp-rest-api-log-admin.php function admin_menu().

Changing null to ” would fix the problem, but technically a parent slug should be passed as an argument.

In addition, there is also warnings when viewing the log entry( e.g. /wp-admin/tools.php?page=wp-rest-api-log-view-entry&id=123):

WP_REST_API_Log_API_Request_Response_Base::{closure}(): Argument #2 ($k) must be passed by reference, value given

and

WP_REST_API_Log_API_Request_Response_Base::{closure}(): Argument #2 ($k) must be passed by reference, value given

in wp-rest-api-log/includes/class-wp-rest-api-log-request-response-base.php file lines 130 and 145.

It does not happen with COD.

I actually downgraded WooCommerce version, but this change might solve the issue, if it was not part of 8.0.1 release (as problem was still there):
https://github.com/woocommerce/woocommerce/commit/c584d4041a3dc1f44e4614dc76cae12f074f7cd2

As mentioned in initial post PayPal return button is actually form submission button that posts data back and as the check is done above the filter, it’s simply impossible to disable that new functionality using filter because filter is never triggered.

Re: WooCommerce Paypal Payments, this issue was even more serious (also mentioned in initial post) so we had to switch plugin off and just wait for things to get bit more stable there.

I’ve also noticed a lot more failures recently. I’ve been using the plugin for 2-3 years on high load site and I never saw an error like that, but for the past month or so this is happening almost on the daily basis.

It started with 2.4.1 for me (upgraded from 2.2.2).

Thank you!

Any progress on this?

Thanks

Awesome. Thanks for quick follow up.

It’s not about regions, its about how the orders are stored and how the data is managed. Given HPOS stores the data in new tables, standard methods like get_post_meta() or update_post_meta() can no longer be used and plugin developers need to rely on woocommerce api methods e.g. $order->get_meta().

Your plugin could be 100% compatible with HPOS and you might only need to declare support using a small php code snippet. I haven’t reviewed the actual plugin code so I’m not sure if any changes are really needed, but the documentation provides information on what parts have to be update and how to declare the support.

I understand this might take you some time, especially if you will have to make changes and retest everything, so I’m not expecting a quick update.

I’m also happy to create a PR with changes if you’re using github for development and your repository is public.

Thanks!

• This reply was modified 2 years ago by mb00.

I second the request for HPOS support.

Here is more details:
https://github.com/woocommerce/woocommerce/wiki/High-Performance-Order-Storage-Upgrade-Recipe-Book

I’ve proposed 2 options, first option requires patching, the second does not. Adding #2 solution to your functions.php will allow you to update the plugin.

Unfortunately current implementation does not have any easy way to address this issue, but here is two work arounds:

1. You can patch the plugin (make change in the plugin). Unfortunately changes will be lost if you will update the plugin.

To patch the plugin
1. Open omnisend-connect/omnisend-woocommerce-hooks.php.
2. Scroll to line 215, you should see the following if statement:
if (OmnisendHelper::isWooCommercePluginActivated() && OmnisendHelper::checkWpWcCompatibility() ) {
3. Add additional check accordingly to your needs, e.g. :
if (OmnisendHelper::isWooCommercePluginActivated() && OmnisendHelper::checkWpWcCompatibility() && isset( $_COOKIE[ 'my_cookie' ] ) ) {

-OR-

2. You can add a following function to your functions.php in your theme/child theme:

function load_omnisend_with_consent( $value, $option ) {
	if ( ! isset( $_COOKIE[ 'my_cookie' ] ) ) {
		return null;
	}

	return $value;
}
add_filter( 'option_omnisend_account_id', 'load_omnisend_with_consent', 10, 2 );

Ideally a ‘wp_footer’ action should be not be set up as anonymous action, so other plugins would have a chance to remove / modify the behaviour.

NOTE: Your site user will have to reload the page (if its not done automatically after accepting cookies) for Omnisend JS snippet to be loaded.

• This reply was modified 2 years, 5 months ago by mb00.
• This reply was modified 2 years, 5 months ago by mb00. Reason: Added a note