Skip Navigation

[Resolved] Relationships between posts of different languages

This support ticket is created 3 years, 1 month ago. There's a good chance that you are reading advice that it now obsolete.

This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.

Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.

Sun Mon Tue Wed Thu Fri Sat
- 9:00 – 13:00 9:00 – 13:00 9:00 – 13:00 9:00 – 13:00 9:00 – 13:00 -
- 14:00 – 18:00 14:00 – 18:00 14:00 – 18:00 14:00 – 18:00 14:00 – 18:00 -

Supporter timezone: Asia/Hong_Kong (GMT+08:00)

This topic contains 19 replies, has 2 voices.

Last updated by caroleM-4 3 years ago.

Assisted by: Luo Yang.

Author
Posts
#2198447

Hello,

The website I am actually working on uses two languages in which user may publish posts of several custom types that will not be translated.

I am actually testing relationships between two of those custom post types in order to see if I may use it in this context and I noticed that the behavior was different depending on WPML settings :

- If I set both custom post types in WPML as "Not translatable" I can register any relationships between any posts regardless of their languages which means that secondary language posts of both types will show up in the selection list when editing a default language post of the other type. I will then be able to save the relationship and the related posts will appear correctly on both sides.

- If I set one of the custom post types in WPML as "Translatable - only show translated items" or "Translatable - use translation if available or fallback to default language", secondary language posts of this type will not show up in the selection list when editing a default language post of the second type. I will still be able to set the relationship if I edit the secondary language post of the second type but then the related posts of the secondary language won't appear when editing the default language post of the first type.

Unfortunately I need to keep at least one of the custom post type as "Translatable - only show translated items" in order to have views of this type showing only posts in the page language which I cannot do if using "Not translated".

So my questions are :
- Is relationship behavior I encounter when WPML set to "Translatable" (both ways) normal or is it a bug that could be fixed ?
- If normal, is there a way to change that, for example by disabling WPML filtering in a specific hook ?
- If not, is there a way to get a view to show posts of a custom post type in one language only when that post type is set in WPML to "Not translatable" ?

Thanks in advance for your help and have a nice day.

#2198743

Hello,

You can setup both post types as "Translatable - only show translated items", I suggest you follow our document to translated related posts:
https://toolset.com/course-lesson/translating-related-content/
When translating, you need to translate the content, but you don’t have to do anything about the related posts. All the post connections come from the ones you already made in the other language

#2199193

Thanks for the feedback Luo but that will not fit my customer's needs.

Let me explain more precisely with the example of the two custom post types I am actually working on which are sort of user profiles and user ads.

In both post types I have posts in German (default language) that will never be translated in French as well as post in French (secondary language) that will never be translated in German and I need to use relationships between these posts regardless of languages which means being able to link together posts of the same language as well as posts of different languages (both languages are spoken widely in Switzerland so French users may be interested in German ads as well as the opposite).

At the moment I did not test with a frontend form but, when using backend edition, it seems I can do that only if both post types are set to "Not translatable" which is not suitable for me as I also need to list posts of the second type (user ads) separately (German posts only on German pages and French posts only on French pages) in a few frontend views.

Probably you are going to tell me that relationships are not meant to work this way with WPML but I ran some test with both post types set to "Translatable - only show translated items" and noticed that in this case I could select a German post as relationship when editing a French post, but not the opposite, and that the French post will then not appear at all in the relationships of the German post even if the relationship is correctly saved and appears normally in the French post.

Honestly, in my opinion, that's a buggy behavior as a relationship is typically meant to link things together which means we should either be able to set it from both posts or from none of them and once it's set it should obviously appear on both posts no matter which one was used to set it.

As most of the complications I had to deal with since the beginning of this project, that's probably due to WPML filtering as it's working perfectly when both post types are set to "Not translatable" which means technically the relationship can perfectly exist between the two posts. I guess that this "Not Translatable" setting, I never used before, makes all post appear as default language ones even if registered initially in the secondary language and that's why the problem does not occur when using it.

Well anyway, whatever the problem is exactly, in the end the real question for me will be : is there a chance to be able to register a secondary language post as relationship of a default language post when both post types are set to "Translatable - only show translated items" or the only way to get it working the way I need is to leave WPML outside of this by setting both post types as "Not translatable" and manage their language via a custom field in order to be able to filter them by language in frontend views ?

#2199389

For the questions:

is there a chance to be able to register a secondary language post as relationship of a default language post when both post types are set to "Translatable - only show translated items" ...

By default, you can connect posts in same language, for example: connect German "user profile" post with German "user ads" post, you can not connect posts in different languages, that will conduct unexpected result.

In your case, you might consider these:
1) duplicate those posts into other languages:
https://wpml.org/documentation/translating-your-contents/displaying-untranslated-content-on-pages-in-secondary-languages/#duplicating-content
2) then follow the document I mentioned above to connect the posts in same language:
https://toolset.com/course-lesson/translating-related-content/

#2200767
toolset1.jpg

Well, if connecting a French post (secondary language) to a German post (default language) may lead to unexpected results then why are German posts appearing in the selection list when editing a French post ?

