Filters key off `queryId`, which is neither guaranteed present nor unique
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 35/100
- Tipo di issue
- Bug
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Attiva
- Stack tecnologico
- javascript, php
Direzione di ricerca
Inizia tracciando filter_query_loop_block_query_vars() e pre_get_posts_transpose_query_vars(), insieme alla generazione dell’URL query-{queryId}-{key} del blocco filtro. Riproduci i casi missing-queryId e duplicate-queryId descritti nell’issue, quindi stabilisci quale comportamento di gestione dell’ambito dovrebbe essere supportato prima di implementare o testare una correzione.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Scoping a filter to its loop relies entirely on the query block's queryId attribute: the filter blocks write query-{queryId}-{key} into the URL, filter_query_loop_block_query_vars() copies queryId into the query as query_id, and pre_get_posts_transpose_query_vars() matches the parameter prefix against it.
That attribute is neither guaranteed to exist nor guaranteed to be unique, and both edges fail badly.
1. No queryId at all — the filter silently does nothing
A query block whose markup carries a query object but no queryId:
<!-- wp:query {"query":{"perPage":10,"postType":"post","order":"asc","orderBy":"title","inherit":false}} -->
The filter renders happily and writes ?query-0-category=alpha (from $block->context['queryId'] ?? 0). But filter_query_loop_block_query_vars() only sets query_id when isset( $block->context['queryId'] ), so the loop's query has none, pre_get_posts_transpose_query_vars() returns early, and nothing is filtered.
Verified on WordPress 6.8.8 and 7.0.4: ?query-0-category=alpha and ?query-category=alpha both return the full, unfiltered set. The control looks like it works — the selection sticks, the URL changes, the results don't.
2. Two loops sharing a queryId — one control filters both
Two query blocks with the same queryId (7 in both), a taxonomy filter in the first only:
| URL | Loop 1 | Loop 2 |
|---|---|---|
/repro-dup/ |
all 4 posts | all 4 posts |
/repro-dup/?query-7-category=alpha |
Alpha One, Alpha Two | Alpha One, Alpha Two |
The second loop has no filter block, and is narrowed anyway.
This matters because duplicating a query loop block in the editor copies queryId along with everything else — see WordPress/gutenberg#55823 ("Duplicating Query Block can result in duplicate Query IDs", still open) and the closed WordPress/gutenberg#56902 ("Same queryId for all Query Loops"). Core's own enhanced pagination has the same problem, and the proposals upstream (a isUnique / non-copyable attribute property, or deriving the id from an instance id at render) have not landed.
That also looks like the mechanism behind #28, where filtering applied to every loop on the page: two loops built by duplicating one share an id, so one prefix addresses both. Filtering is correctly scoped between loops with distinct ids, which is why that report did not reproduce from hand-written fixtures.
Worth deciding
Whether the plugin should defend itself here, and how much:
- Render nothing (or an editor warning) when a filter block sits in a loop with no
queryId, rather than a control that cannot work. - Detect two loops sharing an id in one render pass and warn, since the plugin cannot honour both.
- Or derive the scope from something the plugin controls rather than trusting the authored attribute — which needs the filter block and the loop to agree on it at render time, so it is not a small change.
The first is small and removes a silent failure. The rest deserves a design decision before anyone writes code.
Environment
Reproduced on WordPress 6.8.8 and 7.0.4, PHP 8.4, Twenty Twenty-Five, plugin at main (d8468ea).
- Lingua principale
- PHP
- Stelle
- 124
- Fork
- 33
- Merge medio
- 20h 58m
- PR unite (30g)
- 1
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di humanmade/query-filter
-
`render_block_query` overwrites the `core/query` namespace, breaking context for enhanced paginationAperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
humanmade/query-filter#72 ·
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 68/100
humanmade/query-filter#67 ·
-
Selected Filters BlockAperta
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
humanmade/query-filter#66 ·
-
Reset blockAperta
Difficoltà 3/5 1-2 giorni Idoneità per principianti 48/100
humanmade/query-filter#65 ·
-
Order blockAperta
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
humanmade/query-filter#64 ·
Tutte le issue di humanmade/query-filter
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 84/100
wp-graphql/wp-graphql-woocommerce#1026 ·
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
taskforcesh/bullmq#5038 ·
I maintainer di solito rispondono entro 1 giorno
-
ServiceMapMissingAnalyser reads @method in docblock prose as a tag and reports a phantom accessorApertaagent-ready area:static-analysis bug p3
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
gacela-project/gacela#1050 ·
I maintainer di solito rispondono entro 1 giorno