Skip Navigation

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.

This topic contains 22 replies, has 2 voices.

Last updated by Andreas W. 3 months ago.

Assigned support staff: Andreas W..

Author Posts
August 11, 2021 at 2:45 pm #9383471

pieter-janP

The problem:
our client is having a very hard time, because the products on the website break sporadically. Some English variable products on the website are failing to show the color attributes. During debugging we found out these product are trying to retrieve a Dutch color instead of English. While there is no color to be selected, customers can't buy these products. If we re-save the product the color is found again. However, they have to do daily checks on their site because the problems keep on coming back sporadically. If we take a look at the back-end we see the correct color is linked to the product, the problem is only occurring on the front-end. It has nothing to do with our code, because the incorrect color is already present in our Wp_Query when we retrieve the posts.

Link to a page where the issue can be seen:
While products are being fixed every day and the problem exists sporadically, we can't assure the problem exists on this page. But at the moment of writing the problem is visible on this overview page, where some products are missing colors: hidden link

I expected to see:
Color swatches on every product.

Instead, I got:
Some product do not show colors.

August 12, 2021 at 1:52 am #9385911

Andreas W.
Supporter

Languages: German (Deutsch )

Timezone: America/Lima (GMT-05:00)

Hello,

It would be imjportant to knwo what is triggering the issue.

Could it be the case that the images do work after translating the product but they disappear once product is purchased? I can offer to take a copy of the site for testing, or if youcould create a staging we could test it right away on your server.

I would like to request temporary access (wp-admin and FTP) to your site to take a better look at the issue. It would be better for a testing site where the issue is replicated.

You will find the needed fields for this below the comment area when you log in to leave your next reply. The information you will enter is private which means only you and I can see and have access to it.

Maybe I'll need to replicate your site locally. For this, I’ll need to temporarily install a plugin called “Duplicator” on your site. This will allow me to create a copy of your site and your content. Once the problem is resolved I will delete the local site. Let me know if this is ok with you.

IMPORTANT

Please make a backup of site files and database before providing us access.
If you do not see the wp-admin/FTP fields this means your post & website login details will be made PUBLIC. DO NOT post your website details unless you see the required wp-admin/FTP fields. If you do not, please ask me to enable the private box. The private box looks like this:
hidden link

The steps are also shown in this video: hidden link

Kind regards
Andreas

August 16, 2021 at 1:37 pm #9406963

pieter-janP

Hi Andreas,

Thank you for your extensive answer. Sorry for our delay, but had to do some more tests. We tested your assumption, but most products that break have not been purchased for a while.

We will setup a staging environment so you guys can take a closer look, without the pressure of breaking anything on live!

Problem description update: earlier we mentioned Dutch colors are linked to EN products on the front-end, but now we see some products that break also try to retrieve German colors.

August 16, 2021 at 3:13 pm #9407641

pieter-janP

We setup a staging just now. The moment we started the backup some products where broken, but after installing these products are not showing the same problems on our newly created staging. Now, we know our client fixed these products while our backup was generating. Don't know how Duplicator works, but could be possible that he included these fixes in our backup.

I will make another backup when new products break, while it's not worth investigating yet this way.

August 18, 2021 at 2:14 am #9416241

Andreas W.
Supporter

Languages: German (Deutsch )

Timezone: America/Lima (GMT-05:00)

Hello,

Please check if the issue could be cache-related by clearing the cache and delete any minified CSS/JS files.

I further can offer to create a test site on which you could install the essentially necessary plugin in order so that we can try to recreate the issue.

Best regards
Andreas

August 19, 2021 at 9:17 am #9424065

pieter-janP

Hi Andreas,

It's not cache related, like we mentioned the incorrect color is already present in our Wp_Query when we retrieve the posts. We also disabled WP Super Cache but this has no effect.

We made another backup and made sure no fixes where executed during the backup. We installed the backup and again all products where fixed.

We would like to give you acces to this newly created staging, like your are proposing. But the private box is not showing anymore, can you enable that?

Ps: if you want to see the problem live in action, take a look at the page below. The product "Joy - Green" is not showing a color and therefore can't be bought. If you check the classes, you see "Vert" which means the product is trying to retrieve the French Green color on an English page.

hidden link

August 20, 2021 at 2:06 am #9428797

Andreas W.
Supporter

Languages: German (Deutsch )

Timezone: America/Lima (GMT-05:00)

Hello,

Thank you for creating a Staging. The private reply form is enabled now.

Best regards
Andreas

