Ragnar Karlsson

My suspicion is that there is an underlying issue with this though, my test site doesn’t need this fix on 1.10.5 whilst the live site does.

Jigoshop team – can you replicate?

I use the Checkout Fields Manager currently: https://www.jigoshop.com/product/checkout-fields-manager/

Normski, I believe I have found the issue.

jigoshop/classes/jigoshop_validation.class.php

There is a function as follows:

/**
	 * Checks for a valid postcode for a country
	 *
	 * @param   string  postcode
	 * @param  string  country
	 * @return  boolean
	 */
	public static function is_postcode($postcode, $country)
	{
		if (strlen(trim(preg_replace('/[\s\-A-Za-z0-9]/', '', $postcode))) > 0) {
			return false;
		}

		$country = strtoupper(trim($country));
		$postcode = strtoupper(trim($postcode));

		if (!isset(self::$postcodes[$country])) {
			return false;
		}

		if (Jigoshop_Base::get_options()->get_option('jigoshop_enable_postcode_validating') == 'yes') {
			$regex = '/'.self::$postcodes[$country].'/';
			jigoshop_log("VALIDATE POSTCODE: country = ".$country." & regex = ".$regex);

			switch ($country) {
				case 'GB':
					return self::is_GB_postcode($postcode);
				default:
					$match = preg_match($regex, $postcode);
					if ($match !== 1) {
						return false;
					}
			}
		}

		return true;
	}

Specifically the line

case 'GB':

Caused me to look further up, adjusting the line

'UK' => '^(GIR|[A-Z]\d[A-Z\d]??|[A-Z]{2}\d[A-Z\d]??)[ ]??(\d[A-Z]{2})$',

From UK to GB fixes the issue for me.

Jigoshop, strangely this only occurs on my live environment and not test.

Further to this I have checked, Jigoshop setting to validate post code is disabled but clearly javascript is still doing so.

I am also seeing this behaviour with UK post codes, both with a space in the post code and not.

To be honest, I use the universal analytics exclusively so hadn’t checked. Looks like those using the old tracking method will still work for a while as Google say they will allow classic for 2 years after universal tracking became the standard.

Marcin thanks for the fast response and beta code.

Can confirm that 1.10beta3 modifications to jigoshop_actions.php do:

1. enable analytics.js
2. add ecommerce tracking js
3. result in ecommerce tracking data in Google Analytics

However you have moved the entirety to analytics.js and some sites may be using ga.js still (even if against Google recommendation).

Strongly recommend for final release you add an option to allow user to choose between analytics.js (I suggest this is default) and ga.js (which could provide a warning?).

Also as a follow up I’m not 100% certain that the following line (811) works as intended

remove_action( ‘wp_head’, ‘jigoshop_ga_tracking’, 9999 );

Installing 1.9.2 appears to have resolved this issue, many thanks.

I’ve just reinstalled WP 3.9.1 with Jigo 1.9.2 and no longer appear to have this issue.

I notice that 1.9.1 has changed the jigoshop_countries.class.php which I was also using to override the EU VAT calculation system. However it doesn’t appear to have resolved this issue as tax for non-EU countries continues to not be applied.

I had this in my dev site (before I decided to rebuild) and had to use the db to disable the plugin before getting into admin to re-enable.

1.1.0 fixes this, thanks to Kevin!

Having looked at the plugin file there is a single line missing.

Add after add_action(‘wp_enqueue_scripts’, ‘load_scripts’); in fancy-box/fancybox.php

add_action(‘wp_head’, ‘fancybox’);

Although argument could be made that you should use the wp_footer hook instead so that the script isn’t render blocking.

I’m seeing the same behaviour with v1.0.9 on WP3.9 with a Twenty Twelve child theme.