Hi, I think, the best entry point to implement a function to send the latest newsletter to a new subscriber automatically is in the file /lists/index.php in the function confirmPage($id) between lines 503 and 504 (before the return $res;).

Right after the confirmation of the newsletter subscription the latest newsletter should be sent out in the next processqueue cycle.

Currently I'm searching for the function to resend a specified message. Maybe anyone has the exact file name and line number of this function? I get lost with that huge amount of different, undocumented scripts.

ThanX, Foxpower

Last edited by Foxpower on 10:14pm, Thu 17 Aug, 2006, edited 1 time in total.

Here's a solution for the problem / feature request that works for me (phplist 2.10.2).
I use only one list, so I assume that the actual newsletter to send has the highest id in the table - ah, and it can only be a record, that has a embargo date in the past. If you use more lists in your phplist installation, then you have to refine the sql query. OK, let's start (we're working on the file /lists/index.php):

Search for line 501 ($res .= $html;) and insert after that the following six lines:

No, you don't need to set up a cron job, it works also with the manual process queue in the admin backend, but the process queue has to be activated via cron or backend link either. The latest newsletter is only marked for re-sending.

I'm quite new to phplist, but would really like to be able to use this functionality. However, I have a number of lists, and I'm trying to work out what the sql query would be.

Has anyone done this, or do I need to spend some time analysing the database to work out how to get the latest message for the lists the user has subscribed to? Looking at the number of relations in the database makes me think this will be quite complex.

In the short term, I'll work around it by only sending to one list, so the message will be the latest for the list I want users to subscribe to - but it would be so useful to get it work for multiple lists.

So here is a good start with the query for MULTIPLE LISTS. I am using my table names here but in the actual index.php file we would need to use the proper table variables [message] and (i think) [listmessage]. [LISTID] represents the id of the list the user would subscribe to.

myopenbar - have you got anywhere with this? I've been looking at the code, but don't have enough of an understanding of how phplist is constucted to work out how to implement this query - nor do I really have a phplist dev environment.

I'm surprised that there is not more demand for this - as it seems an obvious enhancement.

When more than one person subscribes to the list, and then they CONFIRM there subscription, the first person to do so will get the extra message:

You will revcieve in a few minutes a copy of our latest newsletter

But everybody else who CONFIRMS there subscription does not receive this message.

As soon as the Queue is processed though, then the first person to confirm (after the queue is procesed) gets the extra message again (You will revcieve in a few minutes a copy of our latest newsletter), but nobody else gets it.

Everybody gets a copy of the newsletter though. The actual sending out of the last newsletter is working fine, it's just the message they receive upon confirmation that only shows up to the first person.

It's not really a big issue. The feature works great (once I figured the Cron job thing out), and everybody who signs up gets the last newsletter no problem. It's just that only the first person to confirm after the last queue process gets the little extra reminder message.

Looks like the latest version 2.10.4 is different because the cant find the line of code mentioned above. I agree this should be built in to the features because it is a very obvious thing to be able to keep new users up to speed with the latest news. Then everyone gets something straight away.

(1) The message "You will receive in a few minutes a copy of our latest newsletter" only appears to the FIRST person that confirms their subscription since the last time the queue was processed. This is because the code checks to see if there was a "success" at changing the status to "submitted". When a second (or third, etc) person confirms their subscription, since the status was already changed by the last person that confirmed their subscription, it does not change the staus again, and therefore the "success" fails, and it does not display that part of the message. This will continue until the queue is processed, at which time the status will changed from "submitted" back to "sent", and then the first person to confirm will receive the message, but nobody else.
Here is my solution to this problem... I simply commented out the "if ($success)" part, by putting a # in front of it.

#if ($success) $res .= "You will receive in a few minutes a copy of our latest newsletter.<br>";

(2) The second bug has to do with the Message ID Number that it picks. It chooses the HIGHEST id, which should correspond to the most recent message that you sent, but the problem comes along when you DRAFT a new message. Since the drafted message now has a higher message id (since it's newer) than the last message that was sent out, this is the id that it picks. The good news is that it does not appear to send out this draft message because the process queue seems to recognize it as a draft (probably because it has not been assigned to a list yet), but the bad news is that it does not send anything at all, so all those people that were supposed to get your last newsletter didn't get anything. The other good news is that it (somewhere) keeps track of these people that were supposed to get the last newsletter, so when you make the fix, it should send them something.Remember that this works only if you have ONE list, so I'm not sure how to fix this (or if it is even a problem) for the hack with mulitple lists.

Another possible solution is if you want to always send the SAME newsletter/message to new subscribers, and not the newest one. In this case, you simply need to find the Message ID of the message you want them to get, and change the WHERE portion of the line to id=xx where the xx is the message id number (I used 48 in my example).Change the code above to this:

"...the problem comes along when you DRAFT a new message. Since the drafted message now has a higher message id (since it's newer) than the last message that was sent out, this is the id that it picks..."

You can avoid this problem as long as you do NOT assign your draft to a list! You can draft it and save it as often as you like, and then the very last step you should do just before you send it, is click on the LISTS tab and assign it to a list(s).

If you assign it to a list, while you are still in the draft stage, then your draft copy is what will get sent out as the most recent newsletter to everybody who confirms their subscription.

I got this working with multiple mailing lists. Really, the way I did it is probably the more correct way even for just one mailing list. in the confirmPage function in index.php, we are already getting information about each list the user is subscribed to and looping through the list to show them the list information. So in that loop, I added another query to requeue the most recently sent message. So, two modifications need to be made.

1) In the query where the lists are retrieved, we need to get the list id. For me, that is on line 535, but here is the original query: