Not sure about Jonathan, but our plugin registers a WordPress endpoint:

add_action( 'rest_api_init', function() {
	register_rest_route( self::$g3d_namespace, self::$ec3d_add_to_cart . '/(?P<productid>[\d]+)', array(
		'methods' => WP_REST_Server::CREATABLE, /* post */
		'callback' => array( $this, 'ec3d_add_to_cart' ),
		'args' => array(
			'productid' => array(
				'validate_callback' => function( $param, $request, $key ) {
					return is_numeric( $param );
				}
			),
		),
	));
});

And on the Woo single product page we present an iFrame to the user which has an embedded callback URL to our site to add a product to the Cart. This link contains a nonce created with wp_create_nonce which does so for the current user. (non-authenticated is the issue)

As of Woo 3.6 this is broken, yes 3.5.x is fine. When the REST endpoint is hit, Woo now seems to have altered the expected User ID for it’s SESSION, and now the nonce generated by WordPress is failing as that is from a different User ID.

adding a filter and forcing the user ID can fix this for us, but unsure of the ramifications:

if ( ! is_user_logged_in() ) {
	add_filter( 'nonce_user_logged_out', [ $this, 'nonce_user_logged_out' ], 9999 );
}

The _low_ priority is used to hopefully fire our filter last, so we can force the ID back to zero and in doing so, we can again add products to the Cart as the nonce is valid for the ID they were generated under:

public function nonce_user_logged_out( $uid )
{
	$user  = wp_get_current_user();
	$uid   = (int) $user->ID;
	return $uid;
}

Which when hit can show the Woo ID as the input to the filter, and our over-ridden FINAL one that we return:

USERID=68ac4c033bc906dbd936f366540949f4
FINAL USERID=0

Perhaps we need to do something differently, just documenting how it works as of now.

Any thoughts would be appreciated.

Thanks for the heads up. The only thing you really want to change there is the H2 on .cart_totals, removing it’s float left and replacing with a text-align left. This is what it looks like in Firefox now:

http://d.pr/i/dVbY

We’ll have this fixed for Jigoshop 1.3.2

It is dependent on several things that may require a closer look. You should post on the Jigoshop forums with a link and get it looked into at least.

One issue involved rewrite rules in .htaccess, another incorrect settings in php.ini, others have set permalinks to default, saved twice, reset to custom, saved twice, one other deactivated the plugin, deleted all Jigoshop created pages and re-activated the plugin … there have only been a few reports of the problem and it isn’t tied to any one thing.

Ok, your error_log from php.ini and (assuming) your Apache/Windows webserver error log are 2 different things. Perhaps you’ve checked both and I’m just misunderstanding …

That line is only a ‘notice’, and shouldn’t be causing a failure, but we are going to file it to look into. Appreciate your posting it.

Also elbil, you or your developer can check out the following link:

http://jigoshop.com/user-guide/theming-with-jigoshop/

Specifically the section on ‘Customising the templates using Hooks’. A few minor tweaks to your theme and sidebars will be good once you get your content properly wrapped.

As suggested, visit the forums at Jigoshop for more help.