simplenews.module (line 1644)

    case 'subscribe':
      // Use formatted from address "name" <mail_address>
      $message['headers']['From'] = $params['from']['formatted'];

      $variables =  simplenews_mail_tokens($context['account'], $context, is_object($context['account']->language) ? $context['account']->language : language_default());
      $message['subject'] = _simplenews_subscription_confirmation_text('subscribe_subject', $context['account']->language, $variables);
      if (simplenews_user_is_subscribed($context['account']->mail, $context['newsletter']->tid)) {
        $message['body'] = _simplenews_subscription_confirmation_text('subscribe_subscribed', $context['account']->language, $variables);
      }
      else {
        $message['body'] = _simplenews_subscription_confirmation_text('subscribe_unsubscribed', $context['account']->language, $variables);
      }
      break;

Why then do not use 2 different keys: subscribe_subscribed and subscribe_unsubscribed?

A similar problem with unsubscribing.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

orb’s picture

fix patch

miro_dietiker’s picture

Version: 6.x-1.3 » 6.x-2.x-dev

I'm sorry we won't change the api in 6.x-1.x.

Instead of enforcing different mailkeys i would favor adding more context into message array.
The general event is subscribe (or unsubscribe), while the differentiation is a subcase.

miro_dietiker’s picture

Category: bug » feature

Also this is a feature request.

orb’s picture

This is a bug
1 mailkey = 1 e-mail

Problems connecting module works with mailkeys, they do not distinguish between different letters.

eg for multi-language needs a module http://drupal.org/project/mail_edit

miro_dietiker’s picture

I do not consider this a bug.

The mail_edit module is just limited to this case. Drupal core does never define this as a must.

Some parts of mails vary substates legitimately. We have many mails we create, that have internal segments with conditions.
You need to translate those segments separately (e.g. using translation interface).
Else one single mail with 4 if statements would then multiply to 4*4=16 possible mail combinations.

orb’s picture

OK
feature request +1

Simon Georges’s picture

Version: 6.x-2.x-dev » 7.x-1.x-dev

Moving all feature request to 7.x.

miro_dietiker’s picture

Status: Active » Postponed (maintainer needs more info)

There's still the decision open if
- The mailkey just defines the type of mail like "newsletter"
- The mailkey also contains the list which is the primary context "newsletter-CATEGORY12345"
(but here honestly, the key is by far not unique because every newsletter issue itself will be differen)
- The mailkey also contains node id (newsletter issue) like "newsletter-CATEGORY12345-NODE54321"

However, newsletter translations can be done with node/content translation. Also somethign like editing the context on a per-node level seems very strange to me.

Under the argument "because one key should be one kind-of-mail" (i changed orb's words a little) even pushing category ID into the key won't help a thing...
Note, newsletters are dynamically created thingies. Users enter data. They're not static content with a classical relation to a single code source like a user register confirmation mail that always contains the same content (plus some replacements).

I still vote strictly for more structural context in the mail options array.
I still feel, having one key that states "this is a simplenews newsletter issue being sent" seems right for me on this level.

drupalove’s picture

Version: 7.x-1.x-dev » 7.x-2.x-dev
FileSize
5.14 KB

I'm posting here believing this issue is close to mine as I couldn't find the information elsewhere.
Please confirm if I can send two emails (two nodes under the same term) to the same subscribers at the same time with this module. I already tried this, but for the past 2 days the second email shows it was sent to -2 subscribers! Picture attached. Thank you.