fbpx
Want To Add Extra Images Per Product Variation For Free? Download Now

Variation Price displayed incorrectly on Shop Page, OK on Product Page

Igor Maly

Hello,

I have variable product with variation attribute Size (M, L). I have set prices for M=1.55, L=1.70 (incl. VAT). Prices are displayed correctly on Product page, when I select L, price shows 1.70.

On Shop page however, when no variation is selected, price is shown as 1.55-1.70 (which is OK) but when I select M, price shows as 1.64 (and for L it is 1.80).

Moreover, when I choose to show prices ex VAT, without a variation selected it shows 1.29-1.42 (correct), but once I select M, I again get 1.64 (and 1.80 for L).

It looks like there is some error calculating price to be shown once a variation is selected.

 

Hakik Zaman

Hi Igor,

Thanks for getting back to us.

Can you please give us temporary admin access to your site? We’ll try to investigate the issue for you.

You can add new users by going to Users > Add New set the user and password for us, set the role to admin and set the info here.

And add your site URL, login username, and password in the site login area. Follow this guideline: https://www.useloom.com/share/27c1f2ac633c4060b2da883d946107d7

Hope to hear from you soon!

Igor Maly

Hi Hakik,

I’ve created a staging site and admin access there, see the updated site login area.

Some steps to follow to simulate the misbehaviour (all prices in EUR):

in shop, search for “Fairytale”, should give one product with two variations, M and L
default pricing (for zone with 20% VAT) is M=1.55, L=1.70
that gives ex VAT prices M=1.291666, L=1.416666
in left sidebar from Show… combobox, select Show prices without VAT
product shows as priced 1.29-1.42 (correct, these are the above prices rounded to 2 decimals)
select variation M — price shows as 1.55 — incorrect
the same for L — shows as 1.70 — incorrect
^^ repeat last 4 steps for country with different VAT rate than 20% (e.g. Hungary has 27%) — without a variation selected, price range is shown correctly, but when selecting any variation, prices are still 1.55/1.70 regardless of VAT rate (country) chosen

That is just a simple example. You are welcome to find the culprit 😉

Igor Maly

Ticket has been closed without resolution :/

Hakik Zaman

Hi Igor,

How many approximate variations do you have with each product?

Hope to hear from you soon.

Thank You

Igor Maly

It depends, I have products with just one variation, and also with 20.

Hakik Zaman

Hi Igor,

Please set the threshold like this- https://paste.pics/QKTNV

Also, the staging site is not working from my side. Will you please check the staging site and let me know the update?

Thank You

Igor Maly

I have set the threshold to 20.

Also updated the staging site info — the previous one has been deleted long time ago.

 

Hakik Zaman

Hi Igor,

Did the threshold(20) resolve the issue?

I have visited your site and found prices like this- https://paste.pics/QKTY2

Thank You

Igor Maly

It seems that for archive/shop page, prices for individual variations get cached somehow, and then the cached price is displayed no matter the current VAT country chosen.

Hakik Zaman

Hi Igor,

You didn’t provide the admin access- https://paste.pics/QKUBX

Can I have the admin access to your site?

Hope to hear from you soon.

Thank You

Hakik Zaman

Hi Igor,

Did you change the price settings or snippet?

The price is not changing on the archive/shop page.

The Health & Troubleshooting Plugin is not working on your site.

So, I was unable to check the plugin/theme conflict.

Thank You

Igor Maly

I am confused — the last time I checked, prices changed. Now I see the same “from …” price no matter which combination of attributes I select.

I will look into it and get back to you later today. Thank you.

 

Igor Maly

Hi Hakik,

I have altered the staging site so that it better shows the issue. I have also deleted most of the products: for our demo, five is enough. I have disabled all Jetpack caching as well.

First thing: the site now displays prices on front-end in “debug format”. First comes the price itself, including the currency symbol. This is followed, in parentheses, with info about at which point in code the price has been calculated, and what tax setting (country/rate) was in effect at that point. At the end of price text, after @ sign, is the timestamp of that particular price generation.