Because they really are as you may see in the attached screenshot and it's possible to set the connection without encountering any error or warning of any kind.

I really don't understand why it's so problematic to set relationships across several languages as they are apparently based on post ids. If it's a question of syncing those relationships between original posts and translations you could eventually add a parameter to enable / disable this syncing and allow free connections if disabled. That would be very helpful in the context of websites / countries in which several languages are spoken meaning the original language of content may not always be the default language and linking posts from different languages makes sense.

Well anyway, I really would like to use relationships because they would be ideal for our customer to visualize relations from the backend but duplicating content cannot be the solution in my case so what about setting both post types to "Not translatable" in WPML, is it safe then to connect any posts together even those that were saved as secondary language posts before the setting change ?

None of the concerned post has translation but taxonomies are translated so I would have to see what are the impact at this level for existing posts as well as for newly submitted post and also to base the language filtering in frontend views on a custom field instead of WPML but that could be ok if it allow me to use relationships the way I need.

#2202285

You can try these:
1) Setup both post types "user profile" and "user ads" as: Translatable - use translation if available or fallback to default language
2) Then connect posts in different languages

In each single post, you can follow our document to display other related posts:
https://toolset.com/course-lesson/displaying-related-posts/

#2202711
toolset20211022-1.jpg

Well, it could be ok for me to work with both post types set to "Translatable - use translation if available or fallback to default language" but unfortunately it does not solve the relationships problem. In fact it's exactly the same as when they are set to "Translatable - only show translated items" : when editing in backend I can't select a French post (secondary language) as relation of a German post (default language) and I can select a German post as relation of a French post but the French post won't show up in the relations of the German one even though it's probably detected as I noticed that, in the context of a one to many relationship, the buttons appear disabled (attached screenshot) once the relation is set.

While running a few more test with the two post types set to "Translatable ..." (both modes) I also discovered an interesting thing that shows the problem is essentially related to WPML filtering : if I switch to "All languages" while editing a default language post, the secondary languages posts show up in the relationship selection list and I can select them but then an error occurs (Es ist ein Fehler aufgetreten, bitte versuchen Sie es später erneut. In English : An error occurred, please try again later.) and the relationship is not saved.

So I thought that the problem may be solved by disabling WPML filtering which I tried to do with :

function disable_wpml_filtering( $query ) {
$query->query_vars['suppress_filters'] = true;
}
add_action( 'pre_get_posts', 'disable_wpml_filtering' );

This solves part of the problem if I set the snippet to run in AJAX calls as I can then select a secondary language post as relationship of a default language post and save without getting an error.

Unfortunately the secondary language post still does not show up in the default language post relations (backend edition at least) but the default language post shows up in the relations of the secondary language post which means the relation has been saved correctly even if set from the default language post.

This partial success confirm that disabling WPML filtering could probably allow me to use relationship the way I need in this project. Such a solution would be ok for me, even if it may still cause unexpected results at other levels or in other places that I will then have to fix using similar tricks, as I already have to do so for frontend post display and filtering as well as for some background tasks I have to run on all posts.

So could you please help me find the correct way to disable WPML filtering on hooks that would be efficient for both relationship selection and relations display, in backend as well as in frontend, but if possible without affecting other queries ?

#2204659
WPML1.jpg

I have tired it in my localhost again:
1) setup both post types as: Translatable - use translation if available or fallback to default language
2) Edit one main language post, and connect it with anther secondary post, save, it works fine, there isn't any errors.

See my screenshot WPML1.jpg

So the problem you mentioned above is abnormal, please check these normal debug steps:
1) Make sure you are using the latest version of Toolset plugins, you can download them here:
https://toolset.com/account/downloads/

2) In case it is a compatibility problem, please deactivate all other plugins, and switch to WordPress default theme 2021, deactivate all custom PHP/JS code snippets, and test again

3) Also check if there is any PHP/JS error in your website:
https://toolset.com/documentation/programmer-reference/debugging-sites-built-with-toolset/

#2204825
toolset-20211025-6.jpg
toolset-20211025-5.jpg
toolset-20211025-4.jpg
toolset-20211025-3.jpg
toolset-20211025-2.jpg
toolset-20211025-1.jpg

Thanks for the feedback Luo, sounds like a good news to my ears as it could be fixed if considered abnormal.

To be in the best possible conditions, I tested on a sandbox on which only Toolset and WPML are installed (of course in their latest version) but the result is the same as you will be able to see in screenshots 1 to 4 that show the selection list when editing French only posts Test 2 FR / Example 2 FR from which the connection is possible and then when editing the English only posts Test1 EN / Example 1 EN from which it's not.

Then I did set Example 1 EN as related post of Test 2 FR (screenshot 5) but it does not appear on Example 1 EN (screenshot 6) exactly like I did encounter it on the project's website.

No PHP errors were logged during these tests and you may see in the screenshots that I have only irrelevant warnings in the console.

If it may help spot what's going wrong, I can give you access to this testing version.

#2205527

Please provide your test site credentials + FTP access in below private message box, also point out the problem post URL, I need to test and debug it in a live website, thanks

#2205725
connect-wpml.jpg

Thanks for the details, I can see the problem in your website.

I assume we are talking about these:
1) One-to-many relationship between post types "Examples" and "Tests"
2) The problem occurs when:
Edith the child "Tests" post in main language "English", you can not connect it with parent "Examples" post in secondary language "French"

This is a limitation of WPML option "Using the default language as a fallback for untranslated content", see WPML document:
https://wpml.org/documentation/translating-your-contents/displaying-untranslated-content-on-pages-in-secondary-languages/

This option is for:
Displays default language content when there is no translation

In your case the default language(Main language) is English, since "Example 2 FR" post does not have a English translation, so you won't be able to see it in the option of "Connect existing Test".

As a workaround, you can connect setup the connection in "Example 2 FR" post(in secondary language), for example:
hidden link
connect button "Connect existing Test", you should be able to see the option in English language, see my screenshot connect-wpml.jpg

since the related post is in default language, so it can display as option of Connect existing Test" select dropdown menu.

And according to our document:
https://toolset.com/course-lesson/translating-related-content/

We recommend to setup both post types as "Translatable only show translated items", there isn't such kind of built-in feature for exactly what you want, you can add a feature request for it, our developers will evaluate it:
https://toolset.com/home/contact-us/suggest-a-new-feature-for-toolset/

#2206145

Thanks for this long explanation Luo but I have already heard all that and we are going back to the start this way so I guess it's time for me to bring back the context :

1. The problem occurs with any type of relationship no matter if concerned post types are set as "Translatable - only show translated items" or "Translatable - use translation if available or fallback to default language" in WPML. The only way to get over that with no custom code is to set both types as "Not translatable" which is not possible in my case as I need to have localized contents for the concerned post types even if not translated.

2. I perfectly know this behavior is due to the way WPML filters localized contents, which is not really compatible with our country context where none of the four spoken languages may be considered default, but I also know it's possible to disable this filtering in most cases, as I often need to, and I have to find a way to apply this to that part of Toolset / WPML combination as I really need relationships to work correctly and can't change the country context.

3. The test I mention in my answer #2202711 (https://toolset.com/forums/topic/relationships-between-posts-of-different-languages/#post-2202711) confirms that relationships can be set correctly from both sides if this filtering is disabled for Ajax calls using pre_get_posts filter. I added the snippet on the testing website and deleted existing relationship between Example 1 EN and Test 2 FR so that you can try it yourself. As you will see you are now able so select Test 2 FR as relation of Example 1 EN and save. It will then appear on Test 2 FR, as in your example, even if it still does not show up in Example 1 EN.

4. The fact that switching the post types to "Not translatable" gets the related posts to show up correctly in both languages (you can also test that on the example website if you want) even though they are all localized sounds for me like a confirmation that it's also possible to disable this filtering for the relationships list of the edit view as it seems to be what WPML itself does in that case for all lists.

5. Unfortunately disabling the filtering using pre_get_posts hook does not affect the relationships list even if the snippet is set to run everywhere which probably means I should target another hook or maybe disable it another way in order to reach my goal.

So the question for me actually is more something like : which hook, or condition, or priority should I use in order to be able to disable WPML filtering for the relationships list of admin edit view ?

If I find the correct answer to this question, my relationship problem is solved, and I am sure you can help me find it as you are on the Toolset side and thus have the full picture of how these lists work under the hood.

I perfectly understand it's not the normal way of using WPML but I have no other choice in the context of the project except replacing WPML completely which I do not want as it's still the best solution in this case whatever limitations I have to deal with.

#2206699

Unfortunately, see our document:
https://toolset.com/documentation/programmer-reference/types-api-filters/
There isn't such kind of built-in feature within Toolset Types plugin as your request:

to be able to disable WPML filtering for the relationships list of admin edit view

And if you are using custom codes to change the relationships list results in admin side, it might conduct other unexpected results, as I suggest above, please submit a feature request for it:
https://toolset.com/home/contact-us/suggest-a-new-feature-for-toolset/

#2207635

Well, I was not asking for a built-in functionality but more for a workaround to get over the problem as the time I have left for this project is way too short to go through a feature request and hope for an addition which may never come.

I have to admit your answer is a little bit disappointing because what you present as an expected behavior still looks like a bug for me. Honestly, as long as it's natively possible to set a relationship between two posts, the expected behavior should be that both posts appear on the related content list of the other post involved in the relationship, this whatever the context, as the opposite makes the whole relationship useless.

Anyway, it seems that I'll have to find a solution on my own or stop using Toolset relationships completely but it's frustrating as the fact that "Add new ..." and "Connect existing ..." buttons are disabled on the parent post in a one to many relationship proves that the existing relation is correctly detected at some level which means it's just the query used to populate the meta box list that is preventing the related secondary language post to be listed and that could probably easily be fixed on your side which is not really the case on mine.

#2208605

As I mentioned above there isn't such kind of built-in feature, I need to check it with our developers, check if there is any other workaround for your case, will update here if there is anything news.