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 next available supporter will start replying to tickets in about 0.56 hours from now. Thank you for your understanding.

This topic contains 13 replies, has 4 voices.

Last updated by George Botsev 1 year ago.

Assigned support staff: George Botsev.

Author Posts
February 15, 2017 at 9:57 am #1208774

Bjorn

Hi,

My site sells unique products, so after selling an item, the item is out of stock.

After installing WPML I noticed a difference in products in category count between my default language version and my WPML translated version of the website.
When you buy something while using the default language version, the product count per category will show the correct adjusted number of products. Switch to the WPML translated version, and the number is unchanged (too high).

The same error happens when you buy something from the WPML translated version and then switch to the default language version.

I checked the database termmeta table for both category IDs (default language and WPML translated copy) and found one has a product_count_product_cat setting of 5 (which is correct) and the other one shows a product_count_product_cat setting 7. It seems when selling something, these numbers are not updated correctly.

I can sync the numbers by accessing wp-admin, switch to the out-of-sync language and use 'Terms Count' in WooCommerce Tools, but that is a bit of a hassle to do after every purchase.

I think it is a bug, but if there is a setting I need to change to get this to work correctly, please let me know.

February 15, 2017 at 7:54 pm #1209470

Yvette
Supporter

Languages: English (English ) Spanish (Español )

Timezone: Europe/Madrid (GMT+02:00)

Hello.

I will be helping you with this issue. I understand that the term counts are not synchronising between translations.

I would like to take a closer look to see if all WCML configuration is correct.

1. ) Temporary access to your system
Could you please provide access to your system (wp-admin and ftp) so that I can further investigate this particular problem? The fields to provide this data are included in a private section that I will open for your next response. You can find it above the comments area. The information in this private section is only visible between WPML Support and you

2. Test Case
Could you please provide a test case that I can examine? I would need the product id. Please also include steps on how to replicate the problem you found.

If it is not too much trouble, I would suggest creating a test product that I can use so as to not affect any of your real data.

3. System Snapshot
Do I have your permission to take a snapshot of your system that I can install locally on our servers? I would need this to be able to escalate the problem, if necessary, to our 2nd tier support - especially if this is indeed a bug.

Thanks !

February 16, 2017 at 10:45 am #1209909

Yvette
Supporter

Languages: English (English ) Spanish (Español )

Timezone: Europe/Madrid (GMT+02:00)

Hello.

I took a look at your site and can see that the product count displaying in your menus is being generated by a custom function added to functons.php of your child theme to extend the menu functions of the parent theme:

class SD_WC_productentellen_walker extends Walker_Nav_Menu {
  // Aantal producten in een categorie weergeven bij menu optie

  function display_element( $element, &$children_elements, $max_depth, $depth = 0, $args, &$output ) {
    if ( $element->object == 'product_cat' && $element->menu_item_parent > 0 ) {
     $check_aantal = get_terms( array( 'taxonomy' => 'product_cat', 'include' => $element->object_id ) );

     $class  = 'afwezig';
     $aantal = 0;

     if ( $check_aantal[0]->count > 0 ) {
        $aantal = $check_aantal[0]->count;
        $class = 'aanwezig';
     }
     
     $element->title .= "<span class='" . $class . "'> (". $aantal . ")</span>";
    }

    parent::display_element( $element, $children_elements, $max_depth, $depth, $args, $output );
  }

} 

 ?>

I´m afraid that our support policy does not cover the support of custom code. When you need custom coding which extends the WPML or compatible theme functionality, we recommend contacting one of WPML certified consultants here:
https://wpml.org/documentation/support/wpml-contractors/

You might also review the following link to make sure you are correctly invoking the WPML API to retrieve multilingual content fro the db.
https://wpml.org/documentation/support/wpml-coding-api/wpml-hooks-reference/

Unfortunately we do not yet have any published doucmenation on WooCommerce Multilingual API calls.

February 16, 2017 at 12:03 pm #1210020

Bjorn

Hello Yvette,

thank you very much for your reply. Unfortunately I have to disagree with you.

The problem is not with the custom coding. This code retrieves the record for each language correctly.
The problem is that WooCommerce doesn't update the product_count_product_cat entry of the WPML created translated duplicated category when using the shop in default language. And vice versa when using the translated language.

This losing track of what to update is not a flaw in the custom coding, which only retrieves the product_count_product_cat value from the database, it seems a flaw in WPML not correctly notifying WooCommerce to update all language instances of this category. Isn't it WPML's responsibility to make WooCommerce aware of these duplicate instances?

Can you look into it a little more?

Thanks in advance.

February 16, 2017 at 2:00 pm #1210169

Yvette
Supporter

Languages: English (English ) Spanish (Español )

Timezone: Europe/Madrid (GMT+02:00)

Hello.

I did think that there could be a problem with the scynchronisation of the product. However, all dashboard views of the products were reflecting the transaction I did.

Also, you can see that the sidebar shop widgets are correctly showing the right count. Only the menu is not aligned.

This leads me to conclude that the problem is with the code implementation. It may be that the code is fine but its integration/update with the Walker menu is not synchronised in the manner you need. (e.g. a late Ajax updat, javascript...etc) I am not sufficiently versed in how Walker menus work to be able to advise you on what specifically might be wrong with the code, but a contractor will.

