Strange reproduceable 404 on translated venues/organizers but not on events

[Stefan Krueger]

Hi,

we have purchased your amazing plugin for our website http://www.berlinbeerweek.com and are currently trying to set up venues, organizers and eventually the events.
We are encountering a strange problem with especially setting up the venues and organizers bilingual.
So, what happens is that if the WPML language settings are set to German I can create an organizer and/or venue with the language of German and it shows up on the site. If I then translate the newly created organizer or venue into English (and it doesn’t matter if I copy or overwrite with the original content) the venue/organizer shows up in the backend but the actual link to it returns a 404 error.
Flushing doesn’t help if the WPML language is still set to German. If I then switch the WMPL language to English and flush the permalinks then the venue/organizer which got me a 404 will work but it will then get me a 404 on the German translation.
If I then change the WPML language back to German and flush the permalinks then the German translation will work again, but the English will bring up a 404 again.
This for some reason only applies to organizers and venues. Event properly show up in both languages, but in either one of them with a venue & organizer leading to a 404.
You can check this here:
http://www.berlinbeerweek.com/en/event/super-veranstaltung/
The language was last set to German, thus on the english translation you will get the 404 however if you click on the German flag then on the German you won’t get the error.
Any idea what this could be and sorry if that is a simple setting issue that needs to be done, I am pretty new with wordpress and we do have a webdesign company, but stuff like that isn’t included in our payment plan so I got to figure this out by myself.

Thanks a lot and let me know if you need more info.

[Geoff B.]

Good evening Stefan and welcome to the Events Calendar Support forum!

Thank you for reaching out to us and for providing your system information.

We are sorry to hear about the issues you are facing with WPML and 404 errors.
I would love to help you with this topic.

The good news is that it turns out that I am part of the WPML compatibility team.
So, as you can imagine, I am very interested in finding out the cause of your issues.

As a disclaimer, before we begin, we are currently working at making WPML integration even better.
Unfortunately, I cannot commit to a release date at this point. But stay tuned!

That being said, provided a few limitations, we should be able to get you up and running.

As a first troubleshooting step, can you confirm that:

1. You have read the following post and configured things accordingly: https://theeventscalendar.com/knowledgebase/setting-up-the-events-calendar-with-wpml/ ?
2. If the issues persists when you switch to the ?lang= method instead of the directory based one in WPML ?

Best regards,

Geoff B.

[Stefan Krueger]

Hi Geoff,

thanks for the quick response.
I did follow both steps in the first troubleshooting and unfortunately the problem persists.

Any further suggestions ?

Thanks

Stefan

[Geoff B.]

Good evening Stefan,

I am sorry to hear that this did not fix the issue for you.

I ran some additional tests and here’s what I found:

What is happening is that the organizer doesn’t seem to be assigned a language upon creating the event.
This is has been reproduced on my own site with twenty-fifteen and WPML 3.3.8

In the meantime, I have found a work around.
Here’s the breakdown:

1. Create your event exactly how you are doing right now
2. Once published, while you are still in the Edit Event screen, right-click on the Edit Organizer link and open the link in a new tab
3. Once in that new tab, just save the organizer (which will assign a language to it) and everything should work smoothly

This is now logged as a bug. Unfortunately, I cannot commit to a release date at this point. But stay tuned we will let you know as soon as it’s fixed!

Thank you for your understanding,

Geoff B.

[Stefan Krueger]

This reply is private.

[Geoff B.]

Good evening Stefan,

Thank you for your answer and for providing a thorough description of your experience.
You are absolutely right, there is a ton of room for improvement on how well WPML is handled.

Thank you also for your invitation to log in. Unfortunately, our policy does not allow us to log in to clients websites for several reasons, including liability.

The good news is that we are making some serious progress on this and hopefully, if all goes according to plan, we should be ready to release some substantial updates on the WPML compatibility before the fall begins.

Your specific issue led me to do some thorough tests on the current compatibility with 3.3.8 (which introduced a few glitches that are also there in the new version).

This led me to discover a new bug with the venue URL. So thank you for that.
The good news is that I have a workaround for it.

Temporarily, until we come up with a permanent fix, it looks like “venue” does not like to get translated in the URL.
This leaves you with a couple of options:

1. Both in string translation AND in your second language po/mo file, you need to remove the translation to venue. Not ideal, but it will work.
2. Add a redirect rule (via a redirect plugin), where every time a URL in your secondary language has the translated version of “venue” in it you redirect it to a url with the untranslated “venue” string instead.

