Issue with WPML and Pods Templates since 2.8

@keraweb This will be a good one for you to look at since you worked on this area of the WPML integration recently.

Hi @berniemann (and @sc0ttkclark)

I don’t even need to test to confirm this issue.
We load auto-templates by their name and not their ID, for this reason this will never work with WPML since it only convert’s translation ID’s.
Good find! I’ll create an issue for this on GitHub.

Cheers, Jory

• This reply was modified 3 years, 4 months ago by Jory Hogeveen.

I don’t know if this will help, but with pods 2.7, when I was translating a template I could name it with the same name as the template in the default language. Now, with pods 2.8, I must leave the template name blank in the translations, otherwise, if I name the translations with the same name as the original, then the template does not work in the front with the default language. As if it were unable to find it for the default language. I assumed this was due to duplicate names, and that’s why I ended up leaving the template translations with the name blank, but it seems like there is some kind of conflict there too.

Another solution for the issue of the template names is to name every template translation with a different name. This also works -I’ve just checked it. But does not resolve the problem with the relationship fields.

Thks

Created a PR to test with:
https://github.com/pods-framework/pods/pull/6219

The change you’ve mentioned is actually because in 2.7 the compatibility with WPML was incomplete.

Cheers, Jory

• This reply was modified 3 years, 4 months ago by Jory Hogeveen.

Another solution for the issue of the template names is to name every template translation with a different name. This also works -I’ve just checked it. But does not resolve the problem with the relationship fields.

Hold on, so if you name all translations different than the original language the issue is fixed?

Hi, sorry for the delay. The reason why I originally opened this topic wasn’t the names of the templates. Later I’ll do extensive testing experimenting with the translated templates names and I’ll tell you how it goes.

