polylang for custom post types stops working in 1.4dev17

I don’t have this issue. However I changed some things around this. The filter is called now only one time quite soon in the process. Maybe before you create it.

How do you use the ‘pll_get_post_types’ ?

I used it as described in the link above, in functions.php

add_filter('pll_get_post_types', 'my_pll_get_post_types');
function my_pll_get_post_types($types) {
	return array_merge($types, array('my-cpt' => 'my-cpt'));
}

Where my-cpt is my custom post type.

I see. This change was not a good idea if the filter is not reachable from functions.php. The new development version 1.4dev19 should solve the issue. Thanks for your tests!

It would be better if custom post types are detected by default, so you don’t have to go through this step ??

They are! You just have to check the relevant option in Polylang settings to decide if you want to enable language and translations management or not.

Ahh I see! That really helps a lot. However the first thing I get from google search is the approach above. And why not have custom post types activated by default?

However the first thing I get from google search is the approach above.

Perhaps because it’s the oldest way. The checkbox is available since 1.0 (about one year ago), whereas the filter is available since 0.8 (about one year before).

And why not have custom post types activated by default?

To avoid conflicts with some plugins / themes

OK, I hope people will get this point. Thanks a lot!

I changed again the code around the ‘pll_get_post_types’ filter, trying to avoid calling it too much time and keep it compatible with themes.

It must now be added before the action ‘after_setup_theme’ is fired. For a theme it means that it must be added directly in functions.php as you do.

The modification is done in current development version (1.4dev20).