Users who subscribe during registration receive two emails, sent in this order:
Introduced to fix a security bug in #3049356: Anon user can alter any anonymous subscription.
Depends on #3332695: Model for confirmations is flawed
simplenews_user_profile_form_submit(), if there are subscriptions then call Subscriber::loadByMail($checkTrust = TRUE) and save the subscriptions in the resulting subscriber.simplenews_user_login(), simplenews_user_view(), SubscriptionsAccountForm::buildForm() pass call Subscriber::loadByUid($unconfirmed = TRUE). For the latter two, if the subscriber is unconfirmed then output form text indicating that.simplenews_user_login() by setting the subscriber to confirmed and saving. 
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
compare
Comments
Comment #2
adamps commentedComment #3
anruetherI'm bumping this up to major, because for cases with a "silent" newsletter this potentially blocks new users from being subscribed.
Background: We have a an "all users newsletter" where we send important technical information to all users about their account - which is a legitimate interest in the sense of the gdpr so no consent necessary.
There is also no workaround because admins can't manually confirm users.
Since #3035367: Track history of subscribe/unsubscribe and proof of consent doesn't have much traction for quite a while now, what would be the approach to solve this with the current state of the module?
Comment #4
anruetherComment #5
adamps commentedIt would be something like this, but I'm not sure if it's actually possible.
simplenews_user_profile_form_submit()there are calls to$subscription_manager->subscribe. We would like no confirmation mails and yet no subscribe immediate. We need to alter the interface to allow this. I suggest we add a new parameter "bool $skip_confirmation_mail = FALSE". Remove the @todo comment in this function.SubscriptionManager::subscribe()write code to handle$skip_confirmation_mailequals TRUE. It's a bit awkward as we do need to call$subscriber->setChanges()but not$this->mailer->sendCombinedConfirmation().simplenews_user_login(), write code similar toConfirmationController::confirmCombined(). However I'm not sure how we know if the changes in the subscriber are still the same ones - what do we use as equivalent to the$hash? Remove the @todo comment.I think the whole model for confirmations is currently quite flawed.
Comment #6
geek-merlin> I think the whole model for confirmations is currently quite flawed.
Yup.
I have worked with the email_confirmer module and i like the approach of factoring out that functionality.
Unfortunately it is effectively unmaintained, but can be a good start for such a component.
Comment #7
super_romeo commentedI wonder why there are so few subscribers on this issue. It affects thousands of sites.
I think it's just that the administrators have not checked the registration for a long time, like me.
Comment #8
super_romeo commentedThe problem is wider.
Emails send in this sequence:
Thus this emails appears in email app in in reverse order.
So user firstly follow the subscription confirmation link. And after click button he is wondering why he is still not logged in???
Big percent just leave my website.
Comment #9
super_romeo commentedChecking checkbox
Skip email verification (discouraged)on/admin/config/services/simplenews/settings/subscriptionfixed this problem.Comment #10
adamps commentedI created #3332695: Model for confirmations is flawed.
Interesting. However I think the problem is not really with the code that sends the emails and receives the confirmations. Instead we are lacking somewhere to store the unconfirmed subscription. That's what the new issue fixes, and I believe we'd need that fix even if we switch to a different confirmation model.
It only affects sites that allow subscription on the email registration form. I guess that reduces the number of sites.
True but you then have no confirmations in all cases - also when subscribing via the subscriber block.
Comment #11
adamps commentedComment #12
adamps commentedComment #13
adamps commentedComment #14
adamps commentedComment #16
adamps commentedComment #17
adamps commentedThis patch is code complete with some brief manual testing. The tests have not yet been updated.
Comment #18
adamps commentedComment #19
adamps commentedComment #21
adamps commentedComment #23
adamps commentedComment #25
adamps commentedComment #27
adamps commentedComment #29
adamps commentedComment #31
adamps commentedComment #33
adamps commentedSome redesign of the subscriber fields...
Comment #34
adamps commentedComment #37
adamps commentedComment #39
adamps commentedComment #41
adamps commentedComment #43
adamps commentedComment #44
adamps commentedComment #46
adamps commentedComment #48
adamps commentedComment #49
adamps commentedOops all the patches so far are actually for #3332695: Model for confirmations is flawed, which is a blocker for this.
Comment #50
adamps commentedComment #51
adamps commentedComment #53
adamps commentedComment #55
adamps commentedComment #57
adamps commentedComment #59
adamps commented