August 21, 2021 at 8:25 am #9434383

Andreas W.
Supporter

Languages: German (Deutsch )

Timezone: America/Lima (GMT-05:00)

Hello,

In order to revise the issue, I need to verify the taxonomy and product translations, and settings. Also, I can recommend running the synchronization settings at WooCommerce -> WooCommerce Multilingual -> Status -> Troubleshooting.

Further, it would be really important to know, when the issue occurs in order to debug the issue. If we do not know which event is causing the issue it will difficult to find out what is causing it.

Could it maybe be that the attributes are not matching anymore after a product has been purchased or after an original product has been edited?

The provided credentials do sadly not allow me to access the site.

ERROR: The username or password you entered is incorrect. Lost your password?

Could you please revise and re-edit the earlier provided information?

Best regards
Andreas

August 23, 2021 at 6:37 am #9439343

pieter-janP

Hi Andreas,

I see our password change did not work, we changed the password so you can login with the credentials we shared earlier.

Like mentioned before we tested your assumption, but most products that break have not been purchased for a while.

We will check the troubleshooting later on live, will this only analyse or is there also a risk things break?

Kind regards,

Tom

August 24, 2021 at 8:29 pm #9453271

Andreas W.
Supporter

Languages: German (Deutsch )

Timezone: America/Lima (GMT-05:00)

Hello Tom,

My apologies for the delay in answering, as I am not working on Sundays on Mondays.

I am only writing you to let you know, that it is highly recommended to take a reliable backup of the website and database before running the WCML sync options.

These options sync language assignments and product details like stock, prices, attributes, and variations between products.
It rarely occurs but just in case an error could occur, please make sure to take a backup first.

I will be taking a copy of your website for further revision and contact you within some hours.

Best regards
Andreas

August 26, 2021 at 9:04 am #9463485

pieter-janP

Hi Andreas, I have some new insights on the problem!

While products sporadically break, we focussed on external connections that make edits on the website. The site is connected to "ShopWeDo", which is a logistics connection that sends packages and updates inventory on the website.

Last week we told our client to disable this connection for 2 days, so we could analyse the bugs for 7 days and possible find a connection. In the 2 days that the connection was disabled, we had no bugs. After enabling, the bugs where coming in again and we found out that most of the corrupt products where bought a few hours ago (also sometimes products only go corrupt after 5 or 6 days, so that's why we initially didn't see a direct relation to buying as a cause).

We already communicated with ShopWeDo and their first response is that they only update the stock of products, so that there is not much they can do and this should just work because it works for all their clients. So in my opinion there are 2 options:

1. There is a bug in the ShopWeDo connection: While the corrupt products are fixed after saving the page, I can imagine this might be caused due to an update script that is not executed correctly (in line with the WC/ WP terms). They also have some old scripts active from the old website, so the possibility is certainly there that the bug is caused on their end.

2. There is a bug in WPML: can imagine there might be bug in WPML, that causes the products to break after stock updates by a REST API connection.

Did you guys ever had a similar problem? And could you tell me if you might know a reason why the colors are mixed up after this update?

Kind regards,

Tom Raas

August 27, 2021 at 3:24 am #9467903

Andreas W.
Supporter

Languages: German (Deutsch )

Timezone: America/Lima (GMT-05:00)

Hello Tom,

I have taken a copy of the site for some testing and I have to admit that I had a tough time debugging the site and I am writing you to provide some first impressions and I am sorry for the very long message:

First thing, WCML should sync stock in the background when a purchase occurs, which is why for example it is not possible to update the stock for translated products manually. This field is blocked by default, as you can see on the WordPress Editor inside the product details of translated products.

Actually, when creating a product, the translated product will always get the stock from the original product, and then when an order occurs the stock should sync between products in the background.

In case of any issue between product variations we recommend running the WCML sync options at WooCommerce -> WooCommerce Multilingual -> Status -> Troubleshooting.

Further, please go to WooCommerce -> WooCommerce Multilingual -> Status and take care of the warnings found on this page which relate to the product permalink base and missing store pages.

Now, on the copy of this site I tested the following:

Example product "Oneway":

1) Change stock on the original product on variation ID #47161

The saving progress here takes very long, there shows up a WooCommerce related error on the browser debug console the PHP debug.log shows and error in:

