bungpm

Hi Aarmir,

thanks for getting back to me. The setting is already off:

https://ibb.co/JwVW51wH

This is the behavior I get in the front end:

https://ibb.co/WWYHpnph

All product variations are added to the product but only two of six variations are in stock.

The others can not be selected though, because the variations are not clickable.

Thanks again for your help.

Awesome, thank you.

I have reviewed the code change and have seen that you create a new refund entry for the order after getting the webhook from PayPal.

However, we trigger the refund by creating a new refund entry in the order in WooCommerce in the first place. We are also setting specific items that the refund is for and add a reason for the refund.

So I am assuming we will get doubled refund entries then? Also, the customer would get a second email about the same refund.

Thanks again and best,

Joern

• This reply was modified 1 year ago by bungpm.

As always, you guys are absolutely amazing. Thanks!

I don’t know if I have ever experienced such amazingly fast support anywhere.

Thanks a lot!

Will let you know how it goes in production.

You should be able to replicate this by adding this filter to your functions.php and NOT using the block but only the shortcode to include the switch.

add_filter( 'should_load_separate_core_block_assets', '__return_true' );

You can download it from here: https://downloads.wp.xz.cn/plugin/custom-fonts.2.1.1.zip

I did some more testing myself and it actually works if you happen to have the subscription as the first item in your cart and the simple product second.

In paymill/lib/integration/woocommerce.inc.php, the following line in process_payment reduces the variable $cart to just the first entry of the cart:

$cart = reset($cart);

If the first product in your cart happens to be the simple product instead, it doesn’t work and throws the interval error mentioned above.

I worked on this issue some more and have a working fix here (http://pastebin.com/UVSYEPpD). It is not pretty yet, and probably isn’t suitable for pulling because I need to allow multiple subscriptions for the same user in my shop and figured this into the change as well by adding the order id to the offer-hash.

While fixing this, I also had an issue with a race condition, where the callback to the webhook for the subscription was interfering with the transaction for the simple product causing the “50000: Problem with back end” error I mentioned previously. I fixed this by switching the calls to processProducts() and processSubscriptions() in line 695 of the changed file.