|
@@ -727,6 +727,36 @@ en staat in de map `kanweg`. Drie dingen die daaruit volgen:
|
|
|
één poging niet, laten staan.
|
|
één poging niet, laten staan.
|
|
|
- **P1-30 · Cloudflare rate limiting** aanzetten, en dan óók de twee
|
|
- **P1-30 · Cloudflare rate limiting** aanzetten, en dan óók de twee
|
|
|
rate-limiting-vinkjes weghalen uit de custom rule `flutterflow`.
|
|
rate-limiting-vinkjes weghalen uit de custom rule `flutterflow`.
|
|
|
|
|
+- **P2-25 · Cleanup `custom.module` — debugging alleen op devbob · Eigenaar:
|
|
|
|
|
+ Bob (Drupal-code, aangemaakt 2026-09-14).** Vóór livegang moet de custom
|
|
|
|
|
+ module (`custom.module` + `custom.evenementen_aanmaken.inc` en de overige
|
|
|
|
|
+ `.inc`-bestanden die de `flutterdrup`-Services-resources voeden) goed
|
|
|
|
|
+ werken **zonder overbodig te loggen**. Nu zit er debug-uitvoer in die
|
|
|
|
|
+ tijdens het bouwen van P2-15/de favorieten handig was, maar op productie
|
|
|
|
|
+ alleen de watchdog/dblog volschrijft. Bewust **pas aan het einde** doen,
|
|
|
|
|
+ na de laatste functionele Drupal-wijzigingen — anders raak je de
|
|
|
|
|
+ debug-info kwijt terwijl je 'm nog nodig hebt.
|
|
|
|
|
+ Aanpak:
|
|
|
|
|
+ 1. Inventariseer alle `watchdog(...)`/`dpm(...)`/`error_log(...)`/
|
|
|
|
|
+ `drupal_set_message(...)`-debugregels in de custom module
|
|
|
|
|
+ (`grep -n "watchdog\|dpm(\|error_log\|drupal_set_message" custom.module *.inc`).
|
|
|
|
|
+ 2. Splits in **echte fouten** (blijven, `WATCHDOG_ERROR`/`WATCHDOG_WARNING`)
|
|
|
|
|
+ en **debug/trace** (request-body dumps, "resource aangeroepen"-regels,
|
|
|
|
|
+ tussenwaarden).
|
|
|
|
|
+ 3. Debug/trace achter één schakelaar zetten die alleen op devbob aan staat,
|
|
|
|
|
+ bv. een Drupal-variabele `custom_debug` (`variable_get('custom_debug',
|
|
|
|
|
+ FALSE)`) in een kleine helper `_custom_debug($msg, $vars)`, zodat het
|
|
|
|
|
+ op productie standaard uit staat en op devbob met één
|
|
|
|
|
+ `drush vset custom_debug 1` weer aan kan. Geen debug-code weghalen die
|
|
|
|
|
+ bij een storing op productie nog nuttig kan zijn — alleen uitzetten.
|
|
|
|
|
+ 4. Nalopen dat er geen `print`/`var_dump`/`dd()` meer in staat die de
|
|
|
|
|
+ JSON-respons kan vervuilen (de app parst de body strikt; één regel
|
|
|
|
|
+ ervoor breekt `getJsonField`).
|
|
|
|
|
+ 5. Deploy naar productie, Drupal-cache legen, en met een cache-buster
|
|
|
|
|
+ nameten dat elk endpoint nog dezelfde JSON geeft (zie het
|
|
|
|
|
+ `_cb=$RANDOM`-recept in `CLAUDE.md`) én dat de dblog na een testronde
|
|
|
|
|
+ in de app schoon blijft.
|
|
|
|
|
+ Hoort samen met P1-30 (Cloudflare) in dezelfde livegang-ronde.
|
|
|
- **Max items + tab 6** (P2-24 A en C) — geparkeerd, zie daar. Melden bij
|
|
- **Max items + tab 6** (P2-24 A en C) — geparkeerd, zie daar. Melden bij
|
|
|
FlutterFlow-support is de enige overgebleven route.
|
|
FlutterFlow-support is de enige overgebleven route.
|
|
|
|
|
|