Thanks you.in my code - SugarBean.php, the second line was already commented out but not the first one. Now done.
I have looked through the emailman.php code to see if I can work out where the emails are getting stuck but I can’t fathom it out. I tried a couple of changes but they didn’t work. It has to be in there somewhere, as the entries sit perfectly in the queue but just won’t move.
Interestingly, last night, I happened to press the ‘send queued emails’ button, which I had done a number of times previously, and the 14 entries got sent. No idea why or how.
There is a relevant technical difference between the scheduler that sends Campaigns and your action pressing the “Send emails” button in the UI.
Each uses a separate PHP, the first is CLI and the second is web server. They use different php.ini, with different timezones, etc.
This might explain your problems.
If you’re into looking at code, let me paste my debug notes here for you. They are a bit cryptic but might be enough to serve as a map for you. This is basically what I write down whenever I have to understand how code flows happen, and go through the process with the debugger. It gets quite complex so having these notes helps me out whenever I have to look at it again.
Campaigns flows:
----------------------
Flow 1, sending already queued Campaigns ---------
cron.php
_addJobsHere.php
EmailManDelivery.php
Gathers rows from emailman, checks every campaigns related record, suppresseds, outbound email
Calls sendEmail from (custom)emailMan.php
tracker_urls
loops each email
Flow 2, sending from Wizard final step: ----------------
Button in modules/Campaigns/WizardMarketing.html
Calls js from jssource/src_files/modules/Campaigns/wizard.js
Into Campaigns controller in modules/Campaigns/views/view.classic.php
Handled in view, modules/Campaigns/WizardMarketingSave.php
Sets stuff like $_POST['mode'] = 'test';
Calls modules/Campaigns/QueueCampaign.php
Which inserts into emailman db table if queueing, then goes to campaign detail view
Or, for test, redirects to EmailManDelivery.php
Hope this helps.
If you haven’t done so already, set your log level to DEBUG, you will see more messages in the logs regarding the campaigns.
Brilliant, thank you. These are perfect. It is very slow going working through the constructs and various function calls etc… in code that has been developed over a few years.
I did press the send queued campaign emails button in the email queue in admin, which I didn’t articulate very well, so I think I was in the right place, but will get much further much faster with your notes.
I am not sure if I am on the right track but in terms of system behaviour, this seems to tally with what I have found.
Working through the code, it appears that Emailman takes the time from the database. I went in and checked in MySQL (SELECT NOW(); ) and the time and date was correct and in line with the server.
However, in the Apache PHP.ini file, the timezone is set to UTC, hard coded.
Everything was working fine until just over a week ago, when campaign emails started getting stuck in the e-mail queue. We don’t run cron through the Windows Scheduler, deliberately, as we have had instances of people moving companies and one instance where a user opted out but was not checked in the database so received another email. So we quickly do a visual check and then send manually, which works fine for us as these are small volumes- 10-20 usually.
Well, on the 26th March, the clocks went forward in the UK. It was after this that the ‘stuck in the queue’ issue began. UTC time is now 1hr behind the UK.
We had been clicking to send queued campaign emails in the queue virtually straight after they had been run, but they didn’t go out. They were eventually deleted by admin, probably before the hour had elapsed. We ran a campaign over the week-end and tried to send it - no joy, emails stuck. Clicked the button again this morning and they went straight out.
I can’t exactly see where this could be looping but we now seem to be able to control this just by observing the time difference. All user profiles are set to GMT+1 at the moment but I can’t see where that would make any difference.