Mail templates

Subscriptions tries to give you the appropriate template. Rather than using the generic -nid template, it selects -type-blog for blog posts, but it uses the comment settings of the -nid template (only the -nid template has comment settings).

Good questions! See #210737: apply "type" template for "nid" subscriptions

Care to analyze the situation and provide a patch?

Yes, the thinking in #7 was that update notifications are more like new notifications than like comment notifications, and thus they should use the type-specific templates.

For example, if you've customized the blog template to show come CCK fields that you've added to your blog type, and you update a blog entry, then you'd want to get the blog format, so that you can see what was updated. On the sites that I run, I use !body in the type-specific templates.

OTOH, with single-node (node-nid) subscriptions, when comments are added, there's no need to send the full node again and again — what we really want to see is the comment, and that's what the node-nid template is for.

We could even argue that node-type should be converted to node-nid if it's just for comments...

P.S. "Subscribe to this page" gives you updates and/or comments, depending on the site/user/subscription setting.

I am simply lost as to how all the tokens work for subscriptions-digest (for example). I am trying to reformat the emails and don't understand how this works. I've read as much as I can and still cant seem to find any documentation as to the "proper syntax", if you will. Any help would be greatly appreciated. robert@robertnelsonvance.com

Please avoid topic drift. Let's discuss #254373: Syntax of the Mail Templates in another topic.

@mrtoner:

Okay, if the node-nid template is for comments and the body of node-nid is never used (because node-type is used instead), why not change the mailkey to node-comments and dump the body field? Of course, I could be the only person confused by a node-nid template that's not used to notify of changed nodes.

The node-nid body is used for notifications about comments. If the node is new or updated, then node-nid is converted into node-type, to give the recipient the benefits of the type-specific template. This is not necessary, if the node is unchanged and only comments were added.

This discussion has prompted to revisit my code and I found that new nodes weren't converted. New nodes can trigger notifications if auto-subscribe is enabled. This is fixed in 5.x-2.x-dev.

I'd like to note that when I commented on an article, instead of the body from node-nid being used for the comments, the body from node-type-article was used.

What type of subscription was it that triggered the notification?

#11: Yes, you're confirming that it's working as designed. If a content type is unlisted, then normal users will never get a notification that has the format of that type.

Subscriptions is not a trivial module and there's quite a bit of logic under the hood. If you want a description of each and every detail of the inner workings, then read the source code. It's THE description of each and every detail of the inner workings. But, while we're at it, and before you come up with the next special case of the special case: there's the 'subscribe to all content types' permission, which allows those that have it to also subscribe to unlisted content types, but they won't get their node/nids converted to unlisted content types; IMO, if they're using a generally available mechanism, they should receive the same results as the general user. The special permission makes additional functionality available, but it does not change generally available functionality.

When this thread ends, you should have a pretty good picture of what templates are used in which cases. Maybe you'd like to write a small section for the README.txt file that would contain all the information that you would have liked to have from the beginning?

What type of subscription was it that triggered the notification?

It was a content-type subscription, on updates and on comments. From your previous (quoted) comment, I thought that the node-nid body would be used for this notification.

No. Converting node/nid to node/type in the case of updates (and now also in the case of new nodes) is the only kind of conversion that I ever mentioned. There's no conversion the other way. IOW, non-node/nid subscriptions use their native mail template, enhanced with the comment part of node/nid if they have comments. If they're unlisted, then the node/type is not available to general users, and it's never converted to.

When I asked what the node-nid body was used for (since node-nid wasn't used if it was converted), you said it was used for comments. That's not always true.

I stand by my statement in #9. Converting non-node/nid subscriptions to node/nid subscriptions is your invention, not mine. In fact #5 made it pretty clear that this is not done.

the module needs to be implemented and documented in such a way that a non-programmer end-user can install and use it with a minimum of effort.

I agree, and this thread shows that it's difficult for me to supply this information in that very form and detail that would suit you — that's why I'm asking you to put together a section for the README.txt file as you would like to find it there. Many others didn't need this, but I'm sure there will be more like you who will appreciate having it.

Yes, 1. and 2., but only for "subscribe to this page" (aka node/nid) subscriptions. "Type" subscriptions, "taxonomy" subscriptions, and all the other subscriptions types use their own body template all of the time, enhanced with the node/nid comment template for comments.

I never indicated that I thought there was a conversion the other way

Then why do you expect to get a node/nid template from a node/type subscription???

Either there's a conversion, or you get what you asked for (node/type if you ask for node/type, for example)— I don't see a third way, and I don't understand why you won't understand...

There's one and exactly one conversion being done: node/nid to node/type (if the type is available), for "new" and "update" notifications. Period. Aside of that you get what you ask for. This seems pretty simple and straight-forward. Why won't you accept it?

P.S. The code is

          if ($module == 'node' && $field == 'nid' 
               && (!empty($object->_is_updated) || !empty($object->_is_new)) 
               && user_access('subscribe to content types', $user)) {
            $unlisteds = variable_get('subscriptions_unlisted_content_types', array());
            if (isset($object->type) && !in_array($object->type, $unlisteds)) {
              $field = 'type';
              $value = $object->type;
            }
          }

Sigh... I've been debating whether I should write a long post and try to roll all this up again, but I don't have time for this... sorry....

Your insisting to start from the templates and work your way backwards is, er, backwards. You're probably close, except you're probably missing some "some" and "all" qualifiers in various places. Also, there are a few other permissions involved, too.

What you're doing is taking the result, 42, and asking for all possible calculations, circumstances, and conditions that could give 42 — there's no answer to that question.

I cant get the mail templates to apply at all, I have edited every one of them. What is the trick here, I am getting the generic email for every type of notification.

Thanks

Did you upgrade from Subscriptions 1.x-dev? If so, then please go to #261002: Upgrade from 1.x-dev: the 2.0 mail templates aren't used.