1. I do not need translation for these fields, so wpml has nothing to do.
Well, but we are analyzing a Problem where a view returns wrong results of a wrong language, apart of the problem that the URL parameter gets lost.
That code, both snippets, work on the Current post that you edit or create.
So, if that post later gets translated and should or should not display on the relative View results in each language, then the data which the Custom Code adds, is not added to your translated posts and searching by the same data, will result in wrong posts shown.
You mentioned removing that code resolves the issue.
That code applies only to the currently edited post and hence does not sync the translations - the data added, the actions it does, are not applied to your translations and hence that same View will not work the same in a translated results list.
2. Is it having to disable snippets? Even when I encode a new date it does not work anymore, yet it is displayed correctly for one of the dates (see capture) why ?
You already confirmed the issue is solved if that code is removed.
But we deviate, I read now that the code is not working anymore even in the current post/language?
This is a totally new issue.
Does removing that code snippet solve the issue?
It would confirm why when I try to replicate this problem on your copy of the site, I cannot see the issue:
https://toolset.com/forums/topic/translation-problem-when-sorting-by-category/#post-907758
3. The update including that feature has no ETA yet.
Now, let's move on.
I want to solve this problem for you and re-downloaded the package and deployed it again to find out, if that code has an influence over the issue and if I can spot the source (any that is not yet known) of the issues.
I replaced all Toolset and WPML plugins with the current ones and checked if the JauneOrange Theme you use still had the Code active which needs to run just once (and hence, should NOT be present in the theme anymore):
function tssupp_duplicate_parent_fields_once (){
$child_slug = 'participant';
$parent_slug = 'concert';
$parent_field_slug = 'concert-date';
// Get all of the child posts
$args = array(
'post_type' => $child_slug,
'numberposts' => -1,
'post_status' => 'publish'
);
$child_posts = get_posts( $args );
if ( !empty( $child_posts ) ) {
foreach ($child_posts as $child_post) {
// get the ID of the parent post
$parent_id = get_post_meta( $post_id, '_wpcf_belongs_' . $parent_slug . '_id', true );
if ( !empty( $parent_id ) ) {
// get the parent field
$parent_field_value = get_post_meta( $parent_id, 'wpcf-' . $parent_field_slug, true );
// duplicate the parent field on the child post
update_post_meta( $post_id, 'wpcf-' . $parent_field_slug, $parent_field_value );
}
}
}
}
But, the theme (correctly 🙂 ) does NOT feature that code, hence, that code cannot be the cause of this issue in the sense of "If disable it, the issue is resolved".
I see that the other Snippet Nigel provided is still in the Theme, and according Nigels Instructions this is required.
That is OK.
I commented the code snippet below, so it's clear what it does:
function tssupp_duplicate_parent_field( $post_id, $post, $update ){ //$post_id is the current edited/created post ID, $post the current post object. NOT it's translation. ONLY the current edited or created post no matter in what language.
$child_slug = 'participant'; //We determine the slug of a post type, child role
$parent_slug = 'concert'; //We determine the slug of a post type, parent role
$parent_field_slug = 'concert-date'; //The slug of the field that is stored on a parent post
// is it a child post being updated?
if ( $child_slug == $post->post_type ) {//Check if the current post saved/edited is of type "participant"
// If yes, get the ID of the parent post
$parent_id = get_post_meta( $post_id, '_wpcf_belongs_' . $parent_slug . '_id', true );
if ( !empty( $parent_id ) ) { //If a parent exists
// get the parent field
$parent_field_value = get_post_meta( $parent_id, 'wpcf-' . $parent_field_slug, true );//get the field 'concert-date';
// duplicate the parent field on the child post
update_post_meta( $post_id, 'wpcf-' . $parent_field_slug, $parent_field_value );
}
}
}
Now, as we see, that code does NOT touch the post types involved in the View which you reported as broken in your initial post, which is Label_artists_vue, and queries "Artistes" post type.
Artistes post types are not involved in that code at all, so I do not think this has an influence over the behavior, and is not related to this ticket if it (that custom code) does not work anymore, as the issue would be another.
This new problem is not the issue reported here, and not related.
Now, Artistes Post Type, which is the post type queried by that problematic view, is translated and exists in the secondary (English) language of your site with few posts (4) and several more in the default language (french).
This is what I see on the duplicate I have.
The View is inserted as well in a page, which is translated to both languages.
So we would expect this View to return only English Results in the English page, and only French in the French page, and no mixup when you submit a search.
Since however the View looses the URL param with this specific constellation, the results are wrong.
What are the possible solutions until we fix the problem with the URL attribute?
1. Use a Submit button (not an AJAX updated View). That works fine
2. Or, in WPML Settings, change from ?lang parameter to "language in directories" URL settings, so the languages are shown as directories.
This works just fine.
Once the issue with the missing URL parameter is solved you can then turn back to ?lang parameter for example.