When opened for the first time (https://mmmm.sk/qpfqcufo/), the site defaults to country Slovakia, where VAT rate is 20%.

We see one simple product with price “19.99 € (!4:simple[SK/20]) @1710768325”.  19.99 € is the product price. “!4” is the point in code where this price come from, “:simple” indicates the product type, “[SK/20]” shows the price was calculated with Slovak VAT rate of 20%, and 1710768325 is the (UNIX-like) timestamp when the price has been computed. This will be important later.

For variable products, price displayed starts with “from “. This is different from the standard woocommerce implementation, where the minimum and maximum prices are chosen from all the variations, and they are shown in “min – max” manner. In my shop, I sell some products both by package and by piece. Moreover, the price for one piece varies — if one buys more pieces, the price per piece falls down. Thus, I want the price to be shown to correspond to the overall minimal price one can achieve. This is in  case one buys a pack. Then, price for a piece comes from the price of the pack, divided by count of pieces in the pack. We can see the calculation here: “from 1.21 € (!3:=10.9/9[SK/20] @ …”. Code point !3 is for calculating the minimum from the pack price by division, and we see the pack was for 10.9, containing 9 pieces (“=10.9/9”), leading to per-piece price of 1.21. Again, SK VAT of 20% has been used.

Let us now select the single variation from the first product.

The  price displayed now changes to “10.90 € (!4:variation[SK/20]) @ 1710765760”. Here, “10.90” is the price itself, !4 is the point in code again, “:variation” indicates that the price is for a variation of variable product (compare with !4:simple above), again SK/20 VAT rate used, and please mention the timestamp. It is now 1710765760, which is greater than the 1710768325 timestamp used for the initial page rendering. If we de-select some attribute and select it again, we will get the same price, with the exact same timestamp. This shows that the price has been computed once, and it is cached (presumably on front-end).

So far, all the results were okay. Now, let us see the issue.

First, we select the country to “ship to” to Hungary. There is 27% VAT rate in Hungary, and we want the front end to show the prices with 27% VAT now.

After the page completes rendering, we see that all product prices now include [HU/27], which is expected and okay. Timestamp of prices changed to 1710769718/19, which tells us they have been calculated after we changed the country to HU (well, certainly later than any other prices we have seen so far).

And now, let us again select the first attributes of the first product, to see the variation price for specific variation.

The price we get is “10.90 € (!4:variation[SK/20]) @ 1710765760”. And this is wrong. For one, it shows Slovak 20% VAT has been used, while we have already switched to HU/27. Furthermore, the timestamp is the same as we have seen while looking at this variation before — while the site was switched to Slovak VAT.

This shows that the display price for this particular variation did not get updated (recalculated), and that is what this ticket is about.

Correct expected behaviour would be to display (somewhat higher) price with HU/27 indicator, and with timestamp greater or equal to 1710769718 (the moment we switched the country to HU).

Prices are calculated within my custom code snippet named “Price From”. Every return statement has unique !# designation (!1 to !6), and contains the tax rate and timestamp info. Shown example indicates that the code in snippet has not been called for updated HU price — the front end just reused previously cached SK price, which is incorrect.

Prices change if I change the currency via currency switcher. I would expect them to change after changing the VAT rate via country switcher as well.

I hope this explains the whole issue. If you have any questions, please ask away.

Thank you

Igor

Hakik Zaman

Hi Igor,

Could you record me reproducing your issue using a tool like this? https://www.useloom.com
It will help me contact the development team.

Thank you

Igor Maly

I took screenshots and tried to insert them into the description. I am not sure if that worked, for I don’t see the pictures in the text now. Would it suffice if I share them?

If I record a video, there will be different timestamp values in it now.

Igor Maly

By the way, changing the threshold as you suggested (to 20, even to 100) did not help. Some variations got updated after changing the country, but not all of them.

 

Hakik Zaman

Hi Igor,

If I record a video, there will be different timestamp values in it now.

The timestamp is not our concern. We want to check the price.

A video will help me to share with our development team.

It is difficult to read all the text for them. I hope you will understand.

Some variations got updated after changing the country, but not all of them.

How many variations with those products?

Thank You

Igor Maly

I have tried to record the video.

On the first attempt, variation prices started to show for Bangladesh (country code BD).

Any chance someone from your team is from BD?

I started a new session in Edge InPrivate window.

Igor Maly

Before we get any further, I would like to know, why the price for specific variation did not show up with VAT for Slovakia. Where did the BD came from, when I started a new incognito session? Are the data shared somehow between sessions?

Hakik Zaman

Hi Igor,

Before we get any further, I would like to know, why the price for specific variation did not show up with VAT for Slovakia. Where did the BD came from, when I started a new incognito session? Are the data shared somehow between sessions?

Unfortunately, this query is not related to our plugin. We are from Bangladesh. I didn’t log in to your site today.

Our plugin has no connection with Session. Please try to flush your caches like- browser cache, caching plugin cache, and server-side cache.

Is it working well without modifying the prices (without timestamp, country code, etc.)?

Thank You

Igor Maly

Modifying the prices is irrelevant to the issue. As I have mentioned earlier, I need the price to be custom-generated. The issue is caching: why does the plugin show cached/not updated values.

 

Igor Maly

It would help (probably even solve the issue) if caching/preloading could be disabled, so that the front end always gets the price from backend. I would rather have correct values, than fast incorrect ones.

I know there is an option to disable the preloader on product and archive pages separately. Tried to disable it, no effect. I have read on some other’s issues that the preloading switch does not really do anything.

Hakik Zaman

Hi Igor,

I have added the following code using the Code Snippets plugin-

function gwp_128280_wvs_country_currency_support( $args ) {
$tax_location = WC_Tax::get_tax_location();
$current = $tax_location[0];
if ( $current ) {
$args[ 'wc_country_preselect' ] = $current;
}
return $args;
}
add_filter( 'woo_variation_swatches_rest_add_extra_params', 'gwp_128280_wvs_country_currency_support' );

Please check now if the shipping country(& price) are correctly changing or not.

Hope to hear from you soon.

Thank You

Igor Maly

Hi Hakik,

thank you for the fix snippet. It seems that it does help, all the prices look good now.

That is, until I enable the Redis object cache.

I have temporarily disabled it so that it would be easier to figure out the issue for your team. It is however meant to be enabled in production. Would it be possible to make it work correctly with the cache enabled?

Enabling/disabling the cache is most easily done from the admin dashboard, top bar, Object Cache / Settings. It is currently enabled again; you have admin access, so fell free to change the settings as necessary.

Hint: the key to the cache should probably contain country info.

Thank you,

Igor

Hakik Zaman

Hi Igor,

I have modified the snippet-

function gwp_128280_wvs_country_currency_support( $args ) {
$tax_location = WC_Tax::get_tax_location();
$current = $tax_location[0];
if ( $current ) {
$args[ 'wc_country_preselect' ] = $current;
}
return $args;
}
add_filter( 'woo_variation_swatches_rest_add_extra_params', 'gwp_128280_wvs_country_currency_support' );
add_filter('woo_variation_swatches_get_cache_key', function($ks, $k, $s){
// Shipping Country
$tax_location = WC_Tax::get_tax_location();
$current = $tax_location[0];
if ( $current ) {
$s .= sprintf( '_%s', $current );
}
return $k . $s;
}, 10, 3);

Please check now and let me know your thoughts.

Hope to hear from you soon.

Thank You

Igor Maly

Hi Hakik,

Thank you for both fixes. I have done some testing and everything looks okay so far.

I am going to re-enable the plugin on production site with the fixes provides.

You can mark this ticked as solved now. Thank you for your assistance.

Kind regards,

Igor