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.
No supporters are available to work today on this forum. Feel free to create tickets and we will handle it as soon as we are online. Thank you for your understanding.
Thank you for the updates. As said, we really need to test this issue in a clean test sandbox as my suspicious point it to your server environment or even your theme code, in order to confirm and isolate it, please, proceed this way:
Install the theme/plugin in a clean installation and reproduce the problem in this new installation. So we can isolate it and do some testing without the interference of server settings or other plugins
After this, I will check the problem in this new installation and look for a possible solution.
I created a test website with a clean WordPress install. You can access it through this link: hidden link - Through this link you will be automatically logged in.
Please upload the (theme/plugin) to this test install, setup it the same way as in your website (using the same options) and create some dummy content to reproduce the issue.
Please note that we only need the (theme/plugin) and the related functionality, you don't need to setup a entire website or clone your existing site. The fewer plugins the better.
After that, please send us clear steps on how to see/reproduce the issue on this test install. We will run some tests.
Please, let me know when you are ready, thank you for your collaboration, have a nice day.
thanks for your reply. I've installed our custom theme and the needed plugins.
I've added: Advanced Custom Fields Pro, Beaver Builder Pro, Wp Rocket and YITH WooCommerce Wishlist. This is the minimal setup to show the behavior to you.
Aditionally I set up WooCommerce and added a demo product and a demo event (CPT)
I have seen the following behavior: As I created the demo event and displayed it on the "veranstaltungen" page with Beaver Builder, everything worked fine. The post-type slug in the url was translated from "event" to "veranstaltung" by the theme language file (maybe this is even a problem). Then I realized that wpml was not configured. I then defined german as default language in wpml and added english and dutch as additional languages as at the original website. After this the slug wasn't translated anymore and the 404 error occurs. I then realized that you have to edit the post module in beaverbuilder (switch displayed post type from and back to event)and re-save the page to get the links working again.
But this is not the only way we could display the list of custom post types. We got a special template for this were you can choose the displayed post type archive in the backend via ACF. If I display the custom post types with this method the behavior is similar: Without wpml the cpt-slug in the permalink is translated from "event" to "veranstaltung" and everythin works. If I now activate wpml the links are not translated anymore and broken. If I then resave the permalink settings, the links are working again but without the translation.
I added both methods of displaying the events to the page "veranstaltungen", so you can see it. Same fix as mentioned earlier.
Thank you for the provided details and clarifications, sorry for the bit of waiting here. I took a detailed look at this issue from the provided sandbox environment, in my tests everything works as expected when a translation is added for your events custom post type. Here are the steps I tried:
1 - In your WordPress Dashboard > WPML > Settings > Post Types Translation I set the 'Events (events)' post type as 'Translatable - only show translated items'
2 - Then I changed the default language of the post type slug to english and added translations for the other languages from your WordPress Dashboard > WPML > Settings > Post Types Translation > Set different slugs in different languages for Events. See attached screenshot.
Note: It is important to set the default language of your post type slug as english, since in most cases you enter the default values in theme code as english, changing it to a different laguage may cause problems, also when you have a post type and page with the same name you can also have 404 not found errors due WordPress internal conflicts.
Please, let me know if you still see any issue from the sandbox test installation, it will confirm if the issue happens only for your website which could be a settings specific or host environment specific issue. Thank you for your collaboration and continued patience, have a nice day.
thanks a lot. Seems that the post type translation settings were a bit messed up.
I noticed that the setting depends on what language is active in the admin panel.
When I used german in admin interface, which is my default language, wpml said that "veranstaltung" is the original slug and won't let me change it. even if I set english as default it remains at "veranstaltungen". I had to change the admin language first to english via the wpml dropdown in the admin bar. Then I was able to set the original slug to english which then was "event" and add "veranstaltungen" as german translation again.
After this steps everything seems to work properly. But I don't think that this is an expected behavior for the slug settings, or is it?
Best regards,
Bernhard
This ticket is now closed. If you're a WPML client and need related help, please open a new support ticket.
