[Assigned] I need helo with Elementor Search Form - I cant see the translated Property Features ( taxonomies)

Hello,

Could you please check if you have the following option activated:

WPML → Languages → Language filtering for AJAX operations

If this does not solve the issue, please let me know, as this might be a compatilbity problem between "RealHomes Elementor Addon" and the WPML Translation Editor, which we will need to investigate further.

Best regards
Andreas

Hello,

I would like to offer to take a closer look and request temporary access (wp-admin and FTP) to the website to investigate the issue further.

The required fields are located below the comments section when you log in to leave the next reply. The information you provide is private, meaning only you and I can see and access it.

IMPORTANT
Please be sure to back up your website and database before granting us access.
If you can't see the "wp-admin / FTP" fields, your post and website credentials will be set to "PUBLIC." DO NOT publish the data unless you see the required wp-admin / FTP fields.

The private reply form looks like this:
hidden link

Click "I still need assistance" the next time you reply.

Video:
hidden link

Please note that we are required to request this information individually on each ticket. We are not permitted to access any credentials that were not specifically submitted on this ticket using the private response form.

Best regards,
Andreas

You could try to set the taxonomies (terms) to "Fallback" at WPML > Settings, but I doubt that this would solve the issue.

Fallback doesn’t mean “merge content across languages”—it means “show default-language content if no translation exists.” This includes that there does not exist any post or term in a second language, and so taxonomy-based filters may still fail unless terms are explicitly translated and assigned.

Further, Elementor or RealHomes widgets may hardcode that empty terms are hidden from the form, which blocks fallback visibility unless overridden.

- Post listings (e.g., archives, loops): WPML can show default-language posts if no translation exists, depending on settings like “Translatable – use translation if available or fallback to default language.”

- Search forms (especially custom ones): These typically rely on taxonomy queries (WP_Query or get_terms()), which by default only return terms assigned to posts in the current language.

---

Maybe duplicating the properties would be an option?
https://wpml.org/documentation/translating-your-contents/displaying-untranslated-content-on-pages-in-secondary-languages/#duplicating-content

Or you could make use of WPML Hooks and automatically create duplicates when a property is published:

For Frontend:
https://wpml.org/wpml-hook/wpml_make_post_duplicates/

For Backend:
https://wpml.org/wpml-hook/wpml_admin_make_post_duplicates/

The problem is that each post and taxonomy has a unique ID inside the database, and the search query will not find anything, as WP_Query will check if an ID exists in each language.

This would only be solvable by using a custom code solution inside a Child Theme.

Now, this is a fairly complicated approach, as get_posts() or WP_Query do not include any language argument yet.

https://developer.wordpress.org/reference/classes/wp_query/

The only way to alter such a query would be to set the argument 'suppress_filters' to true, which will bypass WPML's language filtering.

Example:
get_posts( array(
'post_type' => 'property',
'suppress_filters' => true
) );

You could try using this snippet in a Code Snippet plugin:

add_action( 'pre_get_posts', 'wpml_fallback_search_query' );

function wpml_fallback_search_query( $query ) {
    if ( is_admin() || ! $query->is_main_query() || ! $query->is_search() ) {
        return;
    }

    // Get WPML language context
    $current_lang = apply_filters( 'wpml_current_language', null );
    $default_lang = apply_filters( 'wpml_default_language', null );

    // Only apply fallback logic in secondary languages
    if ( $current_lang !== $default_lang ) {
        // Fetch default-language post IDs for the target post type
        $fallback_posts = get_posts( array(
            'post_type'        => 'property', // Adjust to your CPT
            'posts_per_page'   => -1,
            'suppress_filters' => true,
            'fields'           => 'ids',
        ) );

        // Inject fallback posts into the current query
        $query->set( 'post_type', 'property' );
        $query->set( 'post__in', $fallback_posts );
        $query->set( 'suppress_filters', true ); // Bypass WPML filtering
    }
}

Note that I did not test this snippet yet. If you could set up a staging site, I can offer to test this approach for you.

What does it?

- It intercepts the search query before execution.

- It bypasses WPML’s strict language filtering using suppress_filters => true.

- It injects default-language post IDs into the secondary-language search results pages.

Hi Kostas,

Thanks for the update and clarification.

If the translated terms (e.g. “Additional Features” like Seafront) do not exist or are not assigned to any translated properties, then by default, WordPress and WPML will not return them in taxonomy queries — especially in secondary languages. This is expected behavior, as get_terms() and similar functions only return terms that are assigned to posts in the current language.

The only way to override this behavior is to bypass WPML’s language filtering by setting the 'suppress_filters' => true argument in your query. This tells WordPress to ignore WPML’s language constraints and return terms from the default language as well — even if they’re not assigned to translated posts.

This approach can be useful for fallback visibility, but it requires custom code and may not be compatible with all themes or widgets (especially if they hardcode their queries).

Let me know if you need further assistance. It would be very helpful if you could set up a staging site for testing.

Best regards,
Andreas

This appears ot be related to the fact that the properties are not translated.

The only workaround I can suggest for this is creating duplicates for each property using our recommended hooks.

For Frontend:
https://wpml.org/wpml-hook/wpml_make_post_duplicates/

For Backend:
https://wpml.org/wpml-hook/wpml_admin_make_post_duplicates/

My apologies for the delay, but I do work from Tuesdays to Saturdays.

The reported issues are a known limitation when using listing themes. This is why we provided two hooks that allow us to duplicate posts on the admin and on the frontend for user submissions.

What I can offer:

1) I can provide a WPML test site on which you can install the theme for testing
2) I can assist you with implementing the suggested hooks on your site (even though this is usually not covered by our support policy)