Relationship Field post_type query in format_value()

• rainstorminc

• August 1, 2013 at 4:42 am

Hi everyone,

I’m fairly new to WordPress, but am an experienced PHP programmer.

I found myself debugging an issue on a site we just built that involves ACF. Specifically, we have a custom post type called “Product” and a relationship ACF called “Related Products” where the user can select other products to list on a given product’s page.

Unfortunately, due to a conflict with another plugin on the site, whenever we go to edit a Product in our catalog, the related products aren’t showing up in the admin area as selected.

I’ve figured out where the conflict occurs and think it could be resolved with a minor tweak to ACF.

Specifically, on lines 694-699 in plugins/advanced-custom-fields/core/fields/relationship.php, the following code exists:

		// find posts (DISTINCT POSTS)
		$posts = get_posts(array(
			'numberposts' => -1,
			'post__in' => $value,
 			'post_type'	=>	apply_filters('acf/get_post_types', array()),
			'post_status' => array('publish', 'private', 'draft', 'inherit', 'future'),
		));

This is found within the format_value method of the relationship class. The goal here is to find the posts represented by the value stored in the DB. So, if a given product is related to other products, the ids of those products are in an array in $value and we’re looking to find the posts for those ids.

What I noticed is that this query retrieves posts of all post_types, not just the ones selected for the field. Ie, if my relationship field says that these IDs represent just products, that isn’t taken into account when the query is run — instead, almost all post_types are included in the list. Unfortunately, due to some weird code in another plug-in this can cause an issue because they add new filters to queries that include their own post type which, because ACF isn’t being more precise, is getting included in the filter.

While I completely understand that it’s an edge case, I thought it would be more appropriate to change the code to this so that the query is filtering only on those post_types associated with the relationship.

		// find posts (DISTINCT POSTS)
		$posts = get_posts(array(
			'numberposts' => -1,
			'post__in' => $value,
 			'post_type'	=> $field['post_type'],
			'post_status' => array('publish', 'private', 'draft', 'inherit', 'future'),
		));

Is there any reason why this change couldn’t/shouldn’t be made in ACF?

• Elliot

• August 1, 2013 at 12:55 pm

Hi @rainstorminc

Thanks for the detailed description.

I would have through that the post_type param would not be needed due to the post__in param being so precise.

Can you explain the issue with more detail on why the current query doesn’t work, even through the ID’s are explicitly set?

Thanks
E

• rainstorminc

• August 2, 2013 at 11:27 pm

Hi Elliot,

Thanks for the response!

Yes, I agree — it’s perfectly reasonable to suspect that post__in would be enough. The conflict occurs with another plugin that handles Event custom post types.

This events plugin uses the “pre_get_posts” method. During the process of using this method, the plugin will end up adding a tiny piece to the query if it has to do with a post_type that the plugin is responsible for. Ie, your query says “Give me all post types” and then the event plugin says “hey, that query has to do with events — so add on this event-related piece”. The end result is that the query doesn’t return anything because the event piece isn’t appropriate to be added in this case since it’s not really about events.

I’ll be the first to admit that there’s probably something that could change in the event plugin to avoid this issue. Having said that, my guess is that ACF is more widely supported than the other and therefore, more likely to be updated. Plus, I figured the update actually made sense anyway to restrict the results to certain post_types. Especially, since it was already filtering to certain post_types anyway, it just wasn’t being that specific.

What do you think?

• Elliot

• August 4, 2013 at 11:22 am

Hi @rainstorminc

Because your case is quite specific, I would encourage you to add a filter to the pre_get_posts and edit the ‘wrong’ settings that the events post type plugin is adding.

I would rather not bloat the core and add potential issues for other users if possible.

Thanks for understanding and thanks for the bug report.

Cheers
E

• rainstorminc

• August 6, 2013 at 6:02 am

Hi Elliot,

Thanks for your reply.

While I understand your position, it seems as though the specific request is actually a tighter implementation of the search and shouldn’t negatively effect anyone since, as you said, it’s locked in with the IDs and is just returning posts that are within the user-specified settings.

Do you foresee a problem that someone might encounter with this update that I might be missing?

Thanks!

-Matt

• Elliot

• August 6, 2013 at 2:33 pm

Hi @rainstorminc

The problem with managing a plugin with over 1,000,000 downloads is there is always an issue with any code change! 🙂

Sorry mate, but I would really like to leave the code as is and ask you to hook in and modify the 3rd party conflict yourself.

Thanks for understanding
E