|
|
@@ -1163,6 +1163,49 @@ exacte veldnaam+type-specificatie (kost hem seconden per veld).
|
|
|
|
|
|
## Domein/architectuurcontext
|
|
|
|
|
|
+- **Drupal 7 Services-module: een nieuwe custom resource moet ook los
|
|
|
+ geactiveerd worden per endpoint — code alleen is niet genoeg.**
|
|
|
+ Bevestigd 2026-08-19 (Bob + Claude samen gedebugd, P1-7 Tab 1
|
|
|
+ "Persoonlijke agenda"): `favorieten_agenda.json` gaf op productie
|
|
|
+ een kale, lege 404 (geen enkele Drupal-header, niets in de
|
|
|
+ watchdog-log), terwijl exact dezelfde `custom.module`-code op
|
|
|
+ devbob prima werkte. De resource zelf stond correct gedefinieerd in
|
|
|
+ `hook_services_resources()` (`custom_services_resources()` in
|
|
|
+ `custom.module`) — dat alleen registreert 'm bij de module, maar
|
|
|
+ **een Services-endpoint (bv. `flutterdrup`) serveert alleen de
|
|
|
+ resources die daar expliciet voor zijn aangevinkt**, een aparte
|
|
|
+ config/database-instelling per endpoint, los van de module-code.
|
|
|
+ Die aanvinking was ooit op devbob gedaan (tijdens testen) maar nooit
|
|
|
+ meegenomen naar productie. **Check/fix altijd hier:**
|
|
|
+ `https://<domein>/en/admin/structure/services/list/<endpoint-naam>/resources`
|
|
|
+ (of via `drush @<site-alias> php-eval "print_r(services_endpoint_load('<endpoint-naam>'));"`
|
|
|
+ — vergelijk de `resources`-array tussen omgevingen). **Symptoom dat
|
|
|
+ hierop wijst:** een endpoint/pad dat op de ene Drupal-omgeving prima
|
|
|
+ werkt en op de andere een 404 geeft mét een compleet lege body en
|
|
|
+ zonder de gebruikelijke custom response-headers (bij dit project
|
|
|
+ bv. `x-speed-cache`/`x-device`/`x-geoip-*`, toegevoegd door de eigen
|
|
|
+ Aegir/Boa-caching-laag pas ná volledige Drupal-bootstrap) — dat wijst
|
|
|
+ op "wordt vroeg afgewezen, bereikt zelfs Drupal's eigen watchdog-log
|
|
|
+ niet", eerder dan een nginx/Cloudflare-routeringsprobleem. **Nuttig
|
|
|
+ debug-recept dat hiertoe leidde:** (1) `drupalRequest`'s eigen
|
|
|
+ `print()`-debug-output opvangen via `adb logcat` tijdens een live
|
|
|
+ test in de app, om de exacte headers/status/body te zien die de app
|
|
|
+ zelf verstuurt/ontvangt; (2) diezelfde request los met `curl -i`
|
|
|
+ natesten op beide omgevingen; (3) **om Cloudflare écht te omzeilen
|
|
|
+ moet je letterlijk `127.0.0.1` in de curl-URL zetten** (niet de
|
|
|
+ echte hostnaam, ook niet met een aangepaste `Host`-header — Cloudflare
|
|
|
+ zit op DNS-niveau, een `Host`-header alleen stuurt de request nog
|
|
|
+ steeds via Cloudflare's edge); (4) `menu_router`-tabel checken via
|
|
|
+ `drush php-eval` (leeg voor beide omgevingen was hier een belangrijke
|
|
|
+ aanwijzing dat dit geen kaal `hook_menu()`-pad was maar via
|
|
|
+ Services liep); (5) de Drupal watchdog-log (`admin/reports/dblog`)
|
|
|
+ vergelijken tussen omgevingen — als de kapotte omgeving zelfs geen
|
|
|
+ enkele logregel toont terwijl een ander, vergelijkbaar endpoint op
|
|
|
+ diezelfde omgeving wél volledig doorloopt (inclusief juiste
|
|
|
+ gebruikersherkenning), sluit dat sessie/cookie/nginx-routing-
|
|
|
+ problemen vrijwel uit en wijst het naar iets resource-specifieks
|
|
|
+ binnen Drupal/Services zelf.
|
|
|
+
|
|
|
- **Taal/locale volgt het toestel, niet hardcoded Nederlands** — zonder
|
|
|
opgeslagen voorkeur (`FFLocalizations`/`_kLocaleStorageKey`) valt
|
|
|
`MaterialApp.locale` terug op de systeemtaal van het toestel; matcht
|
