Jeff

Sorry, wrong plugin ticket, ignore this.

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.

add_filter( ‘jigoshop_shipping_fields’, ‘egmont_shipping_fields’ );
add_filter( ‘jigoshop_billing_fields’, ‘egmont_billing_fields’ );

Look in the file jigoshop/classes/jigoshop_checkout.class.php and you can find the two functions:

function get_billing_fields()
function get_shipping_fields()

copy and paste them into your functions.php, rename them, use the filters I listed initally with the new function names … and alter the functions to provide the fields you want.

Easy peasy.

Be advised, the field names have changed in the newly released 1.10 so I use something like this for each field:

return array(
		array(
			'name'          => jigoshop::jigoshop_version() < '1.10' ? 'billing-first_name' : 'billing_first_name',
			'label'         => __('First Name', 'jigoshop'),
			'placeholder'   => __('First Name', 'jigoshop'),
			'required'      => true,
			'class'         => array('form-row-first') ),

This tests for jigoshop version and uses different field names to match version. Most all the field names have changed, so do it for each.

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:

https://d.pr/i/dVbY

We’ll have this fixed for Jigoshop 1.3.2

Well, there ya go. ??

Another item to add to the list of possible causes. ??

Good job Harry.

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.

What version of the plugin do you have Andr2?

Several others have been able to resolve this by upgrading to 0.9.8.1 available from the public master branch of the repository:

https://github.com/jigoshop/jigoshop

The 1.0 release will be ready very soon as well.

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.

One or two people have reported this problem and it seems to be sessions and hosting related.

Turn on WP_DEBUG, run through the process again and note any output.

https://codex.www.ads-software.com/Editing_wp-config.php#Debug

Also, access to your server error_logs may indicate something.

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

https://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.