feat: resolve query loop pagination at request time - #126
Open
charl0tee wants to merge 1 commit into
Open
Conversation
Move core/query pagination resolution out of the build-time FSE template
snapshot and the PHP `X-Query-Page` mechanism into the Next data layer, so
pagination stays in sync when posts are published without a rebuild.
- Add the `core/query-pagination-numbers` block: replicates WordPress
`paginate_links()` (mid-size window + `…` dots), consuming `currentPage`,
`totalPages` and `baseUri`.
- Thread the current `/page/{n}` route + node base uri through the block
enrichment pipeline (formatBlocksJSON / enrichTemplateBlocks →
getBlockFinalComponentProps → getData) via a new `BlockDataContext`.
- `core/query` data layer now derives the offset from the route page and
injects href/label/isDisabled (next/previous) and currentPage/totalPages/
baseUri (numbers) into its pagination children.
- Re-enrich getData-returned innerBlocks so dynamic blocks nested inside a
query (or navigation submenu) still resolve their own getData.
- Remove the superseded `query-pagination-offset.php` and its loader require.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Contributor
Author
|
@kuuak @snugglejuice Fait avec Claude, et ça fonctionne sur Tipee. Mais volontiers si vous avez un peu de temps de checker quand même, pour s'assurer que j'ai pas loupé un soucis obvious ;) |
charl0tee
marked this pull request as draft
July 29, 2026 13:05
charl0tee
marked this pull request as ready for review
July 29, 2026 13:15
kuuak
approved these changes
Jul 29, 2026
kuuak
left a comment
kuuak
left a comment
Contributor
There was a problem hiding this comment.
Ça me semble ok, si ça fonctionne sur Tipee c'est certainement une bonne implémentation.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Contexte
La pagination de
core/queryétait résolue au build-time : les attributs des blocscore/query-pagination-*sont figés dans le snapshot du template FSE (fse-templates-and-parts.json), et l'injection PHP (query-pagination-offset.phpvia le headerX-Query-Page) ne s'exécute jamais au request-time pour ces blocs. Conséquence : publier un nouvel article ne met pas la pagination à jour sans rebuild.Cette PR déplace tout le calcul de pagination au request-time, côté Next (dans le data layer de
core/query, qui tourne à chaqueget-node-by-uri).Changements
Nouveau bloc
core/query-pagination-numbersnext/src/components/core/QueryPaginationNumbers/— réimplémente l'algorithmepaginate_links()de WordPress (fenêtremidSizeautour de la page courante +…), en consommantcurrentPage,totalPages,baseUri.Blocks.tsx.Threading du contexte request-time
BlockDataContext(page,baseUri,innerBlocks) danstypings.d.ts.page(route/page/{n}) +baseUri(uri du node) propagés viaformatBlocksJSON/enrichTemplateBlocks→getBlockFinalComponentProps→getData(4ᵉ argument, rétro-compatible).X-Query-Pagesupprimé deget-node-by-uri.ts.core/querydata layer(page-1)*perPage) → les articles affichés changent selon/page/{n}.innerBlocksde pagination :href/label/isDisabled(next/previous) etcurrentPage/totalPages/baseUri(numbers). Logique identique à l'ancien PHP.core/queryimbriqués sont laissés intacts.getBlockFinalComponentPropsinnerBlocksretournés pargetDatasont désormais ré-enrichis par le même pipeline, pour que tout bloc dynamique imbriqué (pagination dans une query, navigation dans un submenu) résolve son propregetData.Suppression du mécanisme redondant
wordpress/theme/includes/graphql/query-pagination-offset.phpsupprimé + sonrequireretiré de_loader.php. Une seule source de vérité.Notes
QueryPaginationNumbersest volontairement non-stylé, par cohérence avec les blocs next/previous (à styler par projet).baseUriprovient de l'uri du node résolu. Si la query loop vit dans un template FSE (source sans uri), il retombe sur/— limitation partagée avec next/previous.Validation
tsc --noEmit: ✅eslint(fichiers modifiés) : seules des erreursno-explicit-anypré-existantes subsistent, aucune introduite.php -lsur_loader.php: ✅🤖 Generated with Claude Code