February 17, 2017 at 5:45 am #1210740

Bjorn

Hi Yvette,

maybe you can forget about the menu_walker for a minute and focus on the database entries for any two WooCommerce product categories, one in default language, one in translated language.
More specifically the 'product_count_product_cat' entries for those categories.

Let's say I have a category 'Boeken' with term_id 2 and 17 products attached to it. The database 'product_count_product_cat' entry shows 17.
I install WPML and start translating things, the category with term_id 2 gets an English equivalent 'Books' with term_id 23. Properties are copied so the 'product_count_product_cat' entry for this category also shows 17

All is fine.

Then a customer enters my webshop using the English version of my website, and buys an item from category 23. After finalizing the purchase, WooCommerce updates the 'product_count_product_cat' entry for category with term_id 23, but leaves the 'product_count_product_cat' entry of category with term_id 2 (which is essentially the same category) untouched.

Now the categories are out of sync.

This whole process has nothing to do with the menu_walker. WooCommerce is not aware of which category term_id is linked to which translated category term_id. In my opinion WPML is the only one who 'knows' about the connection and therefor should take care of things.

If this out-of-sync situation was due to asynchrone scripts, it would resolve itself over time, which is not the case.

I hope you can solve this for me. If not, should I talk to a programmer, or contact Mr Kaufman directly?

Thanks again

February 17, 2017 at 1:28 pm #1211117

Yvette
Supporter

Languages: English (English ) Spanish (Español )

Timezone: Europe/Madrid (GMT+02:00)

OK.

I take your point and I can confirm that executing a simple purchasing transaction leaves this termmeta field unsynchronised on your system.

I have checked with my colleagues on how to handle this situation based on the following points:

1. WPML does not commit to synchronising *all* fields in the database, however we do provide a mechanism for commercial plugin and theme developers to create and register fields for synchronisation through our WPML and WCML APIs.

2. WPML provides support for commercial solutions and their development teams in this endeavour. For clients who need custom work for any new features, we need to direct them to certified clients. This is so that our support forum can be dedicated to ensuring that our product and partner solutions are working as expected.

Having stated this "official" position, we can see that our testing scripts in WCML do "test" this particular field although it may not be yet used. So, it may be that this is a bug as you state or...it may be something that is coming in future releases! I will be sending a note to our development team to verify this.

Depending on their answer I can take one of two actions:
A) Escalate to development as a bug
B) Refer you to a contractor (again).

So, please be patient while I do this. If you have any other notes I can add to the question please feel free to add to this thread.

Thanks.

February 17, 2017 at 3:09 pm #1211216

Yvette
Supporter

Languages: English (English ) Spanish (Español )

Timezone: Europe/Madrid (GMT+02:00)

Hi again.

I´ve been given the go-ahead to escalate your case to our 2nd tier support. They have received a snapshot of your system and the detailed steps to replicate the issue.

They will interface with you now.
Kind regards.

February 20, 2017 at 10:29 am #1212323

George Botsev
Supporter

Languages: English (English )

Timezone: Europe/Sofia (GMT+03:00)

Hello, I am George from second tier support.
I managed to reproduce the issue and I have escalated it to our developers.
When I have more information, I will let you know.

February 21, 2017 at 10:51 am #1213403

Bjorn

Hi Yvette and George,

Thanks for diving into this and for the support so far, really appreciate that!

Since I was really planning to go live this week, I'm really curious when to expect any updates on this? I'm kind off OK with going live with the count issue (preferably not obviously).
But I'm not sure if it is wise for me to go live if you guys need to do any further testing...

Thanks,

February 21, 2017 at 12:45 pm #1213558

George Botsev
Supporter

Languages: English (English )

Timezone: Europe/Sofia (GMT+03:00)

I cannot give exact release schedule for this and if it would fix your problem exactly.
As far as I see, the fix for the synchronization of this count will be available in the next release of WooCommerce Multilingual, so please be patient.

March 9, 2017 at 1:32 pm #1226436

George Botsev
Supporter

Languages: English (English )

Timezone: Europe/Sofia (GMT+03:00)

Hello again,
We just released a new version of WooCommerce Multilingual - 4.1 which should have a fix for the issue that you have reported here.

Please remember to backup your database and files first before you proceed! You can use a plugin for this if you like (example: http://wordpress.org/plugins/duplicator/)

October 2, 2018 at 10:06 am #2780992

Norman

Hello George,

I'm aware that this thread is marked as resolved but we've just noticed this exact same issue while running WooCommerce Multilingual 4.3.6. Is this a new issue or an old issue resurfacing?

I'm looking forward to your reply.

Kind regards,
Norman Lorch

October 2, 2018 at 11:11 am #2781225

George Botsev
Supporter

Languages: English (English )

Timezone: Europe/Sofia (GMT+03:00)

Hello @norman
I cannot be sure if this is the same issue resurfacing.
Currently, to my knowledge, nobody has reported that error.
If you see such a problem in your install, we can try to debug and help you, but please open a new ticket as, as you already noted - this ticket was closed as resolved, more than 6 months ago.