My problem was with the relationship fields. Although the templates in every language are working and showing the html code, only the default language template is showing the related items (neither calling the related items by PHP nor by [each…].

Only when I set the pod of the related items as ‘Not translateble’, the items are shown in the other languages templates. But this is not a solution, because then if the pod is set to ‘Not translatable’, the page of these posts only exist in one language.

That’s the thing. With pods 2.7 and with the pods set as ‘Translatable – use translation if available or fallback to default language’, these were showing in the templates and also as a single post in every language.

I think the issue with relationship items not showing on translated templates is not related to the template itself. It’s related to the behavior of a pod when set as translatable or not with the WPML plugin.

WPML has three different statuses for posts/pages. Not translatable, Translatable, and ‘Use translation if available or fallback to default language’. I think since pods 2.8, the status ‘Use translation if available…’ acts the same as ‘Translatable’ on a template with relationship items. This means that if a pod is set as ‘Use translation if available…’, a template calling these pods as relationship items will show them only in the language these items were created. The same as if they were set just as ‘Translatable’.

I’ve found a situation that maybe reveals how the pods behavior has changed since 2.8. While with Pods 2.7 a pod set as ‘Use translation if available…’ was showing in all languages on the edit pods page, since Pods 2.8, if you change the language in the admin page, the edit pods page will only show the pods created in that language, and not the pods created in other languages.

Update: to confirm what I was pointing in my last message, I have done a test setting Pod Templates as not translatable. The result is the same. The related items in the relationship field are only shown in the default language. The only way to make the related items appear on the other languages pages is to set the pod of the related items as ‘Not translatable’, but then the pages of these items will be shown only in one language.

Thanks.

Update 2: I’ve been able to resolve the issue of the relationship items not showing in other languages templates by patching the pods code in the original 2.8.1 WPML.php file (pods/src/Integrations/WPML.php). On line 179, I have disabled the filtering settings for ‘media’ (removing the code) and now the relationship items are shown in all languages. I think the way I’m using pods, removing this code will not break anything on my project, so looks like a good (temporal) solution for me. Anyway, I suspect that maybe the issue is inherited from elsewhere, but I’m not a PHP expert, so I have no idea.

As for the subject of the template names and translations, I think the update discussed on https://github.com/pods-framework/pods/pull/6219 causes a conflict when trying to select the templates on the pod settings page. In some cases, the recently created templates weren’t showing in the drop-down menu. It looks like the previous version (2.8.1) works well if you leave the translated templates with a blank title or with a different title (avoiding repeating the title of the original language template in each template translation).

Hi @berniemann

I cannot reproduce your issue locally, I even found out that the code I’ve added in #6219 doesn’t help since that is already done later on.

The way I tested your issue:

– Added a Pod (translatable)
– Added a relationship field to itself (so relationships are translatable)
– Added templates in all languages (templates also are translatable)
– Linked the templates using auto-templates (engelish version).

Relationships are displayed correctly and the template is also selected in the correct language.

Just thought of one situation it would return nothing;

If you only add a template for a translation and don’t add a template for the main language then it won’t work. It will only show on the translation and not the default (or other) language.
This is because it cannot fallback to default if the default language has no template.

• This reply was modified 3 years, 4 months ago by Jory Hogeveen.
• This reply was modified 3 years, 4 months ago by Jory Hogeveen.

Hi Jory,
I’ve done some more tests following the same steps as you on several wordpress installations, but at the moment I have not reached any final conclusion. What I can say is that I was hasty in attributing to the pods update the issue of the relationships not showing correctly in other languages. So sorry and excuses for going around and pointing the wrong way.

What I have found:
On a fresh wordpress 5.8.1 installation (theme twenty twenty), with WPML, Loco Translate and pods 2.7, relationships aren’t displayed correctly.
The same with pods 2.8. So looks like the problem does not come from the pods update.

But…
On another installation, with wordpress 5.8.1 and the same plugins, relationships are displayed correctly in all languages. The difference between this installation and the previous ones is that the installation where everything works fine isn’t a fresh installation. I tested (and deleted) other plugins before. But now both sites have the same plugins and the same theme. So it’s a bit strange. At the moment I can’t think of anything that may be causing the issue. I’ll keep thinking about it.

If no one else runs into the same problem, and you have verified that everything is correct, I will think that either I’m missing something or I am doing something wrong… Thank you very much for your interest in resolving the issue and excuses for your time wasted on this. I’ll let you know if I find something else.

• This reply was modified 3 years, 4 months ago by berniemann.

I think I have found a way to reproduce the issue with two wordpress fresh installations obtaining different results depending on the order I install WPML and Pods.

Case A:
-A newly installed wordpress site
-First: WPML install and setup
-Second: Pods install, create a pod with a relationship field, template, etc. (the way you did it, Jory)
-Result: the relationship items are only shown on the default language page

Case B:
-A newly installed wordpress site (same version, same theme, etc)
-First: Pods install
-Second: WPML install and setup
-Third: create a pod with a relationship field, etc.
-Result: relationships are displayed correctly

I don’t know if this has any sense, but I’ve done the tests twice with the same results in every case, confirming that if I first install and setup WPML and then Pods, the relationships aren’t displayed correctly on secondary languages. So it looks like Pods must be already installed before WPML install and setup.

• This reply was modified 3 years, 4 months ago by berniemann.

Hi @berniemann

The order of installation isn’t related to this issue I’m sure.

Can you check your settings of WPML regarding Pod Templates translations?
Also, make sure the translations for your templates exist if you set Pod Templates to be translatable.

If you’d like to share more cases/tests, please check the following info:

– List all templates you’ve made and their languages/translations.
– Let me know what template you’ve selected in the Pod Auto-templates option.
– List whether Pod Templates are translatable or not.
– Let me know if “Adjust IDs for multilingual functionality” is enabled in “Languages” (this option should be unrelated but I’m being careful with this one..)

Thanks!

• This reply was modified 3 years, 4 months ago by Jory Hogeveen.

Oh Man! I have tried this quickly… On a wordpress installation having the issue, unchecking “Adjust IDs for multilingual functionality” resolves the problem! Wow! I thought I already tried this before, but I must be wrong. So maybe the order in which you install WPML and Pods makes this option to be checked/unchecked by default? I’ll check this later, just to see why the tests I did were giving me different results. Anyway, certainly, it looks like the issue was caused by having this option checked. Oh, it was so simple…

Great, Jory. Thank you very much. Problem solved!

• This reply was modified 3 years, 4 months ago by berniemann.