This thread is resolved. Here is a description of the problem and solution.
Problem: You are developing a site with a custom post type set as not translatable and are using the
wpml_active_languages
filter to input a custom language switch. However, on the singular page of the custom post type, this filter returns an empty array, preventing the display of the language switch, although the page displays in the correct language when linked from a normal page. Solution: The issue arises because the custom post type is set as not translatable, meaning it does not have any language information. WPML cannot retrieve language info or use second-language URLs for such content. To resolve this, you have two options: 1. Use the "fallback" mode (display as translated). 2. Set the post type to translatable. It's important to note that the availability of second-language URLs when the content is marked as not translatable is a known limitation/bug, planned to be fixed in a future release. If you're looking to translate elements like the footer or header, that depends on how they're implemented (via templates, widgets, PHP, etc.).
If this solution does not apply to your case, or if it seems outdated, we highly recommend checking related known issues at https://wpml.org/known-issues/, verifying the version of the permanent fix, and confirming that you have installed the latest versions of themes and plugins. If issues persist, please open a new support ticket.
This is the technical support forum for WPML - the multilingual WordPress plugin.
Everyone can read, but only WPML clients can post here. WPML team is replying on the forum 6 days per week, 22 hours per day.
Background of the issue:
I am developing a site that uses a custom post type which I do not want to mark as translatable due to performance reasons and other effects. I use the filter hook wpml_active_languages on every page to input a custom language switch.
Symptoms:
On the singular page of the custom post type, the wpml_active_languages filter returns an empty array, preventing the display of the language switch. However, the singular page displays in the correct language when linked from a normal page.
Questions:
Why does the wpml_active_languages filter return an empty array on the singular page of the custom post type?
Is there a workaround to get the same data for display of the language switch on the singular page of the custom post type?
While you wait for my colleague to take over the ticket, let me try to help you with the issue quickly.
I am not sure if I understood it correctly, but if you are using it on post type that you have set as Not Translatable, then that is expected, as those posts do not have any language information. Only when set as translatable you would have language information for that post type, default language or translation.
The answer given does not explain to me why wpml_get_active_languages is empty at this singular post page although wpml knows the permalinks to this singular post page for the active languages. I also asked for a work-around which was not answered either.
From the previous answer I conclude that you will pass this ticket to a colleague of yours, so I hope he or she can provide these answers I am looking for.
thanks for getting back, I will be taking the ticket and helping further.
I checked the hook and it seems to work fine for me. I am sharing the test code I am using:
<?php
echo 'Test WPML hook ';
function my_flag_only_language_switcher() {
// Make sure WPML is loaded and working
if ( function_exists( 'icl_get_languages' ) ) {
// Get the active languages
$languages = apply_filters( 'wpml_active_languages', NULL, array(
'orderby' => 'id',
'order' => 'desc'
) );
// Display flags
if ( ! empty( $languages ) ) {
echo '<div class="language-switcher">';
foreach ( $languages as $l ) {
if ( ! $l['active'] ) {
echo '<a href="' . esc_url( $l['url'] ) . '">';
}
echo '<img src="' . esc_url( $l['country_flag_url'] ) . '" width="18" height="12" alt="' . esc_attr( $l['language_code'] ) . '" style="margin-right:6px;" />';
if ( ! $l['active'] ) {
echo '</a>';
}
}
echo '</div>';
}
}
} ?>
<?php my_flag_only_language_switcher(); ?>
Please try above code if it works for you, if not it could be related to your other custom code or similar.
If you still have issue let me know and I can provide a test site, and you can then show us an simple example there and we will check further and help out.
It is not that the hook doesn't work at all, it is that the hook's result if used at a single custom post page is empty if the custom post object type displayed at that single page is declared as not translatable in wpml settings. That page still can have a header and footer section, can have navigation menu's etcetera so the page needs to be translated. And if I navigate to that page by using get_permalink( $post_id ) while at a translated page, it provides me a link to the single custom post page in the form of mysite.com/m-custom-posts/fr/my-custom-post-slug for a French version which is correct. That page exists! But if I use apply_filters( 'wpml_active_languages', NULL), [ 'skip_missing' => 0 ] ) while at that single page, the result is an empty array as if there are no translated versions of that single page. Maybe you don't understand what I mean with a single page, so please check https://developer.wordpress.org/themes/template-files-section/custom-post-type-template-files/
Thanks for getting back to me. I understand what you mean, but that’s not how WPML works.
When a post type is set as not translatable, it doesn’t contain any language information in WPML, and there’s no data related to the second language. You can’t retrieve language info or use second-language URLs for such content.
If you need to display the content in another language / langauge switcher / 2nd language URL etc, you have two options:
Use the “fallback” mode (display as translated), or
Set the post type to translatable.
In your case, what might be confusing you, the availability of second-language URLs even when the content is marked as not translatable—this is actually a known limitation / bug, and it’s planned to be fixed in a future.
If you’re looking to translate elements like the footer or header, that’s a different matter. Whether those are translatable depends on how they’re implemented—via templates, widgets, PHP, etc.
In short: if a post type is set to not translatable, there is no language metadata available nor you should use different language URLs, and the behavior you're describing is not expected or recommended by WPML.
So if I understand correctly, in a future release when you solve 'the bug', it might even be that the header and footer of that single page is no longer available in translated form. That will be a serious problem. The reason I don't want to make the custom post translatable is that we also have a custom table which records have a one-on-one relationship (using post id) with the custom post records. I need that table instead of a post meta because I need to store coordinates in a point field type and have a spatial index with it. If multiple versions of the same custom post exist (for each language), the connection between custom table entries and the custom posts is lost. But if WPML does not support non-translatable custom posts, I have to find another solution.
I am afraid as I have explained the page / post type can not exist in 2nd language if set as not translatable. I am afraid as I have said above, you will need to use suggested approach or find another way that might work for your case.
Feel free to contact us again if any other doubts.
