Newsletter, unabsichtliche Abmeldung, Bestellung ohne Kundenkonto

Deutsches Forum
1

Folgendes Szenario:

Ich schicke einen Newsletter an alle, die dem zugestimmt haben. In der Datenbank oxnewssubscribed ist bei diesen E-Mail-Adressen oxdboptin = 1 (Double Opt-In, bestätigt).

Da ich so ein tolles Angebot aus meinem Shop im Newsletter angepriesen habe, besuchen ein paar User diesen und wollen kaufen.
Sie haben kein Kundenkonto und fahren ohne Registrierung fort.

Wenn im folgenden Dialog der Benutzer nicht die Newsletter abbonieren-Checkbox anklickt, wird oxdboptin = 0 und der Kunde bekommt in Zukunft keine Newsletter mehr, obwohl er sich nicht abgemeldet hat. ???

Falls er die Newsletter-Checkbox neu anklickt, wird oxdboptin = 2 und er soll nochmal bestätigen, dass er sich angemeldet hat. ???

Irgendwie ziemlich unschön.

Wenn der User kein Passwort hat, wird der bestehende Eintrag einfach überschrieben, und damit auch die Newsletter-Einstellung. Ich mach mir da jetzt ein wenig Sorgen, dass mit jedem Newsletter die Newsletter-Abonnenten weniger werden.

Das kann doch nicht im Sinne des Erfinders sein? Hab ich einen Denkfehler oder wie macht ihr das?

Über Feedback würde ich mich sehr freuen. Viele Grüße.

2

Ja, ich stolper auch seit einiger Zeit über dieses Thema und wundere mich vor allem, kaum weitere Infos oder weitere Leidtragende zu finden. Von daher passt dieser Thread insgesamt wohl am besten, auch wenn recht betagt. :wink:

Wenigstens seit OXID 4.7 scheint es so zu sein wie oben beschrieben und noch eine Spur schräger. Man bekommt nämlich [B]jedesmal[/B], wenn man von Schritt 2 zu 3 springt, diese OptIn-Mail, was irre nerven kann, falls man nachträglich z.b. noch den Warenkorb ergänzt. Wir hielten das für einen Bug, und dachten es wäre schlau, die Checkbox dort rauszunehmen und “blnewssubscribed” dauerhaft auf 0 zu setzen, weil anders mit wenig Aufwand kaum zu lösen. Nun fiel auf, dass dadurch eben jeder Kunde automatisch wieder aus dem NL ausgetragen wird, was fast noch schlimmer ist!

Man hat also die Wahl der Qual: entweder andauernd OptIn-Mails, oder gar kein NL… :eek:
Irgendwo ist ein Denkfehler im Code, da vergessen wird zu prüfen, ob ein Kunde schon registriert ist, um dann den Status zu belassen und vor allem keine Mails mehr zu schicken. Hat nicht jmd, Lust, einen griffigen Bugtrack zu verfassen (ich gerade nicht so)? :wink:

Konkreter Verdacht:
Es scheint $iOptInStatus nicht korrekt in oxuser.php / setNewsSubscription() anzukommen, die ist fälschlicherweise immer 0, auch wenn der User 1 oder 2 hat. Wenn die Variable stimmen würde, müsste auch der Rest hinhauen…

Grüße

3

Ach Leute, dies ist schon ein cooles Forum, man braucht nur was schreiben und kommt dadurch auf gute Ideen! :wink:
Also eigentlich ganz simpel (ich war vorher nur blind). In der oxcmp_user.php Z.617 heißt es ja:

// check if email address changed, if so, force check news subscription settings.
            $blForceCheckOptIn = ( $aInvAdress['oxuser__oxusername'] !== $sUserName );
            $this->_blNewsSubscriptionStatus = $oUser->setNewsSubscription( $blOptin, $this->getConfig()->getConfigParam( 'blOrderOptInEmail' ), $blForceCheckOptIn );

Das ist die einzige Stelle in OXID, wo setNewsSubscription mit dem dritten Parameter aufgerufen wird, und die force-Prüfung ist Quatsch, da sich oxuser__oxusername niemals in $aInvAdress befinden wird (gibt kein FormField dafür)! Im Account-Form hätte man zwar oxusername aber keine NL-checkbox. D.h. der force-Parameter ist immer true, was in setNewsSubscription() dazu führt, dass iOptInStatus NIE gesetzt wird und die restliche Logik durcheinander kommt!

Ich weiß, was in Zukunft seitens OXID geplant war/ist, aber aktuell würde ich sagen, der einfachste und konsequente Weg ist, den force-Parameter zu elimieren. Um dies mit möglichst wenig Code als Modul zu schaffen, fiel mir folgendes ein:

<?php
class wn_oxuser extends wn_oxuser_parent
{
    public function setNewsSubscription( $blSubscribe, $blSendOptIn, $blForceCheckOptIn = false )
    {
    	return parent::setNewsSubscription( $blSubscribe, $blSendOptIn, false );
    }
}

Damit ist endlich Ruhe mit den OptIn-Mails, wenn der Haken aktiv ist. Da man aber den Kunden unnötig dazu verleitet, sich (evtl. aus Versehen) abzumelden, ist es wahrscheinlich trotzdem schlau, diese Option an der Stelle gar nicht anzubieten, sondern durch:

<input type="hidden" name="blnewssubscribed" value="[{if $oView->isNewsSubscribed()}]1[{else}]0[{/if}]">

zu ersetzen. Mit dem obigen Bugfix klappt dies nun ja ohne Probleme… :slight_smile:

Grüße

4

schau mal hier: https://bugs.oxid-esales.com/view.php?id=4838

5

Na primo, warum finde ich das nicht? Aber ich danke dir!
Nur was heißt bitte “Patch for 4.6” und “it is included in 5.0.4 release.”? Ich hätte es auch gern z.b. in 4.7.4 gefixt, falls die erscheint… :wink:

6

5.0.4 EE entspricht ja 4.7.4 CE/PE - der Patch dürfte nächste Woche rauskommen

7

Okay, ich komme gerne immer noch ins Tüdeln mit eurer neuen Versions-Politik, sorry!
Also Patch in Sicht, alles klar. Nur bleibt trotzdem die Frage, warum überhaupt dieser störende force-Parameter eingeführt wurde, wenn er gänzlich nutzlos ist? Auch der Patch ist eigentlich sinnlos, da an der Stelle niemals $aInvAdress[‘oxuser__oxusername’] von “null” abweichen wird, aber egal, er bewirkt schon das richtige. Mag ja wie gesagt sein, dass in Zukunft damit noch was anderes geplant ist…