|
|
@@ -1008,34 +1008,55 @@ Twee losse punten om op te pakken:
|
|
|
toegepast op deze ene bestaande banner, en of er bewust voor
|
|
|
`PUitgaanPage` gekozen is als eerste plek.
|
|
|
|
|
|
-**P1-22 · Eigenaar: Onbepaald.** Emoji in Drupal-content worden `?`
|
|
|
--tekens i.p.v. correct weergegeven — content-encoding-bug,
|
|
|
-projectbreed. **Bevestigd live (2026-08-12)** op de omschrijving van
|
|
|
-evenement "Mythic Fest II" (zowel op de Home-kaart als op de
|
|
|
-EventCurrent-detailpagina, dus niet render-specifiek): tekst als
|
|
|
-`??? ????????? ?????? ????` en `?????-???? ???????` vóór/tussen
|
|
|
-overigens prima leesbare Nederlandse tekst — precies het patroon van
|
|
|
-emoji die als vervangingstekens worden weergegeven. **Root cause
|
|
|
-(code-niveau, redelijk zeker):** elke API-call in `api_calls.dart` (in
|
|
|
-ieder geval `EvenementCall`, `HomeTabelCall`, `EstablishmentInfoCall`,
|
|
|
-`EstablishmentsCall` — lijkt projectbreed dezelfde template) heeft
|
|
|
-`decodeUtf8: false`. In `api_manager.dart:211-214`
|
|
|
-(`ApiCallResponse.fromHttpResponse`) betekent dat: de responsebody
|
|
|
-wordt gelezen via `response.body` (Dart's `http`-package, die zonder
|
|
|
-expliciete `charset` in de `Content-Type`-header van de server
|
|
|
-terugvalt op **Latin-1**-decodering) i.p.v. expliciet
|
|
|
-`Utf8Decoder().convert(response.bodyBytes)`. Gewone Nederlandse
|
|
|
-diakrieten (é/ë/ï) vallen toevallig ook binnen Latin-1 en blijven dus
|
|
|
-goed — maar emoji (buiten Latin-1) worden zo onherstelbaar naar
|
|
|
-vervangingstekens gemapt. **Waarschijnlijk simpele, projectbrede fix:**
|
|
|
-`decodeUtf8: true` zetten op de API-calls (of, als dat via losse
|
|
|
-builder-toggles per call moet, een enkele globale plek zoeken in de
|
|
|
-FlutterFlow-projectinstellingen voor API-defaults) — controleer na de
|
|
|
-wijziging of de Drupal-respons zelf al `charset=utf-8` in
|
|
|
-`Content-Type` meestuurt (zo niet, is dat een aanvullende
|
|
|
-server-side-check waard, maar de `decodeUtf8: true`-fix in de app zou
|
|
|
-hoe dan ook al moeten helpen zolang de bytes zelf al geldige UTF-8
|
|
|
-zijn, wat aannemelijk is voor Drupal-JSON-export).
|
|
|
+**P1-22 · Eigenaar: Bob (10 sec-klusje per call, zelfde patroon als
|
|
|
+P1-10's cache-toggle — mechanisch, maar over veel API-calls
|
|
|
+verspreid).** Emoji in Drupal-content worden `?`-tekens i.p.v. correct
|
|
|
+weergegeven — content-encoding-bug, projectbreed. **Bevestigd live
|
|
|
+(2026-08-12)** op de omschrijving van evenement "Mythic Fest II" (zowel
|
|
|
+op de Home-kaart als op de EventCurrent-detailpagina, dus niet
|
|
|
+render-specifiek): tekst als `??? ????????? ?????? ????` en
|
|
|
+`?????-???? ???????` vóór/tussen overigens prima leesbare Nederlandse
|
|
|
+tekst — precies het patroon van emoji die als vervangingstekens worden
|
|
|
+weergegeven. **Root cause (code-niveau, bevestigd):** elke API-call in
|
|
|
+`api_calls.dart` (in ieder geval `EvenementCall`, `HomeTabelCall`,
|
|
|
+`EstablishmentInfoCall`, `EstablishmentsCall` — lijkt projectbreed
|
|
|
+dezelfde template) heeft `decodeUtf8: false`. In
|
|
|
+`api_manager.dart:211-214` (`ApiCallResponse.fromHttpResponse`)
|
|
|
+betekent dat: de responsebody wordt gelezen via `response.body` (Dart's
|
|
|
+`http`-package, die zonder expliciete `charset` in de
|
|
|
+`Content-Type`-header van de server terugvalt op **Latin-1**-decodering)
|
|
|
+i.p.v. expliciet `Utf8Decoder().convert(response.bodyBytes)`. Gewone
|
|
|
+Nederlandse diakrieten (é/ë/ï) vallen toevallig ook binnen Latin-1 en
|
|
|
+blijven dus goed — maar emoji (buiten Latin-1) worden zo onherstelbaar
|
|
|
+naar vervangingstekens gemapt.
|
|
|
+- **Fix bevestigd bereikbaar via de builder-UI, géén custom action
|
|
|
+ nodig (2026-08-12, screenshot van Bob):** elke API Call heeft onder
|
|
|
+ **Call Definition → Advanced Settings** een losse toggle
|
|
|
+ **"Decode Response as UTF-8"** — exact dezelfde plek/rij als de al
|
|
|
+ bekende "Cache API Results"-toggle uit P1-10 (op `EstablishmentInfo`
|
|
|
+ bevestigd: Cache staat al aan/blauw, Decode Response as UTF-8 staat
|
|
|
+ nog uit/wit). Simpelweg per API call aanzetten + de
|
|
|
+ Confirm-actiebalk bevestigen.
|
|
|
+- **Schaal:** de linkerlijst in het API Calls-paneel toont grofweg 15+
|
|
|
+ calls (`FavorietenAgendaTEST`, `getcsrf`, `ZZZhomeSlider`,
|
|
|
+ `homeSlidershortDate`, `homeTabel`, `ZZhome uitgaan`, `HomeSlider`,
|
|
|
+ `Uitgaanstabel`, `UitgaanSlider`, `EstablishmentsNew`,
|
|
|
+ `EstablishmentInfo`, `HorecagelegenheidEve...`,
|
|
|
+ `zzEstablishmentEvents...`, en vermoedelijk nog meer buiten beeld) —
|
|
|
+ waarschijnlijk hoeft dit niet op de `ZZ`/`zz`-geprefixte en
|
|
|
+ `TEST`-calls (lijken oud/scratch, zie ook P2-7's opschoonlijst) maar
|
|
|
+ wel op alles wat daadwerkelijk live gebruikt wordt. **Zelfde advies
|
|
|
+ als P1-10: niet in 1 sessie alle calls proberen, per herkenbaar
|
|
|
+ blokje (bv. per pagina/component-groep) oppakken.** Na elke batch
|
|
|
+ even een verse export/live check of de emoji in een testomschrijving
|
|
|
+ echt goed tonen (i.p.v. alleen op de "Synced"-badge vertrouwen, zie
|
|
|
+ `CLAUDE.md`'s bekende stille-niet-opgeslagen-patroon).
|
|
|
+- Controleer daarnaast (niet blokkerend voor deze fix) of de
|
|
|
+ Drupal-respons zelf al `charset=utf-8` in `Content-Type` meestuurt —
|
|
|
+ zo niet, is dat een aanvullende server-side-check waard, maar de
|
|
|
+ `Decode Response as UTF-8`-toggle in de app zou hoe dan ook al moeten
|
|
|
+ helpen zolang de bytes zelf al geldige UTF-8 zijn (aannemelijk voor
|
|
|
+ Drupal-JSON-export).
|
|
|
|
|
|
**P1-9 · Eigenaar: Onbepaald.** Visuele polish (los, per pagina) —
|
|
|
resterend na sessie 2026-08-06:
|
