I have three lists:

'it' with 2 subscribers
'en' with no subscribers
'nl' with no subscribers

All the lists are with Send rate set to "Custom" and "Custom send rate" set to 1.

When I create a new node for the term tied to the list with subscribers it send the email on a regulary basis of one every two sendings, and at the second submission it does not send the last published node but the first.

Real example:

1. creation of a new node (nid/54) with term "it" selected (the term for the list for which I wanna to trigger the newsletter send)

- table newsletter_newsletter:

| nnid | title | send_id | custom | ntid | subscribers_sent | clicks | opens | last_sent |
...........
| 21 | it | 13 | 0 | 4 | 0 | 0 | 0 | 0 |

- at the same time I puplish the above node in dblog I can find a "notice":
"2 Newsletter Lists failed to send because no subscribers found subscribed to them"

- no newsletter is sent

2. second creation of a new node (nid/55) with term "it" selected

- table newsletter_newsletter, the last inserted row is updated, no new rows are created:

| nnid | title | send_id | custom | ntid | subscribers_sent | clicks | opens | last_sent |
...........
| 21 | it | 13 | 0 | 4 | 2 | 0 | 0 | 1332402956 |

- at the same time I puplish the above node in dblog I can find two "notice":
"2 Newsletter Lists failed to send because no subscribers found subscribed to them"
"2 Newsletter Lists sent"

- a newsletter is sent, but with the node nid/54

and so it go on in an infinite cycle of one not sent and one sent. This behaviour is the same for dev and beta8.

CommentFileSizeAuthor
#2 newsletter-customrate1-1493832.patch740 bytesd.sibaud
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

ParisLiakos’s picture

Priority: Normal » Major

Seems major to me

d.sibaud’s picture

Assigned: Unassigned » d.sibaud
Status: Active » Needs review
FileSize
740 bytes

The function getQuery was checking for nodes created after the last newsletter sent, but if the custom rate is set to 1 the newsletter has to be sent in the same time the node is created. Tested and it works. This time I've attached a git produced patch.

ParisLiakos’s picture

Status: Needs review » Fixed

thanks, commited

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

r0bm1lls’s picture

I am still having this problem with the latest dev version. Tried applying the patch - seems it is already applied. ????
Applied patch to beta8 version of newsletter.automated.inc copied that into the dev version - still have problem. The most recent post never sends, only when another node is published does the previous one send when send rate is set to 1

d.sibaud’s picture

yes, the bug is not solved, it seems that the hook_node_save() is not committing the node to the db as said in the documentation before to call the hook_node_insert, because of this every time the query is executed it return the last but one node inserted and not the last one.
A fairly good explanation and maybe a solution is given in this post.

d.sibaud’s picture

Status: Closed (fixed) » Needs work

pardon, like I said the bug is not solved

d.sibaud’s picture

so the only way to send the last node inserted, regardless of every custom rate value, is manage the $node object returned from node_insert() checking if is it or not a node to be sent and aggregate it to the other ones got from the query, it's too hard for me, rootatwc can you manage it? :-)

r0bm1lls’s picture

So the only way for me now is to do manual sends. Pity.

ParisLiakos’s picture

@tourtools thanks for the analysis and explanation, really appreciate it.Will check and fix this once i find some time

d.sibaud’s picture

Assigned: d.sibaud » Unassigned

I toggle the assignment from myself, if you can do something is really appreciated :-)

springjazzy’s picture

That happens because table taxonomy_index doesn't contain record for inserted node yet. taxonomy_index rebuilds after newsletter do job on posting. Resolved by adding to newsletter module weight = 100, so that it does all job after all modules.

After applying that patch mails start to send, but there is one problem:

Consider two lists - tagA, tagB with custom send rate = 1.

Add tagA material - sends tagA
Add tagB material - sends tagB and TagA again

