Bug in Newsletter_panel infusion solved
Asked Modified Viewed 7,868 times
asked
Scope:
You installed the infusion newsletter_panel version 1.2 or 1.6.
When you try to send out the newsletter you get this error:
The problem in a nut shell:
The problem is that the table that holds the subscriptions contain "dead links", i.e. references to users that don't exist anymore.
This happens when a user that has subscribed to the newsletter is deleted WITHOUT unsubscribing to the newsletter first.
This is very much likely to happen, because the administrator must remember to delete the subscription in the infusion BEFORE deleting the user, and this could easily be forgotten.
The subscription table is called fusion_newsletter_subs, and it has only two fields:
newsletter_sub_id: Sequence number (autoincrement)
newsletter_sub_user: Reference to table fusion_users; field user_id
Example:
Fusion_newsletter_subs:
Sub_id sub_user
1 ------- 31
2 ------- 43
3 ------- 25 <----
4 ------- 18
Let's assume that for sub_id = 3 there is a problem because someone deleted the user with user_id 25 from table fusion_users, WITHOUT removing the subscription.!
So, his subscribtion still exists as post3 in Fusion_newsletter_subs, causing the sendout of the newsletter to fail.
There are several options for how to solve the problem:
1.
Change members.php, so that when a user is deleted the reference in fusion_newsletter_subs is deleted too. However, this will cause that it's no longer an infusion, but a MOD.
2.
Change newsletter_admin.php to cope with "dead refs" so it doesn't fail when the newsletter is sent out.
Pure symptom treatment. I don't like it at all!
3.
Make a "clean-up" php to be called from newsletter_subs.php.
4.
Changenewsletter_subs.php, so that you may see and delete the dead refs.
I choose solution 3 because newsletter_subs.php actualy shows the dead ref from fusion_newsletter_subs and you may also click "Delete" to get rid of it.
The delete function however contains an error.
When this is solved, dead refs appear as blank subscriptions at the top of the list and can easily be removed.
Problem is that the LEFT JOIN that fills the workspace does not take the reference from table fusion_newsletter_subs but instead uses the empty value from fusion_users-user_id.
Empty because a LEFT JOIN leaves empty fields in case no related record is found in the joined table.
So, I corrected the SELECT to add an extra field to the workspace; fusion_newsletter_subs-newsletter_sub_user, and use this as reference when a subscription must be deleted.
The correction in newsletter_subs.php:
Insert with red:
Replace orange by red:
I attached the complete corrected infusion
You installed the infusion newsletter_panel version 1.2 or 1.6.
When you try to send out the newsletter you get this error:
Code Download source
[center]The Newsletter could not be sent.
Please ensure sendmail is configured correctly.[/center]The problem in a nut shell:
The problem is that the table that holds the subscriptions contain "dead links", i.e. references to users that don't exist anymore.
This happens when a user that has subscribed to the newsletter is deleted WITHOUT unsubscribing to the newsletter first.
This is very much likely to happen, because the administrator must remember to delete the subscription in the infusion BEFORE deleting the user, and this could easily be forgotten.
The subscription table is called fusion_newsletter_subs, and it has only two fields:
newsletter_sub_id: Sequence number (autoincrement)
newsletter_sub_user: Reference to table fusion_users; field user_id
Example:
Fusion_newsletter_subs:
Sub_id sub_user
1 ------- 31
2 ------- 43
3 ------- 25 <----
4 ------- 18
Let's assume that for sub_id = 3 there is a problem because someone deleted the user with user_id 25 from table fusion_users, WITHOUT removing the subscription.!
So, his subscribtion still exists as post3 in Fusion_newsletter_subs, causing the sendout of the newsletter to fail.
There are several options for how to solve the problem:
1.
Change members.php, so that when a user is deleted the reference in fusion_newsletter_subs is deleted too. However, this will cause that it's no longer an infusion, but a MOD.
2.
Change newsletter_admin.php to cope with "dead refs" so it doesn't fail when the newsletter is sent out.
Pure symptom treatment. I don't like it at all!
3.
Make a "clean-up" php to be called from newsletter_subs.php.
4.
Changenewsletter_subs.php, so that you may see and delete the dead refs.
I choose solution 3 because newsletter_subs.php actualy shows the dead ref from fusion_newsletter_subs and you may also click "Delete" to get rid of it.
The delete function however contains an error.
When this is solved, dead refs appear as blank subscriptions at the top of the list and can easily be removed.
Problem is that the LEFT JOIN that fills the workspace does not take the reference from table fusion_newsletter_subs but instead uses the empty value from fusion_users-user_id.
Empty because a LEFT JOIN leaves empty fields in case no related record is found in the joined table.
So, I corrected the SELECT to add an extra field to the workspace; fusion_newsletter_subs-newsletter_sub_user, and use this as reference when a subscription must be deleted.
The correction in newsletter_subs.php:
Insert with red:
Code Download source
$result = dbquery(
"SELECT [color=red]newsletter_sub_user, [/color]tns.*, tu.user_id,user_name,user_email FROM ".$db_prefix."newsletter_subs tns
LEFT JOIN ".$db_prefix."users tu ON tns.newsletter_sub_user=tu.user_id".$orderby
);
$rows = dbrows($result);
if (!isset($rowstart)) $rowstart = 0;
$result = dbquery(
"SELECT [color=red]newsletter_sub_user, [/color]tns.*, tu.user_id,user_name,user_email FROM ".$db_prefix."newsletter_subs tns
LEFT JOIN ".$db_prefix."users tu ON tns.newsletter_sub_user=tu.user_id
".$orderby."ORDER BY user_name LIMIT $rowstart,20"
);
Replace orange by red:
Code Download source
</tr>\n";
while ($data = dbarray($result)) {
echo "<tr>\n<td><a href='".BASEDIR."profile.php?lookup=".$data['user_id']."'>".$data['user_name']."</a></td>
<td align='right'><a href='".FUSION_SELF."?step=delete&rowstart=$rowstart&user_id=
".$data['[color=orange]user_id[/color]']."' onclick='return
DeleteMember()'>".$locale['nl402']."</a></td>
</tr>\n";Code Download source
</tr>\n";
while ($data = dbarray($result)) {
echo "<tr>\n<td><a href='".BASEDIR."profile.php?lookup=".$data['user_id']."'>".$data['user_name']."</a></td>
<td align='right'><a href='".FUSION_SELF."?step=delete&rowstart=$rowstart&user_id=
".$data['[color=red]newsletter_sub_user[/color]']."' onclick='return
DeleteMember()'>".$locale['nl402']."</a></td>
</tr>\n";I attached the complete corrected infusion
Edited by Yxos on 23-12-2006 13:07,
answered
answered
Yea, there was a naming problem...
The infusion is usable now and I think it ought to qualify for a "version 1.7", maybe along with a correction as per my solution 2 in the initial description. The send out should never fail, not even if dead refs exists.
Hope digi will do this now that I took the time to describe the problem B)
The infusion is usable now and I think it ought to qualify for a "version 1.7", maybe along with a correction as per my solution 2 in the initial description. The send out should never fail, not even if dead refs exists.
Hope digi will do this now that I took the time to describe the problem B)
answered
is this error why i with user_id 1 get the same mail 4 times ?
answered
Nope!
If you do, I suggest you either find a thread about that problem, or start a new thread in which you carefully describe the problem.
Feel free to post a link to the (new) thread in this one
If you do, I suggest you either find a thread about that problem, or start a new thread in which you carefully describe the problem.
Feel free to post a link to the (new) thread in this one
— 28 days later —
answered
Thank you, Yxos! This was haunting me.
answered
I spoke too soon. I have replaced all of the infusion files, but am still getting the same error.
I checked my fusion_newsletter_subs table and saw that it contained one row with a user that no longer existed in my fusions_users table.
I deleted this user from the Newsletter, using the Newsletter infusion's admin panel. This did NOT remove the user from the fusion_newsletter_subs table. So I removed it "manually" using my database admin tool.
At this point, I don't understand why it's not working. When I try to send a newsletter, I get the same error:
The Newsletter could not be sent.
Please ensure sendmail is configured correctly.
Another possible issue with the upgrade: When I unsubscribe or resubscribe to the newsletter using the newsletter panel (the user-facing panel), I now see the ID of the user in the panel, below the subscribe/unsubscribe button.
Thanks in advance for any help.
I checked my fusion_newsletter_subs table and saw that it contained one row with a user that no longer existed in my fusions_users table.
I deleted this user from the Newsletter, using the Newsletter infusion's admin panel. This did NOT remove the user from the fusion_newsletter_subs table. So I removed it "manually" using my database admin tool.
At this point, I don't understand why it's not working. When I try to send a newsletter, I get the same error:
The Newsletter could not be sent.
Please ensure sendmail is configured correctly.
Another possible issue with the upgrade: When I unsubscribe or resubscribe to the newsletter using the newsletter panel (the user-facing panel), I now see the ID of the user in the panel, below the subscribe/unsubscribe button.
Thanks in advance for any help.
— 1 month later —
answered
I can not get the Newsletter to work. I
Warning: fsockopen() [function.fsockopen]: unable to connect to smtp.pzshow.com:25 (Connection refused)
m getting this,....
The Newsletter could not be sent.
Please ensure sendmail is configured correctly.
And im geting this.....Warning: fsockopen() [function.fsockopen]: unable to connect to smtp.pzshow.com:25 (Connection refused)
— 11 months later —
answered
Russian locale
— 1 year later —
answered
Sorry for reopening this post, although I'm actually only posting the solution I've found after hours of scratching my head this morning.
I found that dead references was not my problem, neither was invalid email adresses among subscribers (as suggestion in another post).
Sending newsletters to many subscribers returned the error quoted above, though I could send to myself only or up to at least three people.
At last, One.com told me that the site email should be an email on the site domain. I suppose this has something to do with the use of BCC in the newsletter. I've always used my own email addresse as site email, but changing this to for example my-name@my-domain.com made it work brillliantly.
So there are several solutions to this nut! ;)
I found that dead references was not my problem, neither was invalid email adresses among subscribers (as suggestion in another post).
Sending newsletters to many subscribers returned the error quoted above, though I could send to myself only or up to at least three people.
At last, One.com told me that the site email should be an email on the site domain. I suppose this has something to do with the use of BCC in the newsletter. I've always used my own email addresse as site email, but changing this to for example my-name@my-domain.com made it work brillliantly.
So there are several solutions to this nut! ;)
Category Forum
Bugs and Errors - 6Labels
None yet
Statistics
- Views 0 views
- Posts 9 posts
- Votes 0 votes
- Topic users 7 members
0 participants
Notifications
Track thread
You are not receiving notifications from this thread.
Related Questions