- English as the default language
- Arabic as the secondary language
I am using the category carousel widget from the XStore theme.
The issue is:
- On the English version, the category carousel works perfectly and links are correct (e.g. "/product-category/...")
- When I switch the site to Arabic, the category names are translated correctly, but the links become incorrect and appear like:
"/?product_cat=..."
When clicking any category from the carousel in Arabic:
- It redirects to the English version instead of staying in Arabic
Inside Elementor, the category links appear correct with "/ar/...", but on the frontend they change to the incorrect query format.
Could you please check if the XStore category carousel widget is overriding WPML permalink rules or not fully compatible with WPML for taxonomy links?
Thank you for contacting WPML support. I'd be happy to assist you on this issue.
To debug this issue further, I would need to check your site settings once, for this I would need temporary access (wp-admin and ftp) to your site.
So could you please provide me with those details, you will find the needed fields for this below the comment area when you log in to leave your next reply. hidden link
This looks like a compatibility issue with the theme.
I have created a public test site here, can you please install the xstore theme and it's core plugin here and see if you can reproduce the issue here? hidden link
I tested the issue on the sandbox site you provided using the XStore theme and its core plugin, but the problem did not appear there.
I believe this might be because the sandbox is a fresh/duplicated setup, where the categories were newly created or duplicated, and I did not manually translate the category taxonomy the same way it is configured on my live site.
On my main site, the categories (taxonomy) were translated manually using WPML, and the issue appears there.
So I’m wondering:
Could the problem be related to how the category taxonomy translations are handled (manually vs duplicated)?
I would really appreciate it if you could help identify the exact cause or guide me on what might be different between both environments.
As I’m planning to launch the site very soon, your support would be greatly appreciated.
Thank you for your feedback. I’ll need to investigate this more thoroughly to understand why it’s happening, as it doesn’t appear to be related to manual handling of taxonomies.
To help with this, could you please share a backup of your wp-content folder along with your database? You can compress them into a ZIP file and upload them via Google Drive. This will allow me to set up a local copy of your site and examine the issue in more detail.
I created a test product and assigned it to a test category. Then I duplicated the product using WPML, which also duplicated the category automatically.
After that, I noticed that the duplicated category works perfectly, and the URL is correct.
However, the issue still exists with my original categories, which were translated manually (not duplicated).
So it seems that:
- Duplicated categories work correctly
- Manually translated categories have broken URLs
Now I have around 3000 products and about 129 categories (including parent and subcategories), all already translated manually.
My questions are:
1. What is the correct way to fix the existing categories?
2. Should I delete the current translated categories and recreate them using duplication instead?
3. Is there a way to bulk convert or sync existing manual translations to behave like duplicated ones without rebuilding everything?
Since the site is close to launch, I need the safest and fastest solution without breaking existing products or URLs.
Looking forward to your guidance.
Thanks in advance.
And you can test any thing in my live site after you finish i will restore old backup
I have identified and resolved the issue on my side.
The problem was related to the category slugs in Arabic. After changing the category slugs to English, everything started working correctly, including the widgets and category links.
So it seems the issue was not related to the theme or plugin compatibility.
