Dustin L.

FYI – The same problem occurs with custom roles that were created by the User Role Editor plugin. This doesn’t seem to be specific to the Members plugin.

@svendinser No I don’t have any other solution.

We just had the same problem happen with the “Billing Town / City” field and an order from Singapore.

It’s disappointing the plugin author hasn’t even replied to acknowledge this problem.

That worked. Thanks!

Thank you. This removes the PHP warning from bbPress and BuddyPress but does not resolve the conflict with bbPress.

I am having the same warning on a production site with a bbPress forum, except it is also preventing the page from loading correctly. Our forum root is set to show Topics by freshness:

https://www.cashflowdepot.com/community/

Page 1 & page 2 work ok but page 3+ are not accessible. They display “Oops, restricted content”.

https://www.cashflowdepot.com/community/page/3/

When I access the site on a staging server set to expose errors I also see:

Invalid argument supplied for foreach() in /nas/content/staging/cashflowdepot/wp-content/plugins/woocommerce-pay-per-post/public/class-woocommerce-pay-per-post-public.php on line 368

Interestingly, if a user is browsing a specific forum (rather than all forums) all of the pages work:

https://www.cashflowdepot.com/community/forum/creative-real-estate-discussions/page/3/

In a staging environment with WP 4.9.8 I switched to Twenty Seventeen 1.7 and deactivated all plugins except:

bbPress 2.5.14
WooCommerce 3.4.6
WooCommerce Pay Per Post 2.1.13

..and the problem persists.

It works great now. Thank you.

Unfortunately, I never found a solution for this. I am deleting variations when they should be hidden and then have to re-add them later. It’s a pain.

The JS I provided worked for me when I used it in the browser console but I could never get it working in WordPress. I’m far from an expert though. It would be extremely helpful if the plugin was updated to work how it did prior to WC 3.0. As it is now I am having to delete and re-add variations as they go out of stock / come back in stock because for us it doesn’t make sense to display disabled variations.

I tested again just now with the latest version of WooCommerce and it does seem to be working as expected. I’ll mark this as resolved.

Thank you

Thank you for responding but that was not how this plugin behaved prior to WooCommerce 3.0. I setup a test environment where you can see for yourself. This has:

WP 4.9.5
Theme: Twenty Seventeen 1.5
WooCommerce 2.6.14
WC Variation Radio Buttons 2.0.1
One variable product with 3 variations
Test URL:

https://wcrbold.wpengine.com/?product=variable-product
http auth: demo / support

The disabled variations are hidden even with WCVRB enabled.

I cloned that test install to a new install and updated to WooCommerce 3.3.5. I enabled all variations then re-disabled two of them. Now the disabled variations are visible but disabled. Test URL:

https://wcrbold.staging.wpengine.com/?product=variable-product
http auth: demo / support

Something seems to have changed with how this plugin interacts with WC after updating to WC 3.0+.

Do you know of a way to hide the disabled variations from the page? The JS solution I came up with works in the console but I haven’t figured out a way to get it working on a live site and would prefer that the disabled variations not be sent to the page at all.

Thank you

For now I came up with some JavaScript that will hide the disabled variations… It would be ideal to find a way to prevent them from being sent to the browser altogether though since this was the default behavior prior to WC 3.0.

var myDisabledVariations = document.querySelectorAll('.variations_form input[type="radio"]:disabled');
for (i = 0; i <  myDisabledVariations; i++) {
  myDisabledVariations[i].parentNode.style.display = 'none';
}

I just ran across the same issue. After a little digging I discovered it’s because since WooCommerce 3.0 product visibility is set via a taxonomy rather than post meta. It’s mentioned in the “Watch for performance improvements” section of this post

https://woocommerce.com/2017/04/woocommerce-3-0-release/

Thank you. That worked.

I figured this out. In case it helps anyone else..

WC has a new filter for this in \data-stores\class-wc-customer-data-store.php

Now they set display_name to “firstName lastName” by default. All I had to do was alter user_nicename with the new filter.

add_filter( 'woocommerce_update_customer_args', 'my_wc30_checkout_customer_data' );
function my_wc30_checkout_customer_data( $customer ) {
	$customer['user_nicename'] = sanitize_title( $customer['display_name'] );
	return $customer;
}

Thank you, @duracelltomi. That seems to have fixed it. No errors now and the data is showing in the source code.