horgster

Hi @iverok

Thanks, this works as expected🤗

Does that I mean, that I also should update this part of my code for Login for VIPPS

/** Removes Country Code from VIPPS Login Plugin */
add_filter('login_with_vipps_woo_phone_number', function ($phoneno, $customer, $userinfo) {
if (!preg_match("!^47!", $phoneno)) return $phoneno;
if (strlen($phoneno) < 10) return $phoneno;
error_log("Removing phoneno");
return substr($phoneno,2);
}, 10, 3);

I am running these two filters in a same custom plugin, like this:

/** Removes Country Code from VIPPS Login Plugin */
add_filter('login_with_vipps_woo_phone_number', function ($phoneno, $customer, $userinfo) {
if (!preg_match("!^47!", $phoneno)) return $phoneno;
if (strlen($phoneno) < 10) return $phoneno;
error_log("Removing phoneno");
return substr($phoneno,2);
}, 10, 3);

/** Removes Country Code from VIPPS Checkout/Express Checkout */
add_filter('woo_vipps_canonicalize_checkout_address', function ($address, $user) {
$phoneno = $address['phoneNumber'] ?? "";
if (!preg_match("!^47!", $phoneno)) return $address;
if (strlen($phoneno) < 10) return $address;
$fixed = substr($phoneno,2);
$address['phoneNumber'] = $fixed;
$address['mobileNumber'] = $fixed;
error_log("Checkout: Removing prefix from phone, using $fixed");
return $address;
}, 10, 2);

• This reply was modified 5 months, 2 weeks ago by horgster.

Hi @iverok

Great and thanks for quick support as always 🙂

But we have an critical bug here!

After upgrading to 5.0.13, the express checkout is no longer working.

We can’t initiate VIPPS payment with Express checkout, when pressing “Betal med Vipps” button during express checkout after the “sales conditions” is confirmed.

If I select an product and select, pay now with VIPPS, I am redirected to “VIPPS Hurtigasse” https://www.oslokiteklubb.no/vipps-buy-product, but when I then press “Betal med VIPPS”, the VIPPS page is not opened.

I was forced to rollback to version 5.0.12 to get VIPPS payment to work again.

Let me know if I can assist in troubleshooting?

Hi,

This morning I tested following two scenarios:

Scenario 1

1. Purchased a product with the value of 5 kr
2. Refunded 1kr manually with the manual button
   VIPPS Gateway was not engaged at this time.
3. Changed the order status to “Refunded”
   VIPPS Gateway engaged – and 5kr was refunded

Scenario 2

1. Purchased a product with the value of 5 kr
2. Refunded 1kr manually with the manual button
   VIPPS Gateway was not engaged at this time.
3. Refunded the remaining 4kr manually
   VIPPS Gateway engaged – and 5kr was refunded

This concludes that refunding *part* of the order until all founds is refunded manually do not work either.

So yes, I think it is important that logic should be changed here.

Hi @iverok

Thanks for quick response.

The entire process that I did:
1. Opened the order by editing it.
2. Pressed “Refund” and selected the product to be refunded.
3. Pressed the “Button” Refund kr xx manually (not the “Refund xx kr via Vipps MobilePay” button)
4. This triggered the order to be refunded to Vipps.

I also tested on another separate test order:
1. Edited an order
2. In Order Status, I selected “Refunded” and updated the order.

This also triggered full refund via the VIPPS Gateway as you mentioned above.

Best Regards
Horgster

• This reply was modified 5 months, 4 weeks ago by horgster.

Hi @gandomi

Thank you very much for this update and quick service!

In the release notes; it states “Prevented wp_statistics_tracker_js_errors option bloat by limiting stored errors and truncating error messages.”

What has been fixed here, as it states “limiting” errors, does that mean that we will still posted error messages in the autoloader?

Hi,

I would also like to address that the “WP Statistics” plugin should at no circumstances logs deprecated warnings of other plugins/themes unless you really need it into the wp_options table!!

There should also be implemented an sensible size limit and frequency limit incase you need to debug this. Please set this to “disabled” be default, and add these options in the General Settings page of the debugger to enable these features when needed!!

In complicated WordPress installations will always time to time have deprecated functions and logging this is unnecessary unless debugging is really needed.

I have added an temporary filter

add_filter(‘wp_statistics_disable_tracker_debugger_logs’, function () {

    return true; // Disables tracker debugger error logging

});

Please fix this!

Hi @iverok

Could you assist to create an new filter that runs all express checkout/checkout.

• This reply was modified 1 year, 4 months ago by horgster.
• This reply was modified 1 year, 4 months ago by horgster.