PHP Notice:  id was called <strong>incorrectly</strong>. Product properties should not be accessed directly. Backtrace: require('wp-admin/edit-form-advanced.php'), do_meta_boxes, WC_Meta_Box_Product_Data::output, include('/plugins/woocommerce/includes/admin/meta-boxes/views/html-product-data-panel.php'), do_action('woocommerce_product_data_panels'), WP_Hook->do_action, WP_Hook->apply_filters, Channel_Engine_Product_Tab->woo_add_custom_general_fields, Channel_Engine_Base_Class->get_product_shipping, WC_Abstract_Legacy_Product->__get, wc_doing_it_wrong Please see <a href="https://wordpress.org/support/article/debugging-in-wordpress/">Debugging in WordPress</a> for more information. (This message was added in version 3.0.) in D:\Local Sites\owow\app\public\wp-includes\functions.php on line 5535

Apart from that there already came up an error once WP Debug was enabled. The error relates to Wholesale For WooCommerce:

PHP Notice:  Undefined variable: wholesale_type in D:\Local Sites\owow\app\public\wp-content\plugins\woocommerce-wholesale-pricing\inc\class-wwp-wholesale-metabox.php on line 339

Another odd thing, that the original stock was at value 86, and I tried to change it to 85, but once the very long loading progress finished the stock was set to 42.

Anyhow, I am not sure why this issue occured, but when checking the Dutch translation, I do see the same value of 42, which means stock sync works as expected.

At this point another error came to my attention:

PHP Notice:  register_rest_route was called <strong>incorrectly</strong>. The REST API route definition for [php]wc/v1/orders/(?P<order_id>[\d]+)/shipment-trackings/providers

is missing the required

permission_callback

argument. For REST API routes that are intended to be public, use

__return_true

as the permission callback. Please see <a href="https://wordpress.org/support/article/debugging-in-wordpress/">Debugging in WordPress</a> for more information. (This message was added in version 5.5.0.) in D:\Local Sites\owow\app\public\wp-includes\functions.php on line 5535
[27-Aug-2021 02:20:41 UTC] PHP Stack trace:
[27-Aug-2021 02:20:41 UTC] PHP 1. {main}() D:\Local Sites\owow\app\public\wp-admin\post.php:0
[27-Aug-2021 02:20:41 UTC] PHP 2. require_once() D:\Local Sites\owow\app\public\wp-admin\post.php:369
[27-Aug-2021 02:20:41 UTC] PHP 3. do_action() D:\Local Sites\owow\app\public\wp-admin\admin-footer.php:95
[27-Aug-2021 02:20:41 UTC] PHP 4. WP_Hook->do_action() D:\Local Sites\owow\app\public\wp-includes\plugin.php:470
[27-Aug-2021 02:20:41 UTC] PHP 5. WP_Hook->apply_filters() D:\Local Sites\owow\app\public\wp-includes\class-wp-hook.php:327
[27-Aug-2021 02:20:41 UTC] PHP 6. Automattic\WooCommerce\Blocks\Assets\AssetDataRegistry->enqueue_asset_data() D:\Local Sites\owow\app\public\wp-includes\class-wp-hook.php:303
[27-Aug-2021 02:20:41 UTC] PHP 7. Automattic\WooCommerce\Blocks\Assets\AssetDataRegistry->initialize_core_data() D:\Local Sites\owow\app\public\wp-content\plugins\woocommerce\packages\woocommerce-blocks\src\Assets\AssetDataRegistry.php:333
[27-Aug-2021 02:20:41 UTC] PHP 8. apply_filters() D:\Local Sites\owow\app\public\wp-content\plugins\woocommerce\packages\woocommerce-blocks\src\Assets\AssetDataRegistry.php:200
[27-Aug-2021 02:20:41 UTC] PHP 9. WP_Hook->apply_filters() D:\Local Sites\owow\app\public\wp-includes\plugin.php:189
[27-Aug-2021 02:20:41 UTC] PHP 10. Automattic\WooCommerce\Admin\Loader::add_component_settings() D:\Local Sites\owow\app\public\wp-includes\class-wp-hook.php:303
[27-Aug-2021 02:20:41 UTC] PHP 11. array_reduce() D:\Local Sites\owow\app\public\wp-content\plugins\woocommerce\packages\woocommerce-admin\src\Loader.php:1042
[27-Aug-2021 02:20:41 UTC] PHP 12. rest_preload_api_request() D:\Local Sites\owow\app\public\wp-content\plugins\woocommerce\packages\woocommerce-admin\src\Loader.php:1042
[27-Aug-2021 02:20:41 UTC] PHP 13. rest_do_request() D:\Local Sites\owow\app\public\wp-includes\rest-api.php:2832
[27-Aug-2021 02:20:41 UTC] PHP 14. rest_get_server() D:\Local Sites\owow\app\public\wp-includes\rest-api.php:495
[27-Aug-2021 02:20:41 UTC] PHP 15. do_action() D:\Local Sites\owow\app\public\wp-includes\rest-api.php:537
[27-Aug-2021 02:20:41 UTC] PHP 16. WP_Hook->do_action() D:\Local Sites\owow\app\public\wp-includes\plugin.php:470
[27-Aug-2021 02:20:41 UTC] PHP 17. WP_Hook->apply_filters() D:\Local Sites\owow\app\public\wp-includes\class-wp-hook.php:327
[27-Aug-2021 02:20:41 UTC] PHP 18. WC_Shipment_Tracking->rest_api_register_routes() D:\Local Sites\owow\app\public\wp-includes\class-wp-hook.php:303
[27-Aug-2021 02:20:41 UTC] PHP 19. WC_Shipment_Tracking_V1_REST_API_Controller->register_routes() D:\Local Sites\owow\app\public\wp-content\plugins\woocommerce-shipment-tracking\woocommerce-shipment-tracking.php:187
[27-Aug-2021 02:20:41 UTC] PHP 20. register_rest_route() D:\Local Sites\owow\app\public\wp-content\plugins\woocommerce-shipment-tracking\includes\api\v1\class-wc-shipment-tracking-rest-api-controller.php:64
[27-Aug-2021 02:20:41 UTC] PHP 21. _doing_it_wrong() D:\Local Sites\owow\app\public\wp-includes\rest-api.php:103
[27-Aug-2021 02:20:41 UTC] PHP 22. trigger_error() D:\Local Sites\owow\app\public\wp-includes\functions.php:5535
[27-Aug-2021 02:20:41 UTC] PHP Notice: register_rest_route was called incorrectly. The REST API route definition for

