Home›Support›English Support›[Waiting for user feedback] Script to update WCML pricing - issue with variable product price values being overwritten at random
[Waiting for user feedback] Script to update WCML pricing - issue with variable product price values being overwritten at random
This is the technical support forum for WPML - the multilingual WordPress plugin.
Everyone can read, but only WPML clients can post here. WPML team is replying on the forum 6 days per week, 22 hours per day.
Background of the issue:
I am trying to update the default price (EUR) and the GBP and USD values for a list of source language SKUs using a script. We have WCML set up with 'Set prices in other currencies manually'. The script seems to work okay initially, and the values are correct after the price sync script is run. Here is the script I am using: hidden link.
Symptoms:
After running the script, the EUR value of translated product variations is being overwritten with the GBP price value at random times. This is unexpected behavior.
Questions:
Why are the EUR values of translated product variations being overwritten with GBP values?
How can I prevent the price values from changing at random after running the script?
Thanks for the details. Since the issue only occurs on production and is hard to reproduce, we’ll need a copy of the site where the problem can also be observed. Please try to replicate the issue as best as you can on a staging copy and let us know once it’s ready. This will help us investigate further.
I’m sending over the details for the staging copy shortly after this message.
We’ve been looking into this in depth, and here’s what we’ve observed so far:
The custom script that updates the prices works correctly. It updates only the default language prices, and those values are then automatically copied correctly to all translations. We have checked and immediately after running the script, prices across all languages are fully correct. However, as time passes, the GBP price starts being copied across to the main price on translated products — but only for product variations.
What makes this even more unusual is that fixing a variable product with incorrect translated prices only requires opening the product in the default language in the admin area and clicking “Update”. No data changes are needed, and all translated prices instantly realign with the default language. The GBP price still creeps back into the main translated price later on.
The price update script is located here:
wp-content/plugins/sf-woocommerce-connector/sync_product.php
And the functions involved in updating prices are update_wc_product_price and get_existing_wc_skus
This behaviour is quite complex to summarise, so we’re more than happy to jump on a call to walk you through everything if that helps.
For the staging copy, we tried to reproduce the issue but couldn’t replicate it. The change in prices only happens on the production site.
These are the only differences between production and the staging copy we have made for you:
- WPML detected a change in the site’s URL and set the site as secondary domain
- WooPayments is in Safe Mode
- Jetpack is disabled
- WP Mail SMTP plugin is disabled
- We have scrubbed user data
- It is host in a different server
We’re not fully clear on how WPML keeps prices synchronised internally or how the wcml_sync_hash metavalue works (deleting this value caused all variable products to end up with incorrect translated prices in less than a day – we normally see around ten affected products per day at most). We’ve searched extensively for any process responsible for syncing or overwriting prices, but we haven’t been able to identify what is triggering the overwriting.
We’ve also attempted to log product changes via WordPress hooks, but we haven’t been able to identify a process that alters the main price in translations.
We also tried partially commenting out the function processDelayedFields in:
wp-content/plugins/woocommerce-multilingual/inc/translation-editor/class-wcml-synchronize-variations-data.php
but that didn’t resolve the issue.
At this stage, we suspect there may be some form of caching involved, as the prices begin to shift one by one throughout the day. We haven’t yet tested clearing caches programmatically after running the script (for example using wc_delete_product_transients or wp_cache_delete), because the prices also become incorrect even when they are updated directly through the admin area, but we are willing to try this approach..
Once the staging details are added below, please let me know if you need anything else from us.
Thank you for sharing the staging website, but since the issue is not happening there, is not of much use.
Since you shared that updating a product via the UI also leads to the same issue, it seems that the script is not part of the cause of the issue. Can you please confirm that? If the issue still happens after a manual update via WordPress admin.
Also, our best guess so far is that cached value is causing that. Can you please deactivate the cache and compare the behavior? Check if the issue is there even without the cache activated.
We believe we may have isolated the cause of WCML incorrectly overwriting variable product base currency prices (EUR) with values from a secondary currency.
In our case, it appears to be a conflict involving WCML and two plugins, Optimization Detective and Image Prioritizer. However, the behaviour is not necessarily limited to those plugins. Any plugin, scheduled task, or process that triggers save_post outside of the normal admin context, particularly when $_POST is empty, could potentially lead to the same issue where WCML overwrites the base currency prices using the currently active secondary currency.
I have not yet put a proof of concept together, but I wanted to share this update in case it helps narrow the investigation. It is not yet clear whether WCML should be accounting for this scenario or whether it is stemming from unintended behaviour within Optimization Detective.
Optimization Detective triggers a background cache invalidation routine which fires the save_post action. Normally, when a product is saved in the admin, $_POST is populated. In this scenario, $_POST is empty because the update is initiated in the background via a scheduled event.
Optimization Detective and Image Prioritizer run on the front end using real traffic to detect LCP images across different screen sizes, sending this data back via the REST API. The issue may not have appeared in local or staging environments simply because there was not enough real front end activity or variety of screen sizes to trigger the update and cache invalidation.
Thank you for bringing that to my attention. Nonetheless, we can't really investigate the live website, as we don't have a consistent way to reproduce the issue, and we can't apply tests on it, since it might compromise its functioning.
It seems, though, as you are getting close to isolating and reproducing the issue. You shared that “… Any plugin, scheduled task, or process that triggers save_post outside of the normal admin context, particularly when $_POST is empty, could potentially lead to the same issue where WCML overwrites the base currency prices using the currently active secondary currency.”
Is there a way you could force that to happen and test if the prices would change?
Please let me know if you can get to a proof of concept or consistent way to reproduce the issue. Again, preferably on staging or in a copy I can invetigate. Thank you for your patience.