Just to clarify things, currently, officially, the only WPML method supported is language as a parameter (?lang=). The directory based method (as in http://www.berlinbeerweek.com/en/veranstaltungsort/testvenue1/) will simply work for several specific scenarios, but there will be the odd time where there is a random hardcoded ?lang= that will show up at the end of your URL.

We apologize for the inconvenience and we are working at changing that.

Have a good week-end,

Geoff B.

 

[Stefan Krueger]

Hi Geoff,

thank you for your help and the suggested workarounds.
I assume this also applies for organizers as there are the same issues with them?!

Best regards

Stefan

[Stefan Krueger]

I don’t know if it matters but I have just found out something else.
If I newly create a venue in German and the permalinks are flushed in German then the venue shows up after publishing. If I then got to the translation into english, copy the content from the german version and then just hit preview the english translation is shown in that preview perfectl. If I then publish the translation clicking on the link returns a 404.

[Stefan Krueger]

I am sorry to post so many updates. But I was looking through these instructions here:

WPML Configuration

And it was required to download/install WPML String Translation, which I did.
When I check String Translation though, none of what is showing up is translated into German. Is this a problem ?
Also under my settings “Theme and plugins localization” I have ticked “Don’t use WPML’s String Translation” at the moment, but also nothing changes if I tick “Translate the theme and plugins using WPML’s String Translation”.
So, what is the plugin useful for and why did I have to download it?

[Stefan Krueger]

Hi Geoff,

it’s me again. I have been trying several different things the past two days and one last attempt to “fix” this resulted in actually somewhat of a temporary solution.
I am not a programmer, but during my trial and error sessions in the past few days it looked like that somehow the “right” path to the content isn’t stored properly for each language and only when I flush the permalinks they get corrected but then only for WP’s default language. So, I thought this may have something to do with the custom URL structure for permalinks and archives. So, then I set the permalink settings to Plain, saved the changes and voila now both languages worked for venues and organizers, except that for some odd reason both language flags on the site had &lang=en added, the German and the English one, resulting in only seeing the English version after clicking on the flag. So now, I have our .com and .de domain set up in WPML, one is for English the other one is for German and at least I can set up venues, organizers and events in both languages without 404s. I am now left with “ugly” plain links on the site though, any idea why this is happening the way it is and how to circumvent this ? Is this a bug in WPML, the rewrite mod (should I try a different one maybe), event calendar pro or WP itself ?

Thanks for your help and sorry for the spamming :/

Stefan

[Stefan Krueger]

One more thing to add. It seems other people have similar issues with links getting translated and not properly forwarding to the actual content.

Polylang + Events Calendar

Is this a bug related to the rewrite mod ? And why does that only apply to venues and organizers, but event links are properly rewritten.?

[Geoff B.]

Good evening Stefan,

Thank you for your answers and for your understanding.
We really appreciate your input on this.

I assume this also applies for organizers as there are the same issues with them?

Yes, absolutely, these 2 separate workarounds will also work for the organizer issue.

If I newly create a venue in German and the permalinks are flushed in German then the venue shows up after publishing. If I then got to the translation into english, copy the content from the german version and then just hit preview the english translation is shown in that preview perfectl. If I then publish the translation clicking on the link returns a 404.

This is a very good point. I was able to replicate that exact scenario in my tests.
It is another facet of the issue: the fact that the venue and organizer strings are not being assigned languages in the WPML tables properly.

When I check String Translation though, none of what is showing up is translated into German. Is this a problem ? Also under my settings “Theme and plugins localization” I have ticked “Don’t use WPML’s String Translation” at the moment, but also nothing changes if I tick “Translate the theme and plugins using WPML’s String Translation”. So, what is the plugin useful for and why did I have to download it?

I would recommend the following 2 steps:

1. Go to WPML > Themes and Plugins Localization
2. Using the checkboxes, re-scan our plugins for strings

This should give you complete control over the strings.

Let me know how that goes.

I am not a programmer, but during my trial and error sessions in the past few days it looked like that somehow the “right” path to the content isn’t stored properly for each language and only when I flush the permalinks they get corrected but then only for WP’s default language.

This is exactly what the issue is. Kudos!

Thank you for bringing this to our attention. The good news is that we have already identified this as being the cause of the issue.
We are working on fixing that.

So, then I set the permalink settings to Plain, saved the changes and voila now both languages worked for venues and organizers, except that for some odd reason both language flags on the site had &lang=en added

The extra ?lang=en results from the initial flushing unfortunately.
The only known cure would be to manually edit the permalinks (after a backup) directly in phpMyAdmin

I am now left with “ugly” plain links on the site though, any idea why this is happening the way it is and how to circumvent this ? Is this a bug in WPML, the rewrite mod (should I try a different one maybe), event calendar pro or WP itself ?

The only way to truly circumvent this is through a maintenance release.

In the meantime, it appears that the only 3 options are the 2 workarounds I suggested or yours.
I wish I had a better answer for you, but for now it’s the best one I have.

One more thing to add. It seems other people have similar issues with links getting translated and not properly forwarding to the actual content.
https://theeventscalendar.com/support/forums/topic/polylang-events-calendar/
Is this a bug related to the rewrite mod ? And why does that only apply to venues and organizers, but event links are properly rewritten.?

To make a long story short, multilanguage plugins are not always automatically compatible with customs post types out of the box.
As a side note, we actually do not officially support Polylang. At least not for now.

Rest assured we are working hard at this and thank you for your patience.

Best regards,

Geoff B.

[Stefan Krueger]

Thanks Geoff!
I appreciate all your efforts until this is resolved and in the meantime we’ll just live with the plain links.

[Geoff B.]

Good evening Stefan,

Thank you for your understanding as we fix this.
It’s really appreciated.

You will be contacted when the fix is available.

Best regards,

Geoff B.

[Stefan Krueger]

Hi Geoff,

I assume this wasn’t fixed with the latest update ?

Best regards

Stefan

[Author]

Posts