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.