Reply To: Post object option ignores a custom post type

• Chauncey McAskill

• May 22, 2015 at 3:47 am

Hi,

I don’t know if we are sharing the same issue (and for me, the issue stretches further back than 5.2.5) but I’ve figured out mine.

The Context:

The project I’m currently working on uses Polylang for translations. Custom fields aren’t set to be translated, their data is synced manually.

I have a post object setup to retrieve posts from two custom post types: partner and sponsor. These post types aren’t configured to be multilingual.

The Issue:

In acf_field_post_object::render_field(), if there’s a saved value, ACF will retrieve all posts matching the saved value (in order to pre-populate the rendered field).

$posts = acf_get_posts(array(
	'post__in' => $field['value']
));

Unfortunately, this returns an empty array because acf_get_posts() will default to loading from all available post types. In my case, acf_get_post_types() returns: post, page, attachment, partner, and sponsor.

And this is the key problem: post and page are configured to be multilingual. This triggers Polylang to add a condition to fetch posts in the current language which the non-multilingual post types can’t fulfill.

First Solution:

Require ACF to pass along the filtered list of post types:

$posts = acf_get_posts(array(
	'post__in' => $field['value'],
	'post_type' => $field['post_type']
));

The one downside of this is if the list of filtered post types changes (e.g., a post type is removed), it will affect any currently saved value assigned to that now-removed post type.

Second Solution:

Intercept Polylang before it adds that language condition to the WP_query. I accomplish this using a backtrace to figure out if the WP_query was called by acf_get_posts() by way of acf_field->render_field().

**Updated 2015-05-21T17:22-05:00**

add_action( 'pre_get_posts', function ( &$wp_query ) {
	$is_acf_get_posts = (
		   ( $e = new Exception )
		&& ( $trace = $e->getTraceAsString() )
		&& false !== strpos( $trace, 'acf_get_posts(Array)' )
		&& (
			   (   is_admin() && false !== strpos( $trace, '->render_field(Array)' ) )
			|| ( ! is_admin() && false !== strpos( $trace, '->format_value(' ) )
		)
	);

	if ( $is_acf_get_posts && pll_is_not_translated_post_type( $wp_query->get('post_type') ) ) {
		pll_remove_language_query_var( $wp_query );
	}
}, 9 );

function pll_is_not_translated_post_type( $post_type ) {
	global $polylang;

	if ( isset( $polylang ) ) {
		$pll_post_types = $polylang->model->get_translated_post_types( false );

		return ( is_array( $post_type ) && array_diff( $post_type, $pll_post_types ) || in_array( $post_type, $pll_post_types ) );
	}

	return false;
}

function pll_remove_language_query_var( &$query ) {
	$qv = &$query->query_vars;

	unset( $qv['lang'] );

	if ( ! empty( $qv['tax_query'] ) ) {
		foreach ( $qv['tax_query'] as $i => $tax_query ) {
			if ( isset( $tax_query['taxonomy'] ) && 'language' === $tax_query['taxonomy'] ) {
				unset( $qv['tax_query'][ $i ] );
			}
		}
	}
}

I made this filter very verbose just to make sure the idea is understand. I’m using a much more compact version in my project. This function can also be easily translated to your multilingual-plugin flavour (e.g., WPML).

Cheers,