icanoop

Good point. Then, new custom fields overlords, is Secure Custom Fields going to add compatibility with WooCommerce HPOS?

@polevaultweb are you still planning to go forward with this after what’s happened recently?

Great news!!! Thanks @polevaultweb !

I agree that would be ideal. But it would also be more work for them. I’m appealing to the minimal effort aspect of compatibility mode.

I think ACF should work as is at the function/API level with HPOS compatibility mode enabled. The only problem I see is that ACF fields don’t show up on the edit order & edit subscription pages with HPOS enabled because ACF only adds meta boxes to posts and orders are no longer posts.

It seems like minimal effort for ACF to work when HPOS compatibility mode is enabled. Running with compatibility mode still gets you a lot of the benefit of HPOS such fast order searching.

Is there any chance ACF would consider supporting HPOS with compatibility mode?

We’re looking to migrate to HPOS but we have ACF fields on orders and subscriptions. I guess we have to decide whether to ditch HPOS or ditch ACF?

• This reply was modified 7 months, 4 weeks ago by icanoop.

The real resolution is to fix the code but as a workaround I’ve been running these commands every time I install the plugin.

sed -i '8 a $old_error_reporting = error_reporting(E_ALL ^ E_NOTICE);' wp-content/plugins/no-captcha-recaptcha-for-woocommerce/lost-password.php
sed -i '19 a error_reporting($old_error_reporting);' wp-content/plugins/no-captcha-recaptcha-for-woocommerce/lost-password.php

• This reply was modified 5 years, 10 months ago by icanoop.

Hi @madeincosmos,

Thanks but I’m trying to get the variation value, not the variation ID. For example, if I have a variation called Size and the customer chooses Small, Medium or Large when they place their order I need to get the value they chose, not the ID (returned by get_variation_id()) of the Size variation. How would I do that?

Thanks!

Here’s the site.

https://suretydiy.com

Add any of the top 3 featured products (those are subscriptions) and then add regular products from below. The WP Menu Cart at the top works correctly now.

WooCommerce Subscriptions 1.5.10 was just released and fixes this problem.

Did you have a chance to try and reproduce the problem? Any update on this?

Sure. Now I think it’s a problem with WooCommerce itself, not with WP Menu Cart. WP Menu Cart is just calling cart->get_cart_contents_count() and cart->get_cart_total() each time so WooCommerce must be returning the wrong data. For some reason it works correctly in the WooCommerce cart page but not correctly when called from WP Menu Cart.

It looks like the problem might have to do with ajax requests. If my cart has 3 regular products in it and then I add a subscription product, in the initial page load WP Menu Cart correctly shows 4 items in the cart with the correct total amount for the cart. Just after that, an ajax post is made to admin-ajax.php which has in its response object a field called a.wpmenucart-contents that contains html for a wpmenucart link which only shows 1 item in the cart and the total is only the amount of the subscription item. The WP Menu Cart changes to reflect the link in that ajax response which contains incorrect data. Any ideas?