瀏覽代碼

Taak 128-A: confirm afleiden uit simplenews zelf i.p.v. vastzetten

simplenews_subscribe_user() kijkt niet of iemand ingelogd is; hij doet
blind wat de $confirm-parameter zegt. De Double-regel wordt door de
aanroeper toegepast, en het websiteformulier gebruikt daarvoor
simplenews_require_double_opt_in($tid, $account). De resource roept nu
diezelfde functie aan, dus de app volgt de website automatisch en blijft
kloppen als de opt-in-instelling ooit wijzigt.

Read-only geverifieerd op productie: die functie geeft false voor de
ingelogde gebruiker zelf (direct actief, geen mail) en true voor een
vreemd adres (bevestigingsmail) -- precies de Double-semantiek.

De variabele custom_nieuwsbrieven_confirm blijft als noodrem, maar is
normaal niet nodig.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
bob 5 小時之前
父節點
當前提交
a3883f210e
共有 2 個文件被更改,包括 54 次插入23 次删除
  1. 23 10
      TASKS.md
  2. 31 13
      snippets/nieuwsbrieven-drupal.inc.txt

+ 23 - 10
TASKS.md

@@ -135,17 +135,28 @@ de app stuurt GEEN bevestigingsmail, en dat is correct.** De drie nieuwsbrieven
 staan op opt-in/out-methode **Double**, en simplenews omschrijft die stand zelf
 als: *"anonymous users receive an (un)subscription confirmation email.
 Authenticated users are (un)subscribed immediately."* Een app-gebruiker is per
-definitie ingelogd, dus die hoort direct verwerkt te worden — net als op
-`/user/<uid>/simplenews`. `custom_nieuwsbrieven_confirm` staat daarom op
-**FALSE** (default in de code); op `1` zetten geeft alsnog bevestiging.
+definitie ingelogd, dus die hoort direct verwerkt te worden.
+
+⚠️ **Maar simplenews past die regel niet zelf toe.** `simplenews_subscribe_user()`
+bevat geen enkele check op de ingelogde gebruiker — hij doet blind wat de
+`$confirm`-parameter zegt (gecontroleerd in de broncode). De *aanroeper* bepaalt
+die waarde, en het websiteformulier doet dat met
+**`simplenews_require_double_opt_in($tid, $account)`**: FALSE zodra het
+mailadres van de ingelogde gebruiker zelf is, anders de opt-in-methode van de
+nieuwsbrief. De resource roept sinds 2026-09-21 precies diezelfde functie aan,
+dus de app volgt de website automatisch — ook als de opt-in-instelling ooit
+wijzigt. Read-only geverifieerd op productie: voor de ingelogde gebruiker geeft
+hij `false` op alle drie de nieuwsbrieven, voor een vreemd adres `true`.
+
+De variabele `custom_nieuwsbrieven_confirm` blijft bestaan als noodrem (niet
+gezet = automatisch, 1 = altijd mail, 0 = nooit), maar is normaal niet nodig.
 
 Uitschrijven gaat altijd direct, ook als bevestiging aan zou staan: anders
 drukt de gebruiker in de app op "uit" en blijft hij abonnee tot hij een mail
 opent.
 
 **De resource geeft toch de STATUS terug, niet een kale bool** (1 aan / 2 wacht
-op bevestiging / 0 uit). Dat kost niets en houdt de deur open: zet iemand ooit
-`confirm` aan, dan hoeft de app niet aangepast te worden.
+op bevestiging / 0 uit). Dat kost niets en houdt de deur open.
 
 ### Eerder als risico genoteerd, nu verklaard
 
@@ -173,11 +184,13 @@ Bobs tests liepen via de website-pagina (`source = website`). Op productie staat
 `source = app` nog op 0 treffers; dat is meteen de manier om te zien of de
 eerste app-aanmelding door de nieuwe route is gekomen.
 
-⚠️ **Eén nazorgpunt op beide omgevingen:** het gedeployde bestand heeft nog
-`variable_get('custom_nieuwsbrieven_confirm', TRUE)`. Dat moet FALSE zijn (zie
-hierboven). Kies één van twee: de regel in `custom.nieuwsbrieven.inc` aanpassen
-(staat al goed in het snippet) óf tot die tijd
-`drush @<alias> vset custom_nieuwsbrieven_confirm 0` op beide omgevingen.
+⚠️ **Nazorg op beide omgevingen:** het gedeployde `custom.nieuwsbrieven.inc`
+bevat nog de eerste versie, met `variable_get('custom_nieuwsbrieven_confirm',
+TRUE)` — die zou een ingelogde app-gebruiker wél een bevestigingsmail sturen.
+Vervang die regels door de versie in het snippet (die roept
+`simplenews_require_double_opt_in()` aan) en draai `cc all`. Wie niet wil
+redeployen: `drush @<alias> vset custom_nieuwsbrieven_confirm 0` doet het ook,
+maar dan staat er een knop die niemand later nog begrijpt.
 
 **✅ Code is af en staat klaar in `snippets/nieuwsbrieven-drupal.inc.txt`** (compleet bestand `custom.nieuwsbrieven.inc` + het blok voor `custom_services_resources()` + de deploy- en controlestappen). PHP-syntax gecontroleerd op de server en de index-logica read-only drooggedraaid op productie voor een Horeca-owner, een gewone gebruiker met abonnement en een zonder: rolfilter en statussen kloppen.
 