wc/v2/orders/(?P<order_id>[\d]+)/shipment-trackings/providers

is missing the required

permission_callback

argument. For REST API routes that are intended to be public, use

__return_true

as the permission callback. Please see <a href="https://wordpress.org/support/article/debugging-in-wordpress/">Debugging in WordPress</a> for more information. (This message was added in version 5.5.0.) in D:\Local Sites\owow\app\public\wp-includes\functions.php on line 5535
[27-Aug-2021 02:20:41 UTC] PHP Stack trace:
...
PHP 20. register_rest_route() D:\Local Sites\owow\app\public\wp-content\plugins\woocommerce-shipment-tracking\includes\api\v1\class-wc-shipment-tracking-rest-api-controller.php:64
[27-Aug-2021 02:20:41 UTC] PHP 21. _doing_it_wrong() D:\Local Sites\owow\app\public\wp-includes\rest-api.php:103
[27-Aug-2021 02:20:41 UTC] PHP 22. trigger_error() D:\Local Sites\owow\app\public\wp-includes\functions.php:5535
[27-Aug-2021 02:23:06 UTC] PHP Notice: Undefined variable: wholesale_type in D:\Local Sites\owow\app\public\wp-content\plugins\woocommerce-wholesale-pricing\inc\class-wwp-wholesale-metabox.php on line 339
[/php]

This error is pointing towards "WooCommerce Shipment Tracking" and was triggered inside "Woocommerce Wholesale Pricing" and says clearly:

"register_rest_route was called incorrectly"

Maybe this could be a source for the actual issue?

2) Purchase the original product and a translated version by purchasing variation ID #47161.

While going to the cart I receive two theme errors:

FATAL ERROR: UNCAUGHT ERROR: OBJECT OF CLASS WC_PRODUCT_ATTRIBUTE COULD NOT BE CONVERTED TO STRING IN D:\LOCAL SITES\OWOW\APP\PUBLIC\WP-CONTENT\THEMES\GOFLUO\WOOCOMMERCE\CART\CART.PHP ON LINE 133
( ! ) ERROR: OBJECT OF CLASS WC_PRODUCT_ATTRIBUTE COULD NOT BE CONVERTED TO STRING IN D:\LOCAL SITES\OWOW\APP\PUBLIC\WP-CONTENT\THEMES\GOFLUO\WOOCOMMERCE\CART\CART.PHP ON LINE 133

On the checkout, I am sadly also not able to complete the purchase. It is asking for:
"You must enter a valid EU VAT number to complete the purchase."

Even though this field is marked as optional when entering a valid VAT number the validation error keeps occurring.

I then had to create an admin order instead.

Now, when going to the "add admin order" screen I do see the next errors:

