I have a view attempting to show content related by taxonomy (filter = set by the page where this view is shown).
The post where the view is shown has multiple levels within the taxonomy assigned (displayed in the post content template in hierarchal order like breadcrumbs). The CPT being queried in the view only has a single term within the taxonomy assigned, which as it happens is a grandchild term. In other words, post where the view is shown has terms like Top-levelParentTerm, ChildTerm, GrandchildTerm. The related-by-taxonomy CPT has only a single Grandchild term.
The output I'm getting on the post from the view includes CPTs with a different grandchild term set than the current post. I'm gathering that the filter includes any terms set by the page where the view is shown, and these terms inherit all their children/grandchildren?
Is there any way to filter the query to include only exact term matches; exclude sibling terms?
When the query hears "set by the page where this view is shown", it'll get all those terms, compare, and spit out whatever matches all terms of that current page or post where the View is inserted on.
I observe that if I have a Current page with a Parent term, then the View returns posts with that parent term AND the posts with the related Child Terms, even if they are not set on the current page, and the parent term is not set on the other post type.
This is unexpected IMHO.
Mainly because the other way around it works as I expect:
If the current page has only a Child Term assigned, then only posts with that child term assigned are returned in the View.
I escalate this as an issue, I am not yet sure if it's a BUG, but it's surely something we need to unify and clarify.
Thank you, Beda! What is the usual timeline for issue resolution? Unfortunately, other types of post relationships are not alternative paths I could take in trying to re-engineer the view I was hoping to create, so it still hinges on using a taxonomy filter. My current dilemma seems to be either waiting in hope that the filter will be updated to not include child terms that are not assigned to the page where the view is shown, or taking a hard look at sacrificing other aspects of how the project is utilizing taxonomy.
I investigated this and it turns out we follow the WordPress query.
I asked the developers if it's possible to enhance our GUI to allow a decision to be made, whether to follow the native WordPress methods or exclude the Child Term posts on Parent Term Post Queries.
We will see if we can implement this but I cannot guarantee it.
You can read a similar issue description here, which did not even use Toolset:
enlace oculto
Thank you for the update, Beda! I have been using an Insert Page widget combined with JetPack visibly on the grandchild terms as my current workaround, but that entails a crazy amount of widgets and adding more for each new instance. It's only good as a temporary solution until I'm able to automate with a view successfully or assess the impacts of changing how the taxonomy is being used so the view only returns the desired results. I took a look at the link you posted (thank you!) and it helps to know someone has successfully done what sounds like what I would like to happen here. I just hope it still includes child terms if they are set by the current page, and only excludes non-assigned child terms. Explicitly stating not to include child terms of a specific parent term has me wondering how it actually behaves, but I would still like to pursue it to find out.
Definitely add my vote for the GUI enhancement feature request. 🙂 Specifying the exact taxonomy and parent term in this instance should be fine but a more global/general operation at the GUI level is far more ideal. It seems as if the code in the link is meant to be used within a custom-coded template like single.php, but I would like to modify the query filter on the existing view. I am curious if this thought makes sense: combine https://toolset.com/documentation/programmer-reference/views-filters/#wpv_filter_query with the customized taxonomy query from the posted link. If I am on the right track, I'm assuming all I need to do is contained within functions.php, that there's nothing I need to add to the view itself. If I'm not at all on the right track, that would be great to know as well. I understand that custom coding is not included in the support forum; I am hoping to know whether I'm completely lost or partway there. Thank you!
Right now we have a filter:
apply_filters( 'wpv_filter_tax_filter_include_children', $include_child, $category->name, $view_id );
The thing is that we do have that piece of GUI but only for the mode for shortcode attribute or URL parameter:
the selector to decide whether the filter will apply to any, none or all selected or passed terms changes its behaviour:
by default, "any" means include children, while the other two options means do not include children.
But this is not added to the Query/GUI as you need it.
How to use the filter you could see here:
https://toolset.com/forums/topic/filtering-by-taxonomy-when-taxonomy-is-hierarchical/#post-508825
Thank you, Beda! Adding the Views filter hook from the other support thread indeed has my view working as I hoped/expected. Including a term's children does makes sense for the WordPress default since it's the behavior I'd expect for archives, but I'm very pleased to break out of that inheritance to do precise term matching for this related content view. This was everything I needed for this context, thank you!
