[Resolved] Intermittent product URLs using default language category slug causing redirect loops when using %pr...

We’ve identified the potential issue with term translation.

In our case, the get_the_terms filter consistently retrieves the WP_Term object in Italian (main language) from cache, but in some scenarios the term is not properly translated.

This behavior seems to be related with the get_term filter, specifically the get_term_adjust_id callback. Digging deeper, it points to WPML_Term_Adjust_Id::filter() and, more precisely, to the internal check are_functions_in_call_stack() when get_permalink() is present in the stack.

This made us wonder if the behavior is related with the known patch described here:

https://wpml.org/errata/woocommerce-multilingual-too-many-redirects-error-when-using-shop-base-with-category-permalinks/

However, in our setup products are translatable with fallback to the original language disabled when a translation is missing, so the patch would not be effective.

As a side note, if we temporarily comment out 'get_permalink' from the checked functions, everything works as expected and the correct translated term is returned.

Could you confirm whether this is expected behavior or a side effect of the mentioned fix?

At the moment we are trying a fix filtering "wc_product_post_type_link_product_cat" and translating the slug term when necessary.

Thanks in advance.

Hello,

we accessed the staging environment, but we realized that the test performed is not representative of the actual issue. The problem does not concern different categories, but rather different products belonging to the same category.

To better clarify the issue, let’s take a “shoes” category as an example. We are currently encountering mixed URLs such as:

/en/shop/shoes-english/nike-english/ - In this case, both the category taxonomy and the product slug are correctly displayed in English.

/en/shop/scarpe/adidas-english/ - Here, instead, the category taxonomy remains in Italian, while the product slug is in English.

Furthermore, while continuing the custom debugging process we are developing internally, we also identified even more anomalous cases — although extremely rare — where URLs from the main language contain elements translated into a secondary language.

For example:

/negozio/shoes-english/nike-italiano/ - In this case, the category taxonomy is in English, while the product slug is in Italian.

Or:

/negozio/shoes-spanish/nike-italiano/

Please note that we are referring to a multilingual installation configured with:

/en

/fr

/de

while the main language is published directly on the root /

In light of all this, our developer also pointed out that the approach used in the staging environment risks compromising the analysis itself, since a new — evidently very recent — version of WPML has been installed there, whereas our live website has been running WPML for more than 5 years.

This is precisely why we expected a more in-depth and professional approach to investigating the issue, potentially including direct database checks in order to identify inconsistencies that may have accumulated over time.

At the moment, instead, we find ourselves attempting to replicate an issue that is extremely difficult to reproduce within an environment that does not accurately reflect the actual state of the original website, inevitably leading to incomplete conclusions.

For this reason, we are once again requesting that the issue be escalated, so that it can be analyzed more thoroughly and with an approach that is more aligned with the real condition of the installation.

Thank you.