ShopWeDo Easy Shipper:

Notice: Undefined variable: shipping_id in D:\Local Sites\owow\app\public\wp-content\plugins\shopwedo-easyshipper\classes\shopwedo-pu.php on line 342

and

Notice: id was called <strong>incorrectly</strong>. Order properties should not be accessed directly. Backtrace: require('wp-admin/edit-form-advanced.php'), do_meta_boxes, WC_Meta_Box_Order_Actions::output, do_action('woocommerce_order_actions_end'), WP_Hook->do_action, WP_Hook->apply_filters, shopwedo_get_label_button_order_detail, WC_Abstract_Legacy_Order->__get, wc_doing_it_wrong Please see <a href="https://wordpress.org/support/article/debugging-in-wordpress/">Debugging in WordPress</a> for more information. (This message was added in version 3.0.) in D:\Local Sites\owow\app\public\wp-includes\functions.php on line 5535

These errors also show up once all WPML plugins are disabled and should be reported to the ShopWeDo Team.

I then created an admin order in English with Status Completed for:

Oneway - Anthracite, S
SKU: 5407008172343
Variation ID: 43467

To my surprise, the stock amount of this variation stayed unchanged.

I then tested again, now without any WPML plugins. After creating an admin order for the above-mentioned product the stock still remained unchanged.

This leads me to the conclusion, that in fact there is a stock issue on the site, but it is not triggered by WPML. I would suggest you take a local copy of the site to test it on a virtual server and enabled WP-Debug to revise the errors.

https://wpml.org/documentation/support/debugging-wpml/

Then also, before testing make sure that all plugins are updated, which is currently not the case. If still errors can be found after updating please inform the responsible support teams.

Apart from that you originally are reporting that product colors break sporadically.

This actually could be an issue regarding "Variation Swatches for WooCommerce - Pro" and WPML. What I can still offer for now is to create a test-site on which could test this plugin if you are able to provide us with the latest version?

Best regards
Andreas

August 27, 2021 at 7:59 am #9468795

pieter-janP

Hi Andreas,

Thank you for your very elaborated debug analyses! I do think most of these errors are not related, because I don't see a direct relation. Also, the site runs perfectly if we disconnect ShopWeDo.

However we are definitely going to check all these errors one by one in the upcoming days. In my experience having some errors is inevitable when a few plugins have to "work together" directly.

The thing we have to focus on more is why product color attributes change when the stock is updated via ShopWeDo. I might happen because of some errors in another plugin like Wholesale for WooCommerce, but this is a very far-fetched in my opinion.

I already re-tested some of the tests you ran and I think some of the observations are misplaced:

1. I also updated the stock for Oneway, it's working correctly. I saw that indeed one variation stock was 42 and another one was 85, so I assume you opened the incorrect variation after reload (actually did the same, that's why I found out). I, now edited the stock to 43, 42 and 41 successfully.
2. I ordered one product and the stock changed from 43 to 42 like expected.
3. The checkout flow is working, but if you checkout and fill in a company name, you have to fill in a valid VAT number for your country.

Ps: I want to share the Variation plugin, but there is no upload feature here. Let me know how I can proceed with this. Some months ago my first guess was also to look at this plugin, but the incorrect colors also occur on the overview page where the plugin is not active. Like I said, if we retrieve the product with a standard WP query the incorrect color is shown, so it's more logic that it's a bug in WPML I suppose.

August 27, 2021 at 8:01 am #9468799

pieter-janP

Concerning the ShopWeDo error, I think this is only happening when you do an order from the backend. ShopWeDo also has a pick up locations feature, that is only visible on the front-end.

August 28, 2021 at 1:36 am #9473417

Andreas W.
Supporter

Languages: German (Deutsch )

Timezone: America/Lima (GMT-05:00)

Hello,

Yes indeed, we should definitely do some testing. My apologies for the delay in answering, as I am sick off this week but decided to follow up on this open ticket myself.

I am not yet familiar with ShopWeDo, but maybe we could set up a dev account and do some testing.

I am providing a test site on which you please also install Variation Swatches for WooCommerce - Pro.

I would like to do some testing here, as this plugin is known and I already escalated threads internally regarding similar issues earlier, which were able to be solved by our team back then.

One-Click-Login:
hidden link

Please leave a short notification once the site is ready. In case you find the time to set up the plugins and try to recreate the issue, it would be highly appreciated.

Best regards
Andreas

The topic ‘[Closed] Product color relations sporadically break’ is closed to new replies.