Notifications sometimes Blank

MedMan - I am starting to see the same problem on a test site running Drupal 6. I'll keep you posted.

R,
Coby

MedMan,
It looks like the problem may be in how tokens are being processed in our particular setup. If you go to

Admin>>Messaging & Notifications>>Messaging Templates>>Notifications for node comments

Change the token in the body from [comment-body] to [comment-body-raw] does that fix your problem?

Please only try that on your test site where you can trust the input as raw will not apply your filter settings.

Also, this only occurs for me when there is a comment posted to the site via email (using mail2web), which then triggers the notification event and a message is sent back out about the new comment. This is all happening on the same cron run so I am suspecting something is colliding as comments are saved and notifications about same are sent back out.

I am using the simple messaging module and working in organic groups. I also have a few patches applied, so will need to go back and take some notes on the exact config.

For now try changing that token and see what happens.

R,
Coby

MedMan,
In my case it looks like it was a collision of input filters.

Here's the life cycle of a post created via the web with a comment reply via email
1)new post via web
2)post saved - filter->Filtered HTML - set as default filter
3)notification event triggered by new post
3a)message is sent - filter->Plain text - set in Messaging Settings
4)email received by subscribers
5)email reply by whatever email client
6)email reply fetched by mailhandler - plain text mime part - set in mailhandler mailbox settings
6a)message is saved as comment - filter->Markdown* - set in mailhandler mailbox settings
7)notification event triggered by new comment
8)message is sent filter->Plain text - set in Messaging Settings
9)email received by subscribers
10)repeat

And it could be more involved if the life cycle starts as a new post via email.

In the end it looks like some of the filter settings I had at different spots were conflicting. As you can see, depending on your setup, HTML or Plain Text, you may need to test until you can get it working. Sorry I do not have a more definitive answer, but the different possibilities between installs is staggering.

*Note - I am testing the Markdown filter in my install, which is not a core filter.

R,
Coby

I am also having this problem (on two sites, one using notifications 5.x-1.2 and one using 6.x-1.0). At first my case was the same as described above with the n/a problem only happening when the reply came in by email, but in the drupal 6 site I'm not using mail2web anymore and it just happened again. The drupal 6 site is an upgrade from the drupal 5 site, so maybe something is held over but mail2web is disabled for the drupal 6 site now.

I couple weeks ago I tracked down where this was in the code but I can't for the life of me find it again. It looked like it was something to do with input format and a check to see if there were proper permissions to use them. I'll keep looking for that and post back.

I have not seen an n/a since I got my filters sorted out.

I am using Markdown on the incoming emails; filtered html as a site default filter; and Reverse Markdown on outgoing emails.

I hacked together the Reverse Markdown filter for my use case. It's what I would call beta quality and you can find it here: http://github.com/cglusky/revmd/tree/master

I am NOT supporting HTML email either coming in or going out because it causes too many issues for me to consider it worth the effort. Markdown gives a bit of formatting support and keeps things simple(er). And it works with mobiles.

R,
Coby

This might be a Messaging issue. If it is I would love to write it up as an issue there, but I don't know exactly what the issue is. If anyone has any thoughts about how to translate this into a Messaging bug report I'd be happy to do it.

I found the place in the code where I thought the n/a was coming from and it's in the function check_markup() in filters.module.

If this test fails: if (isset($text) && (!$check || filter_access($format))) it return n/a.

I'm not sure if this is where it's coming from but messaging.module calls it here:

function messaging_text_render($text, $glue = '', $filter = NULL) {
  $output = '';

  if (is_array($text)) {
    if (isset($text['#prefix'])) {
      $output .= $text['#prefix'].$glue;
      unset($text['#prefix']);
    }
    if (isset($text['#text'])) {
      $output .= $text['#text'];
      return $output;
    }
    foreach (element_children($text) as $key) {
      // The filter is not passed along
      $text[$key] = messaging_text_render($text[$key], $glue);
    }
    $output .= implode($glue, $text);
  } else {
    $output .= $text;
  }
  // The filter is applied now only once
  if ($filter) {
    $output = check_markup($output, $filter, FALSE);
  }
  return $output;
}

Could something about that recursive calling of the function have something to do with colliding of filters mentioned above?

I believe this is related to the filers and some edge cases. While the filters seemed like a good idea, the amount of additional configuration combined with some regexes that were not that great seems to have led to several similar issues. I've removed the filters, and instead there is a kill switch to turn on/off message cleaning. Message cleaning is now handled by a single regex that appears to work in most cases, but it may not in all. I will provide more details in the release notes for the next versions which will be released at the end of the week. If the regex proves problematic, it can be toggled off with a setting and there's the option to now implement hook_mail2web_alter which will let you, among other things, implement your own message cleaning technique.

Success at last!

The newly uploaded version (feb 1 2009) didn't solve the n/a problem for me.

However, sagannotcarl's comment led me to the right fix by drawing my attention to the check_markup function.

For me, the problem wasn't the messaging module's call to check_markup (which properly passes FALSE as the third argument, so an access check is not called), but instead the call to check_markup in token's comment_token_values function, which does instruct check_markup to verify the user's permission to the filter being called.

Since mail is sent via the cron job, it is run as the anonymous user. I solved the problem by providing anonymous access to the filter being used.

That's fantastic, setting my notification template to use comment-body-raw fixed it for me.

This way I don't have to give anonymous users access to this random input format.

Thanks jmcclelland.
Colin

Switch to mailcomment project. Mail2web is now known as "mailcomment" due to a trademark issue with the name mail2web.