Newsletter sent twice

Posted: Thu Aug 25, 2005 9:19 am

My newsletter module once worked just fine. But the last few times I've sent out a newsletter (600+ subscribed members) people have been getting duplicates. Not only that, but the newsletter sent function doesn't completely finish and I get a server error message instead of getting back to nuke with the display "Newsletter sent."

So, the newsletter does get sent, but it gets sent twice.

Any idea what's up with that?

On this site I'm still using 6.9. I've had a look at the admin/modules/newsletter.php file and I can't see anything wrong.

Anyone with any idea of what might be causing it?

Posted: Thu Aug 25, 2005 10:19 pm

Hhhhmmm.... I know why you are getting a server error (a PHP script time-out -- set to stop run-away processes from chewing up the server), but not sure why getting duplicates. Are there any other mail/sendmail errors anywhere? You may want to ask your server hosting company to look at the mail error logs if you do not have access to them.

Does it happen every time, consistently?

Posted: Fri Aug 26, 2005 9:44 am

Thanks for the advice. I've just contacted my host with some questions, so we will see what happens.
It didn't always send dupes .. and yes, it now consistently sends dupes. Very odd.

Posted: Fri Aug 26, 2005 5:57 pm

Ok. Now that it is consistently sending dups, that sure sounds like it could be a code problem OR an infrastructure change (wow, that really helps! Laughing

). Anything that you can point to that has changed recently code-wise, .htaccess (rewrite?), server?

Is there anything that could be submitting the script twice? Might try adding a small bit of code to write out to a logfile date/time and either user_name or email address and submit it again and see if the script itself is somehow getting submitted twice or the logic itself has gotten screwed up....

Do you know if it is EVERY user that is getting two? Can you somehow pinpoint to the data?

montego

Posted: Sat Oct 08, 2005 12:39 am

CodyG,

Did you ever get this issue resolved?

Regards,
montego

Posted: Sat Oct 08, 2005 7:07 am

I haven't got this issue resolved yet and my host seems to be ignoring my request to check things on their end, so I'm back to assuming it's my script too. Besides, other domains on the same server are not having this issue, but they have way smaller user populations.

I'm running nuke ver 6.9 on this particular site. The admin/modules/newsletter.php file looks ok, no double functions or anything. The newsletter gets sent, but the admin page never automatically refreshes, eventually it just hangs with a dns error.

However, there is this one bit of the code that I wonder about. As the problem began somewhere around our 500th user (I now have 720) ... but this looks like it's just the bit that tells me I'm sending the message to many users, so I don't know if it relates to anything and I remain confuddled.

Code:

 if (($type == "newsletter") AND ($srow > 500)) {


        CloseTable();


        echo "<br>";


        OpenTable();


        echo "<center><i>"._MANYUSERSNOTE."</i></center>";


    } elseif (($type == "massmail") AND ($urow > 500)) {


        CloseTable();


        echo "<br>";


        OpenTable();


        echo "<center><i>"._MANYUSERSNOTE."</i></center>";


    }


    CloseTable();


    include("footer.php");

Any further clues would be great, including any code that I might apply to test this. My users have complained about the dupes, but not that loudly.

I'm also working at trying to give this site an upgrade and hoping the issue will go away when that happens.

Posted: Sat Oct 08, 2005 7:20 am

CodyG,

That bit of code would not cause duplicate emails, in fact, it would stop the script from running after 500 had been sent (but I can't tell for certain due to not being able to see more of the code).

I'll PM you with my email address and if you could send me all the files under your /admin/modules/newsletter.php I'll take a look at it.

Regards,
montego

Posted: Sat Oct 08, 2005 9:36 am

I would agree.
That snippet seems to prevent sending if the email list is greater than 500 - presumably in an attempt to halt the process before the server gets bogged down.

I am suprised that out of 720 members, over 500 have elected to subscribe to the newsletter - but that might be just my own site users not bothering to select the option lol.

As always when it comes to sending such large numbers of emails, I always recomend a third party script like WorldCast which will send mail via your ISP - this is much fairer for others using a shared hosting environment.

Is there no option to send you newsletters via smtp instead of php mail?

Could there be any java s cript anywhere (header/footer etc) which might be trying to refresh the page - this might possibly cause the double sending.

Posted: Sat Oct 08, 2005 6:07 pm

CodyG,

Thanks for the code. I too can find nothing wrong with the code. The code snipet you provided is in the check_type() function and is not restricting anything, just displaying the preview page with a message at the bottom letting the admin know that the newsletter or mass mail is going to go to more than 500 users.

Have you checked how long the script runs before error'ing out? My guess is it is around 5 minutes, but can be less if your web hosting company sets the php time-out parameter to a lower number. This setting is to help reduce the risk of having a run-away PHP process consume all the server's resources. This usually returns some type of time-out message / PHP error.

I think there are two time-out type settings at work here. There is a webserver Timeout parameter and a php.ini level max_execution_time setting. You can try to increase the timeout time for PHP (if PHP is not running in "safe mode"). Figure out how much time before the error and then try adding the command ini_set('max_execution_time', '300'), where the '300' is the number of seconds. Change your value of this to one or two minutes above where it is currently timing out. So, it might look something like this:

Code:




function newsletter_send($title, $content) {


    global $user_prefix, $sitename, $dbi, $nukeurl, $adminmail;





    ini_set('max_execution_time', '300');





    $from = $adminmail;


    $subject = "[$sitename Newsletter]: ".stripslashes($title)."";


    $content = stripslashes($content);


    $content = "$sitename "._NEWSLETTER."\n\n\n$content\n\n- $sitename "._STAFF."\n\n\n\n\n\n"._NLUNSUBSCRIBE."";


    $result = sql_query("select user_email from ".$user_prefix."_users where newsletter='1'", $dbi);


    while(list($user_email) = sql_fetch_row($result, $dbi)) {


        mail($user_email, $subject, $content, "From: $from\nX-Mailer: PHP/" . phpversion());


    }


    Header("Location: admin.php?op=newsletter_sent");


}

If you get a message saying this cannot be set, then you have to go to your host (I don't even think an .htaccess directive will help).

If you still timeout in roughly the same amount of time, it is probably the web server timing you out.

Now, why the duplicate emails? Nothing in the code looks like its possible to create. The only thing I can think of is you either have duplicate email addresses in your user table (very doubtful) or once the timeout occurs, I wonder if your web server tries once to re-submit the script with the same post variables. I have never heard of this, but do not have a lot of experience with different web servers. Bottom line is the code looks good to me too.

It would be helpful to find out if truelly ALL 700+ users are getting your newsletters and if so, are they ALL getting duplicates. Also, if not all are getting a newsletter, how many are and then within that group, how many are getting duplicates?

Sorry that I did not have the answer.... only more questions to try and dig for clues. Any other ideas out there?????

Regards,
montego

Posted: Sat Oct 08, 2005 7:39 pm

Yeah, you could try an alternative newsletter module like the one at [ Only registered users can see links on this board! Get registered or login! ] - at least that would quickly pinpoint whether it is a timeout issue.