|
|
@@ -2647,6 +2647,26 @@ krijgt dus de oude respons tot de cache echt geleegd is** — een geslaagde
|
|
|
cache-buster-test is dus wél bewijs dat je code klopt, maar géén bewijs
|
|
|
dat de app het al ziet.
|
|
|
|
|
|
+**De Services-views-resource heeft een EIGEN limiet (10) die de
|
|
|
+`items_per_page` van je view overrulet — en accepteert `limit`, `offset`
|
|
|
+en `page` als query-parameters.** Bevestigd 2026-09-08 op
|
|
|
+`flutterflowmobiel_establishment_events`, waar de view op
|
|
|
+`items_per_page = 25` stond maar de JSON hardnekkig 10 items gaf:
|
|
|
+```
|
|
|
+...&limit=25 -> 25 items
|
|
|
+...&limit=50 -> 50 items
|
|
|
+...&onzin=25 -> 10 items (controle: onbekende params worden genegeerd)
|
|
|
+```
|
|
|
+Zoek de oorzaak dus **niet** in de view als het aantal niet klopt; het
|
|
|
+zit in de resource-instellingen van het Services-endpoint. `page` en
|
|
|
+`limit` combineren netjes en overlappen niet
|
|
|
+(`page=0&limit=5` / `page=1&limit=5` gaven aaneensluitende nid-blokken),
|
|
|
+en `offset=5&limit=5` is identiek aan `page=1&limit=5`. **Gevolg voor
|
|
|
+FlutterFlow-paginering: aan de Drupal-kant hoeft er niets extra's te
|
|
|
+gebeuren** — een gewone pager in de view volstaat, `page` werkt al. Wat
|
|
|
+ontbreekt zit altijd aan de app-kant (een `page`-variabele op de API
|
|
|
+Call + Infinite Scroll op de Backend Query).
|
|
|
+
|
|
|
**Bij het testen of een views-endpoint een filter-parameter accepteert:
|
|
|
stuur altijd óók een verzonnen parameter mee als controle.** Drupal Views
|
|
|
negeert onbekende query-parameters **stil** — zonder die controle bewijst
|
