I’ve recentely upgraded from 3.0.2 because messages were not being sent out in some very peculiar cases, for unknown reasons.
Upgrading to 3.2.4. only made things worse. Cannot send emails, cannot even login to my admin anymore, due to unrecognized pass. Regular phpmailer service is used to send messages and I don’t even get the password recovery email.
A fresh install of the same version of PHPList shows the same bugs.
PHP version used 5.4.30
Any advice is welcomed!
Have you restored the correct settings in your config/config.php file that you had in your 3.0.2 version?
Thanks a lot for your answer!
Yes, I have done everything - copying the basic info (from config file), then going back to the original config with more options (from the extended configuration file), checked the logs for emails being sent etc.
The fresh install did eventually start sending the emails - no idea how, or what I did exactely to make that happen. Then I went back to the upgrade installation, deleted all files and re-uploaded the files from the upgrading archive.
In the end, the upgraded instance also started sending out campaigns, but not the test messages. I saw some other users have seen this behavior. I’m monitoring the processes today to see how it goes with real emails, not just the test ones.
@ssg2014 You don’t need to do this but should use the same config file. This rules out any problems with incorrectly copying settings, and the only change is copying the phplist code.
If there are any new settings in the config file then you can apply those after the upgrade is working.
Thanks for the advice. That was actually the first thing I did (always do on PHPList upgrade) 
Still waiting for today’s newsletter to be sent out by the editors, to see if issue with sending persists. I’ll be sure to add here the results for future reference.
Unfortunately, bug persists. Campaign appears to have been sent, but no emails are sent, not stats are recorder. What should I do next?
Found the culprit: current version of PHPList does not allow any other user than SuperAdmin to process queue. So emails created by admins are only prepared but not sent out. Will set up a proper cron job.
Yes, seeing this months later so who knows if you will ever see this - curious to know what cron job you set up that did not infuriate your host admin?
I find it absolutely ridiculous that an admin of a list cannot actually process a job,
What has gone wrong w phpList developers?
This at the most complex should be config parameters.
Even if you declare an admin a superuser, the primary admin should still be able to lock down the permissions of the subordinate admins.
ie, I declare admin list1 as a supeeruser, but do not give them permissions to manage subscribers or change settings, that should be what the settings do.
Instead the superuser desination lets them do whatever?
What is the point of configurations if they do nothing but control batches and throttling…