Provide option to send a newsletter even if no associated nodes are available

hmm interesting.havent though about this usecase.

well if you want your newsletter to be automated, eg being sent on daily/weekly/monthly basis the only workaround for now would be to just select some/or all your taxonomy terms,so that it can find nodes,even though they will not be sent.

i will turn this into a feature request,just to remember that i must expose an option to send the newsletter even when no nodes found.

Thanks!

weird..if there is a post that got sent before the last newsletter of this list, it should find it....well a quick and dirty way is to set its last_sent value in the database to NULL,but if it keeps not finding any nodes for these terms,even there are newly created terms that belong there,then we have a bug....and you will have to reset to NULL each time

here is the sql :

UPDATE newsletter_list SET last_sent = NULL WHERE nlid = <the newsletter id of your list here> ;

ah nice,didnt know you know coding:)
in that case:

got to newsletter.mail.inc line 107 and see if it gets correct the tids of this template..then its the query that runs to find out if there is any node published for these tids.

so right before return if you do dpm($query->execute()) you will see the results and the query that run (you need devel module for dpm function)

hmmm seems dpm wont run since it is inside the cron run,thats why you den get results:)
use die(var_dump($query->execute())); instead,so you get the results no matter what:) ah, you should use <pre> tags to make it more readable..eg :

echo '<pre>'; die(var_dump($query->execute()));

I needed this today, so I coded a patch. It includes a new database column and a form element (plus, of course, the requisite check in the code). Here it is. It's against version 7.x-1.0-beta6, though.

thanks for the patch!

but why this?:

-    WHERE send_again = CURDATE()
+    WHERE send_again <= CURDATE()

I just saw this now (ironically, while debugging a newsletter issue for the same client I wrote the patch for).

Here's the rationale for the <= CURDATE() change as far as I remember it from February: in the original code, if send_again comes and goes without (for whatever reason) cron running (e.g. server downtime, migration, messed up system time, etc), the newsletter isn't sent at all and you have to wait till the next period. With the <= in place, if send_again is in the past, the newsletter will be sent. Under normal circumstances, send_again is either today or in the future, so this doesn't break anything.

Uh sorry...i forgot about this issue..and tbh i found out myself that <= is needed...
i dont think this is complete yet..we need to get views to know about these field as well...setting it to needs review to trigger the tests

Also the default value in this form is wrong:

--- a/includes/newsletter.admin.inc
+++ b/includes/newsletter.admin.inc
@@ -745,6 +745,11 @@ function newsletter_list_edit($form, &$form_state, $list) {
     '#default_value' => check_plain($list->send_rate),
     '#title' => t('Send rate'),
   );
+  $form['always_send'] = array(
+    '#type' => 'checkbox',
+    '#default_value' => FALSE,
+    '#title' => t('Send newsletter even if there are no nodes to list.'),
+  );

you have to use '#default_value' => check_plain($list->always_send),

I added this comment to another thread (is #12 the solution?):
I manually applied the patch to the beta 9 code. It appears to be working. Always send works correctly but when I edit the list (after previously checking the box) the checkbox isn't checked anymore. With my very limited PHP knowledge I don't know how to get this to work.

Patricia, that's what #12 meant. To keep the checkbox checked, you need to change this line: //'#default_value' => FALSE,// to this line: //'#default_value' => check_plain($list->always_send),//

#11 seems to work correctly. Should be commited IMO.

Reviewed, This module needs an option of send custom content without the necesity of look for taxonomies of nodes. So I think this is a priority.

patch does not apply and #12 needs to be fixed

Any update on this issue please?

Thanks

Could really use this patch.. Im using the views also.

On this issue's subject, how about letting other modules provide their own classes (i.e. extending NewsletterBasic, like NewsletterAutomated does) ?

For ex. by introducing a new hook in newsletter.module - function newsletter_create(), like :

/**
 * Instantiates a new Newsletter class
 * according to http://drupal.org/node/608152.
 *
 * @return
 *   A newsletter object.
 */
function newsletter_create($nlid = NULL, $ntid = NULL, $nnid = NULL) {
  // Allow other modules to implement custom newsletter classes.
  $custom_candidates = array();
  foreach (module_implements('newsletter_create') as $module) {
    $n = module_invoke($module, 'newsletter_create', $nlid, $ntid, $nnid);
    if (!empty($n)) {
      $custom_candidates[] = $n;
    }
  }
  // If there are several candidate implementations, the last takes priority.
  if (!empty($custom_candidates)) {
    $newsletter = array_pop($custom_candidates);
  }
  elseif (isset($ntid)) {
    $newsletter = new NewsletterCustom($nlid, $ntid, $nnid);
  }
  elseif (isset($nlid) && !isset($ntid)) {
    $newsletter = new NewsletterAutomated($nlid);
  }
  else {
    $newsletter = new NewsletterBasic();
  }
  return (object) $newsletter;
}

Then in another module :

/**
 * Implements hook_newsletter_create().
 */
function mycustmod_newsletter_create($nlid, $ntid, $nnid) {
  // Here could go some (optional) selection code, then :
  return new FooNewsletterAutomated($nlid);
}

class FooNewsletterAutomated extends NewsletterBasic {
  // ex: Adapt class NewsletterAutomated contents to your needs.
}