Please see the chat I started before and get back to it

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.

Our wait time is higher than usual, please make sure you are meeting the minimum requirement - https://wpml.org/home/minimum-requirements before you report issues, and if you can take a look at current Known Issues - https://wpml.org/known-issues/. Thank you.

Sun	Mon	Tue	Wed	Thu	Fri	Sat
-	8:00 – 13:00	9:00 – 13:00	9:00 – 13:00	8:00 – 12:00	8:00 – 12:00	-
-	14:00 – 17:00	14:00 – 18:00	14:00 – 18:00	13:00 – 17:00	13:00 – 17:00	-

Supporter timezone: Europe/Zagreb (GMT+02:00)

Tagged: Documentation request

This topic contains 10 replies, has 2 voices.

Last updated by Bruno Kos 7 months ago.

Assisted by: Bruno Kos.

Author	Posts
September 2, 2024 at 8:18 am #16130437
ondrejd-2	Background of the issue: I am trying to use the WCML plugin to reflect different prices in WooCommerce lookup tables. The current setup stores all prices in the parent product, which I find problematic. Here is the link to the page where the issue can be seen: hidden link Symptoms: The WCML plugin doesn't reflect different prices in WooCommerce lookup tables. I believe the method of storing all prices in the parent product is flawed. Questions: Why doesn't the WCML plugin reflect different prices in WooCommerce lookup tables? Is there an alternative workaround to avoid storing all prices in the parent product? Check the screenshot. All the product translations are stored with default price in Woocommerce lookup table. This is unacceptable.
September 2, 2024 at 12:53 pm #16131752
Bruno Kos Supporter Languages: English (English ) German (Deutsch ) French (Français ) Timezone: Europe/Zagreb (GMT+02:00)	Hi, How prices are stored in database can't be changed, that's why we offer an interface to set prices for different languages. WooCommerce typically stores product prices in the parent product data (i.e., the original product entry). The default behavior is to store prices in the lookup tables for performance reasons, and these tables are often tied to the parent product ID. As a result, all translations of the product will inherit the same price from the parent product unless explicitly overridden. If you think it should not be this way and have an explanation or an example on where this fails let us know so we could check (e.g with Lookup Table Caching).
September 2, 2024 at 1:50 pm #16132102
ondrejd-2	It is not Woocommerce that stores the prices in parent products. It is Woocommerce Multilingual - your plugin. I don't know the exact logic you use to output the prices at front-end but I know for sure that the front-end is actually the only place where it works as intended. When you use any of the plugins that provide XML/CSV feed functionality it always doesn't work with WCML. No matter what level of compatibility you or the plugin developer declares. It never works because of the prices in parent product. I managed to create workarounds for the issue with feeds that's both nasty and slow, but that's about what your support gave me. Now I stumbled upon this issue once again in form of product lookup tables. If you take a look at the screenshot I attached you will see that every product is stored there 7 times with exactly the same information. Now for what reason you consider this to be the correct behavior? First of all, the table now cannot be used to filter products by price in different currencies. Second, the table is absolutely unnecessarily 7 times bigger because there is no reason to store every singe product with same data 7 times. It would however make perfect sense to store every product 7 times if you just finally accepted that the prices should be stored in product translations instead of parent product.
September 3, 2024 at 5:49 am #16133906
Bruno Kos Supporter Languages: English (English ) German (Deutsch ) French (Français ) Timezone: Europe/Zagreb (GMT+02:00)	I submitted this as feature request for our developers to check but I can't promise anything as that would be a major change. I will update here as soon as I have some feedback.
September 3, 2024 at 7:09 am #16134103
ondrejd-2	Well, the thing is I need a solution right now and not a promise of "maybe one day we will do something about it". If you cannot provide me with even a temporary solution then transfer the ticket to someone who can think in terms of code and provide some answers.
September 3, 2024 at 7:30 am #16134164
Bruno Kos Supporter Languages: English (English ) German (Deutsch ) French (Français ) Timezone: Europe/Zagreb (GMT+02:00)	There is no further escalation for this issue, as there is already an internal development ticket where our team will review and discuss it. Please note that significant changes cannot be implemented immediately. Additionally, we cannot modify or code changes to our plugins based on custom client requirements. If you need to change or extend the functionality of our plugins, you may reach out to one of our recommended contractors: https://wpml.org/contractors/
September 3, 2024 at 7:45 am #16134211
ondrejd-2	No. I need a workaround to a really badly designed feature so I don't have to spend hours, maybe days reverse engineering the mess. So kindly, send this to someone who can talk about it. You obviously cannot or don't want to. Doesn't matter really.
September 3, 2024 at 11:01 am #16135107
Bruno Kos Supporter Languages: English (English ) German (Deutsch ) French (Français ) Timezone: Europe/Zagreb (GMT+02:00)	As mentioned previously, our developers are already investigating this issue and will provide their insights, which I will then share with you. I will not escalate this ticket to another support agent, as they would take the same approach.
September 3, 2024 at 2:06 pm #16136121
Bruno Kos Supporter Languages: English (English ) German (Deutsch ) French (Français ) Timezone: Europe/Zagreb (GMT+02:00)	I have a response from our development team: 1. This is a known issue related to filtering products with manual secondary currency prices. A fix is planned and scheduled for the WCML 5.5.0 release, though the release date is not guaranteed. 2. Understand that manual secondary prices are not tied to translations. This functionality operates independently of WPML and translations; it represents a separate dimension in the pricing structure. 3. Unfortunately, there is no available workaround or snippet to resolve this issue at this time.
September 4, 2024 at 7:01 am #16138558
ondrejd-2	Let's be realistic here. Now we are on 5.3.6, so you are telling me that this behavior, which is by the way present for years now, might not get fixed in another 12 months? Is that right?
September 4, 2024 at 9:23 am #16139344
Bruno Kos Supporter Languages: English (English ) German (Deutsch ) French (Français ) Timezone: Europe/Zagreb (GMT+02:00)	That's correct, I cannot guarantee any dates for this to be implemented.