Filtering acf_get_posts args

• enshrined

• July 4, 2017 at 5:41 am

It’d be amazing if we could filter the post status’ in the acf_get_posts() function in the future.

In my case, I’ve manually edited the plugin (embedded within a personal plugin) but this stems from having control over the post_object field arguments through the acf/fields/post_object/query but not the acf_get_posts() function.

E.G. I have a post status (archived) that’s not searchable on the front end on WP but should be able to be used within the backend in the post_object fields.

When registering the post status I set exclude_from_search to true, I can then use the acf/fields/post_object/query filter to add archived to the $args array before returning. This allows me to search for a choose the archived posts within the post_object fields, but it won’t display them afterwards because the acf_get_posts() function fails to return a post.

This is because acf_get_posts has it’s default post_status for the query set to any but any, as per the docs retrieves any status except those from post statuses with 'exclude_from_search' set to true. Hence in my case failing.

if we could filter the act_get_posts args on a field type basis, this would allow us to pass through the updated status’ and fix this issue. I’d imagine something like the below would work:

function get_posts( $value, $field ) {
	
	// numeric
	$value = acf_get_numeric($value);
	
	
	// bail early if no value
	if( empty($value) ) return false;

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

	$args = apply_filters('acf/fields/post_object/get_posts_args', $args, $field );
	$args = apply_filters('acf/fields/post_object/get_posts_args/name=' . $field['_name'], $args, $field );
	$args = apply_filters('acf/fields/post_object/get_posts_args/key=' . $field['key'], $args, $field );

	// get posts
	$posts = acf_get_posts( $args );
	
	
	// return
	return $posts;
	
}

Either way, love the plugin, keep up the good work 🙂

Cheers,
Daryll

• John Huebner

• July 4, 2017 at 6:36 am

I’m a little confused at why setting the post status using acf/fields/post_object/query. The first think ACF does in this function is call wp_parse_args($args, $defaults). Since post_status of any is a default value, is should not override the status that you set in your filter. If this is causing the post object field to get no results it seems like there should be something else causing it.

• enshrined

• July 4, 2017 at 6:45 am

Hi John,

The issue is because there’s no way to pass a custom array of $args into the acf_get_posts() function from the acf_field_post_object::get_posts() method as there are no filters in this method and it’s being called by acf_field_post_object::render_field().

That’s why the snippet in my original post suggests adding the three filters so this can be adjusted if we need to do so.

The post status adjustment in acf/fields/post_object/query is to allow the AJAX search to search for that specific post status, otherwise again it uses any which will miss out my custom archived status. This section works perfectly, the issue comes when the field is then rendered on page load using acf_field_post_object::render_field() which comes back as blank.

• John Huebner

• July 4, 2017 at 7:29 am

k, I think I see.

You should submit a support ticket here https://support.advancedcustomfields.com/new-ticket/.

• enshrined

• July 4, 2017 at 7:43 am

Cool, I’ve opened a ticket. Although it’s not an issue for me for now if others run into it at least they will know the problem!

• Nikole

• March 27, 2023 at 4:35 pm

I’m wondering if there has been any movement or fixes in this in later versions of ACF or since this post was made. I think we run into a problem because the acf/get_posts_args isn’t passing a lang argument which is causing issues with relational posts. We can’t choose the posts we want to see in the post picker (like just that language or all languages) so we had to do some weird things with this (like overwriting the basic acf_get_posts function).

If we could send it a basic lang=” (for all) or lang=whatever, we wouldn’t have to be forking ACF and could make it work better.

I think I read somewhere that this is somewhat by design, to lock in the language, so you can only see related posts in the same language when you are using polylang. But we end up with CPTs for things like associated resources that might be used for posts in other languages.