That happens because field sent_time in table newsletter_list equals created field in node. So the first time it null -> sends tagA node (equals to tagA created) -> sends tagB node (as it still equals and sql relation for finding proper materials is node.created >= newsletter_list.sent_time it sends again). The problem is in updating table newsletter_list.sent_time to REQUST_TIME that similar to node and newsletter_list. Resolved by addind +1 to REQUEST_TIME.

Hope it helps to publish stable version!

ParisLiakos’s picture

wow, springjazzy very analytical and helpful!
now we just need the patch:)

springjazzy’s picture

I'm noob here, so that patch - should I post it?

ParisLiakos’s picture

ah, np, i will do it

deggertsen’s picture

Did this ever get solved?

Kefyras’s picture

Yeah, the issue is still present. I can see that the implementation, suggested by Springjazzy, was done (module weight set to 100 ant REQUEST_TIME +1), but something is still wrong.
I have a very strange situation - when i create a content (from a content type, that has newsletter functionality (send it, right after it was created)) - it gets sent, normally. But after i create one more instance of content (of ANY content type, both with newsletter functionality and without), the last content that was already sent, is sent one more time and afterwards it just goes on and on
I noticed a few things :
1) if i start creating content of the same type - then it sends the one last instance of other content type that i used before and then stops sending them (starts sending only the normal content (if it has the functionality)) - so it seems like the these newsletters are in some sort of queue.
2) the earlier suggestion by Springjazzy, was implemented, but now the current version of this module doesn`t have the variables "sent_time" (i think it`s been replaced by "last_sent" and "created (node)" - this one, it seems, has been completely removed, since i can`t find it, neither in database, nor in code.

This is a rather difficult issue for me, so i would really appreciate if someone more experienced could help us out here.
Have a nice day !

Kefyras’s picture

Ok, i found out the problem - it`s because the field_send_to_subscribers_value table is being updated to 1, when instead it should be set to 0 (probably creation of node triggers this).
If i change the value of the previously created instance of content to 0 (in the same table), it doesn`t get sent when i create a new instance of content. Therefore, the problem is clear. Now i`ll just take a look at what exactly makes it happen so, and once i do, i`ll post a solution.

Kefyras’s picture

Assigned: Unassigned » Kefyras
Status: Needs work » Active
Kefyras’s picture

Update: The problem is with the "field_send_to_subscribers" - it`s a checkbox, that i have on certain content types, if i check it, the new node that i just created is sent, if it`s not checked - not sent.
And the problem is that after the node is created and newsletter sent, the checkbox stays checked, therefore, the "field_send_to_subscribers_value" is still at 1, hence, it is being sent after creating the next instance of content.
And it seems that the real problem is something else - Why the hell, does this module sends a correct node and then the previously created one ? i think the "getQuery" function has something to do with this, it might be the case, that an incorrect nid is being selected or something like that...
Still looking into it. If anyone could help me out here, i would really appreciate it.

Kefyras’s picture

Ok, so i found the solution, i just updated "field_send_to_subscribers_value" to 0 every time, the new node is inserted (hence, the checkbox is unset right after it is sent once), so here`s the code (newsletter.module)
Here`s how it looks now

function newsletter_node_insert($node) {
    $status = array();
    $custom_send_rate_lists = newsletter_custom_send_rate_lists();
foreach ($custom_send_rate_lists as $list) {
    $newsletter = newsletter_create($list->nlid);
    if ($newsletter->checkCustom()) {
      $status = array_merge($status, $newsletter->send());

$num_updated = db_update('field_data_field_send_to_subscribers')  //Updates only after the letter is sent once, as it should
  ->fields(array(
    'field_send_to_subscribers_value' => 0,
  ))
  ->condition('entity_id', $node->nid)
  ->execute();
    }
  }
  newsletter_feedback($status);
}

I don`t consider this a bug fix, since the value in database must be used for something else, but it is a workaround for now and it works perfectly for me, so use with caution. I hope this will be useful to you :)
I`ll mark it as "needs review", since it does.

Kefyras’s picture

Title: Custom send rate to 1 send 1 email every two » Custom send rate to 1 send 1 email every two (or second newsletter is being sent after any content is created)
Status: Active » Needs review