Taxonomy filter to respect query loop settings

[scottpoulin]

The taxonomy filter pulldown will display all terms from that taxonomy, regardless of whether the parent query loop is using taxonomy filtering or not.

It seems to me that if you're limiting the terms in a query loop, the filter pulldown should be limited to those same terms - otherwise you can select a term that's not in the query loop's result set and get "nothing found."

This branch handles this situation, both for filtering via the standard Gutenberg taxonomy filter and Advance Query Loop's implementation. Note that the latter is only partially supported due to limitations in WP's get_terms function - specifically, only IN and NOT IN operators are supported, and multiple term queries must use the OR relation.

[tabbplomaritas]

This is a much needed improvement if this fix works. Hoping Humanmade can review and merge this soon!

[zamartz]

Agree! need this!

[roborourke]

Triaging the open PRs. Thanks for this @scottpoulin — the underlying goal (term lists that respect the Query Loop's own taxonomy settings) is one we definitely want, and it's closely related to #52.

This needs a rebase onto main before it can be reviewed properly, and it won't be a mechanical one. Two things have changed underneath it:

1. build/ is gone from the repository (removed in c1aabe0) — built files are generated at release time and gitignored now. Your branch still modifies build/taxonomy/render.php, so that part should just be dropped.

2. The get_terms() call has moved. src/taxonomy/render.php no longer queries terms itself; it calls \HM\Query_Loop_Filter\get_filter_terms( $attributes ) in inc/namespace.php. That function now also handles the includeTerms / excludeTerms attributes, curated ordering, and URL-encoded non-ASCII slugs. So the AQL/taxQuery logic in this PR wants to move into get_filter_terms() and merge with the include/exclude handling that's already there, rather than replacing a plain get_terms() call. That's the real conflict — git rebase can't resolve it for you.

One thing to watch when you redo it: the diff currently flips

if ( empty( $block->context['query']['inherit'] ) ) {

back to

if ( $block->context['query']['inherit'] ) {

which reintroduces the undefined-array-key warning from #15. main has the empty() guard now, so please keep it.

Also worth reading before you start: #52 covers the closely-related case of term lists that ignore other active filters on the same loop, and #32 adds a "Show Terms in Current Results" option to the same block. There's a real chance all three want to converge on one implementation inside get_filter_terms() — some coordination there would save duplicated work.

A couple of smaller notes for whenever the rebase happens:

• and / or should be && / ||, and == should be ===, per the project's WPCS config.
• get_term_by( 'name', ... ) is ambiguous when two terms share a name in a hierarchy. If AQL really does store names rather than IDs or slugs, a comment saying so would help; otherwise slugs would be safer.
• The count( $queries ) > 0 && ( relation === 'OR' || count( $queries ) === 1 ) condition is doing a lot of work in one line — worth an early return or a small helper with the "AND across multiple queries is unsupported" reasoning spelled out.

Happy to help if the merge into get_filter_terms() is fiddly — just say. If you'd rather not pick it back up, let us know and we'll carry the approach forward from your commit with credit.

---

Generated by Claude Code