|
|
@@ -2523,6 +2523,24 @@ tweede schrijfroute (bv. een Django-importer met een eigen
|
|
|
databaseverbinding) zijn eigen `charset`-instelling heeft, ook al staat
|
|
|
de kolom goed.
|
|
|
|
|
|
+**Na een deploy van custom-module-code die een views-JSON aanpast: de
|
|
|
+oude respons blijft uit Drupal's page cache komen — test met een
|
|
|
+cache-buster.** Bevestigd 2026-09-08 (P1-45): de code stond correct op
|
|
|
+productie, maar `curl` gaf onveranderd de oude vorm terug. De header
|
|
|
+**`x-drupal-cache: HIT`** verraadt het (let op: `cache-control:
|
|
|
+no-store, no-cache` staat er óók bij en is misleidend — dat gaat over de
|
|
|
+client, niet over Drupal's eigen cache). Een willekeurige extra
|
|
|
+query-parameter maakt een andere cache-key en toont meteen de verse
|
|
|
+render:
|
|
|
+```
|
|
|
+curl -s -u bob:serhii "<url>&_cb=$RANDOM$RANDOM" | jq -c '.[0]'
|
|
|
+```
|
|
|
+Een `Cache-Control: no-cache`-header doet dit **niet** — die wordt
|
|
|
+genegeerd. **Belangrijk gevolg: de app vraagt zonder cache-buster op, en
|
|
|
+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.
|
|
|
+
|
|
|
**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
|