If the attribute type is Select and it doesnāt allow multiple selection, you can try this first:
$query->filter([
'xcustom' => 123,
]);
Replace 123 with the ID of an existing option of this Select attribute (you can check these via the Edit Options button, option ID is in the URL when you edit it, something like āā¦tag_ID=123ā¦ā). This way you can check if the query works at all, and if so you can try to provide a variable value $listing->get_xcustom__id() or debug this further.
2. You can try this filter:
Its still doesnt work. Should I put it in bug section? Iām very sure its a bug, as the other user from the thread i sent above also failed using the same technique.
I want to show related listing from the same current listingās owner. your code works. but im curious what is the difference between this 2 code, as using either of those work. which one is more preferable:
$query->filter(['user' => $listing->get_user__id()]);
OR
$query->filter(['vendor' => $listing->get_vendor__id()]);
when using set_args, why we need to add categories rule again? without that it will show all listing from all categories. that rule already added in ā/includes/blocks/class-related-listings.phpā line 76
$query->set_args(
[
'tax_query' => [
'relation' => 'AND',
// Set xcustom.
[
'taxonomy' => 'hp_listing_xcustom',
'field' => 'term_id',
'terms' => $listing->get_xcustom__id(),
'operator' => 'IN',
],
// Set categories. we need this eventhough its already in 'hivepress/v1/models/listing/relate'. maybe its hivepress bug
[
'taxonomy' => 'hp_listing_category',
'field' => 'term_id',
'terms' => $listing->get_categories__id(),
'operator' => 'IN',
],
],
]
);
Please try to debug this via var_dump($query->get_args()); This way you can check how the WP query changes after you add the custom attribute filter, and if it changes at all.
Either is ok, but user can have multiple vendor profiles in future updates, so filtering by user ID may be more safe.
Yes, this issue occurs because set_args overrides the query arguments tax_query and meta_query instead of merging them. You can merge them using $query->get_args()['tax_query'] to prevent duplicating arguments manually.
I have another weird thing, hereās the code I use.
add_action( 'hivepress/v1/models/listing/relate', function( $query, $listing ) {
var_dump( $query->get_args() );
var_dump( $listing->get_xcustom__id() );
var_dump( $listing->get_categories__id() );
$query->set_args(
[
'tax_query' => [
'relation' => 'AND',
// Set xcustom.
[
'taxonomy' => 'hp_listing_xcustom',
'field' => 'term_id',
'terms' => $listing->get_xcustom__id(),
'operator' => 'IN',
],
// Set categories. we need this eventhough its already in 'hivepress/v1/models/listing/relate'. maybe its hivepress bug
[
'taxonomy' => 'hp_listing_category',
'field' => 'term_id',
'terms' => $listing->get_categories__id(),
'operator' => 'IN',
],
],
]
);
var_dump( $query->get_args() );
}, 10, 2 );
but the terms for āhp_listing_xcustomā misteriously change from array(6) to array(6,4), see the raw dumps below. From where that ā4ā comes from??
Please try to hard-code the ID without ā__inā as suggested above and try to output the args:
$query->filter([
'xcustom' => 123,
]);
Regarding the second issue, please var_dump$listing->get_xcustom__id(). If 4 is the category ID and itās added automatically, please make sure that your function callback runs after all the other callbacks (change 10 priority to 1000), this may resolve the issue.
I added this to the bug tracker, please try to set a high priority (1000) for the function callback and use $query->set_args() to fully override the tax_query as a temporary fix.
Thereās a bug related to selectable attribute fields not being available at the time this hook fires, but thereās a solution for the second issue - arrays are merged so adding a custom key should prevent this (this way you can still set any arguments for WP_Query as a fallback). I tested this code with the ListingHive demo content and it worked: