kdatasystems

Thank you for your response. The erroneous query was the MySQL statement being created on line 64 of the “lib/mail_functions.php” file (plugin version 3.5.2). The original line was:

$query = "INSERT INTO $tableName (from,fromname,to,reply_to,subject,htmlbody,textbody,headers,attachimages,htmlenabled,email_type,delivery_type,meta_key,hash,sid) values ('$from','$fromname','$to','$reply_to','$subject','$htmlbody','$textbody','$headers','$attachImages','$htmlenabled','$email_type','$delivery_type','$meta_key','$hash','$sid');";

I updated the statement above to include “sent” and “date” values as discussed.

Hi Nodesman, I reviewed the issue I was experiencing a bit further and found that the “to” column error I suspected was only a MySQL warning and not a critical error causing the queue’s insert statement to fail. The insert statement was still failing however, but for another reason. I found that the “wpr_queue” insert statement found in “lib/mail_functions.php” (line 64 of plugin version 3.5.2) was not providing the “sent” and “date” column values during the SQL insert statement. These columns are configured in the database to not allow null values. A default value is also not set for the columns and so the “wpr_queue” insert statement was failing since they were not provided.

I am not sure if the “wpr_queue” table previously allowed null values for the “sent” and “date” columns, or if they contained a default field value originally, but during my testing they did not. Maybe something changed during the update process to MySQL 5.6 on my server, or maybe my previous MySQL 5.5 was allowing insert statements it should not have been.

To correct the problem I was experiencing, I updated the SQL insert statement on line 64 of the “lib/mail_functions.php” file and provided “sent” and “date” values. This corrected the problem and my queue is now processing and messages are flowing properly.

If you have questions, please let me know. Also, thank you for your great development!

Solution posted above.

I spent time today reviewing the version 5.3.7 source code and may have determined why my newsletters are being sent to all subscribers in the site, regardless of the newsletter they are subscribed to. In the “run_for_time” function of broadcast_processor.php, there is a SQL query fetching the newsletter and subscibers of the current broadcast being processed. The WHERE clause of the SQL query does not appear to limit the results to the current newsletter only. In the code I reviewed, the query returns the subscribers for all newsletters. As a potential solution, I added an additional filter to the WHERE clause to check that the newsletter ID is equal to the NID variable (‘newsletters’.’id’ = $nid). I tested a few broadcasts following the change I made and it appears to have corrected my problem. I posted my findings here in hopes that Rajasekharan may be able to confirm what I stumbled upon and suggest whether or not this is a valid solution.

Thank you for all your efforts and hard work Rajasekharan!

I’m not sure this will help solve the problem, but I thought I’d share that the revised HTML editor in version 5.3.5 does not appear to always work in Internet Explorer. It seems to always work fine in Google Chrome and Firefox however. Is this true for anyone else?

I am also experiencing this problem and wanted to note that the From email address of the broadcast sent out is not correct. In my case, it appears that the From address is always the value of the first newsletter I created, even when I am broadcasting another newsletter.

If there is any other information I can provide, please let me know.

Thank you in advance!