+ 31 - 13
snippets/nieuwsbrieven-drupal.inc.txt

@@ -39,8 +39,16 @@ omschrijft die stand zelf zo:
 
 Bevestiging geldt dus alleen voor ANONIEME bezoekers. Een app-gebruiker is
 per definitie ingelogd en wordt direct (un)subscribed — net als op
-/user/<uid>/simplenews. Daarom staat `custom_nieuwsbrieven_confirm` op
-FALSE: zo doet de app exact hetzelfde als de website.
+/user/<uid>/simplenews.
+
+⚠️ Simplenews past die regel NIET zelf toe. simplenews_subscribe_user()
+bevat geen enkele check op de ingelogde gebruiker; hij doet blind wat de
+$confirm-parameter zegt. De formulieren bepalen die waarde, met
+simplenews_require_double_opt_in($tid, $account) — FALSE zodra het
+mailadres van de ingelogde gebruiker zelf is, anders de opt-in-methode.
+Deze resource roept precies diezelfde functie aan, dus de app volgt de
+website automatisch, ook als de opt-in-instelling ooit wijzigt. Je hoeft
+er geen variabele voor te zetten.
 
 Dit verklaart ook het cijfer dat eerder verdacht leek. Gemeten over de hele
 database (tid 1, een oude restterm, niet meegeteld):
@@ -57,10 +65,10 @@ er in tien jaar nul zijn bevestigd — dat is een lage conversie op de
 publieke formulieren en misschien ooit een eigen kijkje waard, maar het
 raakt de app niet.
 
-WIL JE HET TOCH MET BEVESTIGING (dan blijft het abonnement op status 2 tot
-de gebruiker op de link klikt — de app toont die stand al):
+NOODREM (normaal niet nodig): custom_nieuwsbrieven_confirm overrulet de
+functie hierboven. Niet gezet = automatisch, 1 = altijd bevestigingsmail,
+0 = nooit.
   drush @uitgaanskrant.com vset custom_nieuwsbrieven_confirm 1
-Terug naar direct abonneren:
   drush @uitgaanskrant.com vdel custom_nieuwsbrieven_confirm
 
 
@@ -252,14 +260,24 @@ function _custom_nieuwsbrieven_wijzig($tid, $aan) {
     // Al actief? Niets doen. Anders stuurt simplenews bij confirm=TRUE tóch
     // een mail ("je bent al ingeschreven") bij elke dubbele tik.
     if ($huidig !== 1) {
-      // FALSE (default) = meteen actief, geen mail. Dit is wat de
-      //   opt-in/out-methode "Double" voorschrijft: anonieme bezoekers
-      //   krijgen een bevestigingsmail, ingelogde gebruikers worden
-      //   direct (un)subscribed. Een app-gebruiker is altijd ingelogd.
-      // TRUE = bevestigingsmail; het abonnement blijft dan op status 2
-      //   tot de gebruiker op de link klikt.
-      $confirm = (bool) variable_get('custom_nieuwsbrieven_confirm', FALSE);
-      simplenews_subscribe_user($account->mail, $tid, $confirm, 'app');
+      // Wel of geen bevestigingsmail? Niet zelf beslissen, maar exact
+      // dezelfde regel volgen als het websiteformulier: dat roept
+      // simplenews_require_double_opt_in() aan. Die geeft FALSE zodra het
+      // mailadres van de ingelogde gebruiker zelf is, en valt anders terug
+      // op de opt-in/out-methode van de nieuwsbrief. Een app-gebruiker is
+      // per definitie ingelogd, dus dit levert hier altijd FALSE op:
+      // meteen actief, geen mail. Verandert de opt-in-instelling ooit, dan
+      // volgt de app vanzelf mee.
+      //
+      // Let op: simplenews_subscribe_user() kijkt NIET zelf of iemand
+      // ingelogd is -- hij doet blind wat deze parameter zegt. De
+      // "Double"-stand wordt dus door de aanroeper toegepast, niet door
+      // simplenews.
+      $confirm = variable_get('custom_nieuwsbrieven_confirm', NULL);
+      if ($confirm === NULL) {
+        $confirm = simplenews_require_double_opt_in($tid, $account);
+      }
+      simplenews_subscribe_user($account->mail, $tid, (bool) $confirm, 'app');
     }
   }
   else {