Implementing digest mode for D7

Within a few weeks, before the end of November, unless something goes very wrong.

Thank you for your offer to help. Subscriptions and Mail Editor definitely still need a lot of testing and feedback (positive feedback wouldn't hurt either, if something is actually found to work)...

There's no special problem with digest mode, it's just more work, and I haven't been able to get to it yet.

Ok, great. The D6 version won't give you much, if anything at all. The D6 digest code is mostly unchanged (i.e. broken by the porting of the surrounding code) still in the D7 _subscriptions_mail_cron() function. It needs to be cleaned up and brought to D7 (use the $data array, etc.), and we need new D7-specific functionality.

Here's my draft design off the top of my head:

1. We need a subscriptions_mail_digest template, including a preview feature showing the latest three nodes that are accessible to the current user.
2. For that template we need [subs:nodes] to return a 'list' so that we have access to the properties of the nodes for formatting the digest, e.g. to create a list of the subjects at the top of the digest.
3. Then we need to format each node with its corresponding template using mail_edit_format() with a context of 'DIGEST'. Like all tokens, the digest items should not be created until they are actually needed. We may be assembling a digest that shows only the subjects and links to the items on the site, so we may not need the formatted items at all. Also, it's unlikely that we'll need the formatted items more than once, so there's no need to cache them.
4. The result needs to be available during formatting of the digest either as [subs:nodes:?:formatted] (isolated strings) or [subs:nodes-formatted] (an 'array' of strings). I haven't quite made up my mind yet which one is preferable; maybe we can even provide both without too much overhead.
5. The formatted nodes need to be HTML, so that they can be passed through check_plain() to yield text.
6. I'm not sure whether we can use the normal result of mail_edit_format()ting (somewhat customizable through the 'DIGEST' context). This should probably be fine as a first step, but in the end we'll probably need to format the nodes using 'sanitize'=>FALSE, and sanitize them when they're retrieved as tokens.
7. Finally, we need a template that demonstrates some of the possibilities...

The digest functionality should go mostly (completely?) into subscriptions_mail.cron.inc.

I may well have missed something — if I did, then let's discuss it before you make a design decision (and waste implementation effort) that I may not agree with.

Please assign yourself if you do want to work on this.

I've just committed a first implementation of digest mode to the -dev version (give it up to 12h to be repackaged).

The updated templates need Mail Editor BETA2 — be sure to update Mail Editor!

I'd love to get some feedback before releasing BETA1...

I have installed the dev version.

I updated a blog post. Cron ran. There is a notification in watchdog of the notification sent to the user who has selected digest mode. There is another notification that subscriptions sent 0 single and 1 digest.

So, it appears that the only site member who got a notification is the one with the digest. None of the site members set to single mode got notified. The current situation on my site is that every member except for one have the Digest mode unchecked.

Additional information: the send interval for everybody is set to Daily. There was already one notification (actually I would have thought there would have been two, since I added two images) that was supposed to go out to everyone today (but it failed on account of the fact that the one member had Digest mode selected and was running the alpha version that does not support digest mode). I do see that according to the configurations page there are 11 active items in the queue. But, this is a strange number, since I've got 17 members on the site. Why would it not be 16 items in the queue? Things seem to be out of whack. The earlier notifications that were supposed to go out failed because of the one site member who had selected Digest mode. So, why did that site member still supposedly get the digest sent when the others did not get the single notification sent? I would expect that either everybody should have received the latest notification or nobody should receive it (if it is an issue with the Daily interval).

I set a member to receive notifications as soon as possible. I purged the queue. I updated a blog post. The configuration page said that there were 17 active items in the queue. I ran cron manually. There were no messages in the watchdog file. I revisited the configuration page and it says that there are 12 active items in the queue.

I have reverted to the alpha6 version, set the member with the Digest mode to not receive notifications, reset the member with the notify as soon as possible to receive Daily, and created another update. The configurations page says that there are 16 active and 1 suspended items in the queue. I will let cron run according to its normal schedule and see what happens tomorrow.

Thank you for the feedback. Having a send_interval > 1 adds an additional layer of complexity that makes it very difficult to speculate about what is happening. I'm not sure that changing the send_interval and clearing the queue will have the immediate effect that you expect.

Even trying to guess what the counts mean is difficult, unless you actually look at them and painfully evaluate them one by one. It seems that not all of your 17 members have a subscription of the type that would trigger on the update that you did, and some have more than one (which generates multiple entries in the queue, which still result in only one notification in the end).

None of what you report indicates a clear failure, or that the current -dev version would perform worse than the prior one did. Why did you revert to ALPHA6? In what way do you expect ALPHA6 to perform better than the current -dev version?

Setting back to NR to get more feedback, especially from sites which send asap. Obviously, digest mode will have to work with, say, daily intervals, but let's try to focus on getting it to work with 'at the next cron run' first (which is what send_interval = 1 means). If you have any send_interval > 1 then you must wait for at least twice the send_interval (and discard anything that happened during the first send_interval after you made any changes) before you draw any conclusions. It's not that notifications can get lost when changing the send_interval, but understanding at which point they're being sent when making changes is difficult.

Fixed in BETA1.