Answers.Body: <p>If the mail never went out, it's likely that there's a crash occurring during the sending of the mail.  This can be particularly difficult to track down, but there is often an entry in your PHP log (or WP debug log, if it's enabled).  More rarely, there's an entry in the CiviCRM &quot;ConfigAndLog&quot; log.</p>
  <p>If you have Smarty processing for CiviMail enabled, you may want to disable it to see if the problem persists - the most common cause I've seen for a crash here is that there's malformed Smarty in an email.</p>
  <p>Another cause I've seen is an unusual SMTP response from the server - though in your case we can rule that out.</p>
  <p>Some more info to help with troubleshooting:</p>
  <ul>
  <li>Does the problem occur on a very simple test message?</li>
  <li>If you find PHP errors in the log, please share.</li>
  </ul>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2023-06-28T21:15:41.037Z
Answers.Text: Another cause - not relevant in your case - is a mismatch of PHP versions or modules between command-line and web-based PHP.  For instance, a password encrypted with `libsodium` won't work if you don't have libsodium present in your command-line PHP.
Answers.UserDisplayName: Jon G - Megaphone Tech
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2023-06-29T23:15:16.017Z
Answers.Text: Thanks, that's helpful. Yes, the problem occurs with a very simple test, but you've made me wonder if the unsubscribe link is triggering it somehow. There are no relevant errors that I can see in any log including the PHP log or the browser console. If I get a chance I'll enable more debug logging but I don't want to disrupt a production site and also I'm travelling and not sure how much internet access I will have for the next few days.
Answers.UserDisplayName: Phil McKerracher
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2023-10-07T14:28:06.250Z
Answers.Text: Picking this up again because it's still a problem and I have some PHP errors to report.
  2023-10-07 15:22:44.774502 [NOTICE] [3336769] [2a00:23c4:80aa:9901:6d1d:6953:a92e:8aa2:55029:HTTP2-273#beechesit] [STDERR] PHP Warning:  Undefined array key "campaign" in /home/beechesit/public_html/wp-content/uploads/civicrm/templates_c/en_GB/%%CA/CA3/CA322A60%%Report.tpl.php on line 147
Answers.UserDisplayName: Phil McKerracher
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2023-10-07T14:32:07.393Z
Answers.Text: Also possibly relevant:
  
  Clicking the "report" link on a simple test mailing shows
  
  Status: Scheduled
  
  Even though the time is in the past and a manually triggered "Send Scheduled Mailings" job has reported success.
  
  This looks like a problem with the scheduling system.
Answers.UserDisplayName: Phil McKerracher
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2023-10-07T15:00:48.803Z
Answers.Text: Update regarding Smarty: I don't use any smarty tokens in the test emails, but I couldn't find a way to disable Smarty processing completely. Is that even possible?
Answers.UserDisplayName: Phil McKerracher
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2023-10-07T15:08:38.503Z
Answers.Text: Update: Just to be clear about the "undefined array key warnings" in the debug log - there are a lot of them (more than 100 with each mailing attempt) - I couldn't fit them in the comment above or find a way to add an attachment. They only showed up when I changed the PHP debug filter to "Notice". As far as I can tell they wouldn't be expected to cause this particular problem and there's no easy way to fix them.
Answers.UserDisplayName: Phil McKerracher
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2023-10-07T16:16:36.767Z
Answers.Text: The undefined array key warnings seem irrelevant.  Do you have `define( 'CIVICRM_MAIL_SMARTY', 1 );` in your `civicrm.settings.php`?
Answers.UserDisplayName: Jon G - Megaphone Tech
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2023-10-07T17:41:31.420Z
Answers.Text: Ah, there it is. No, it's set to zero.
  if (!defined('CIVICRM_MAIL_SMARTY')) {
    define( 'CIVICRM_MAIL_SMARTY', 0 );
  }
Answers.UserDisplayName: Phil McKerracher
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2023-10-10T01:36:58.000Z
Answers.Text: OK - I'm not sure how to resolve this best without either a) running a debugger or b) installing and delivering to a local mail host (like Postfix). Sorry I can't be more helpful.
Answers.UserDisplayName: Jon G - Megaphone Tech
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2023-10-10T12:56:47.950Z
Answers.Text: Thanks for your help, Jon G. I do already have Postfix installed, and other CiviCRM instances on the same server delivering mailings successfully using it. Sorry if that wasn't clear.
Answers.UserDisplayName: Phil McKerracher
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2023-10-10T19:46:34.277Z
Answers.Text: Ah - well that's helpful to know.  Are there *any* logs in Postfix, or does the mail never reach Postfix?  Assuming it never reaches Postfix, I think you'll need to run a debugger to see the problem.  However - the one reason I've seen that causes no PHP errors to be written is if you have an out-of-memory error.  And mailing generation takes up more RAM than most Civi operations.  So...how are you triggering cron?  If you're using the CLI, does the CLI have a memory limit?  If so, what happens if you remove it?
Answers.UserDisplayName: Jon G - Megaphone Tech
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2023-10-10T20:20:41.267Z
Answers.Text: There's nothing at all in Postfix (postfix/smtp activity in /var/log/mail.log) as far as I can tell. 
  
  I'm prepared to run a debugger if necessary but it's a couple of days' work  to set up a staging site etc, and I'm not familiar with the environment and the code. Is there a guide somewhere to help?
  
  Cron is triggered from the "wp" command:
  
  /usr/local/bin/wp  --user="civicrm" --url=https://www.beeches.it --path=/home/beechesit/public_html civicrm api job.execute auth=0 >/dev/null
  
  Triggering the scheduled job manually shows the same symptoms.
  
  The PHP memory limit is 512MB.
Answers.UserDisplayName: Phil McKerracher
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2023-10-10T20:48:28.477Z
Answers.Text: 512MB is a lot - but if you set mem_limit to -1, does the problem resolve?  Does removing the redirect to `/dev/null` show anything?  Does adding `debug=1` after `auth=0` yield anything?  You'll need to remove `/dev/null` to check obviously.  You might also want to call `job.process_mailing` instead of `job.execute` to reduce the amount of code you're looking at.
Answers.UserDisplayName: Jon G - Megaphone Tech
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2023-10-11T00:34:11.787Z
Answers.Text: This is all I see with debug=1 and no /dev/null:
  
  Array
  (
      [is_error] => 0
      [undefined_fields] => Array
          (
              [0] => auth
          )
  
      [version] => 3
      [count] => 1
      [values] => 1
      [xdebug] => Array
          (
          )
  
  )
Answers.UserDisplayName: Phil McKerracher
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2023-10-11T00:44:41.970Z
Answers.Text: With not debug=1 but also no /dev/null I see this:
  
  Array
  (
      [is_error] => 0
      [version] => 3
      [count] => 1
      [values] => 1
  )
Answers.UserDisplayName: Phil McKerracher
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2023-10-11T00:45:14.780Z
Answers.Text: No difference with memory_limit = -1
Answers.UserDisplayName: Phil McKerracher
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2023-06-28T21:13:40.323Z
Answers.LastActivityDate: 2023-06-28T21:13:40.323Z
Answers.UserDisplayName: Jon G - Megaphone Tech
Body: <p>Group emails from one of my CiviCRM installations are not being delivered (ever), which has caused some embarrassment. Messages can be composed as usual, but are never scheduled and there's no &quot;runner&quot; display. Pausing and restarting the mailing results in the status changing from &quot;Scheduled&quot; to &quot;Running&quot; and clicking &quot;Report&quot; shows the expected number of intended recipients but the &quot;Successful Deliveries&quot; count is always zero. In case it's relevant, I did notice that the option to send &quot;immediately&quot; is not selected by default (which I think it always is on sites that work), but it can be selected manually.</p>
  <p>Obviously, I have enabled the &quot;Send Scheduled Mailings&quot; job and tried triggering that both manually and from a cron job. The log shows success but with a count of zero.</p>
  <p>I have also tried obvious things like disabling all extensions, resetting caches and paths, comparing all settings with other installations that do work, searching the forums, bug reports and so on. I've checked that outgoing mail is configured correctly and I can send test emails. There's nothing in the error logs. Nothing makes any difference, it seems to be a bug.</p>
  <p>The problem is reproducible in the sense that it's not intermittent, but I haven't been able to reproduce it on a clean installation.</p>
  <p>I'd be prepared to move everything to a new installation to work around this but it's a heavily used instance with lots of contacts, invoices and so on and I know of no way to export all those and reimport them later to a working instance. Everything else seems to be working as usual.</p>
  <p>Reproduction steps</p>
  <ul>
  <li>Create a group containing some test contacts.</li>
  <li>Go to <strong>Mailing &gt; New Mailing</strong> and compose a test message, with the group from the previous step selected as Recipients.</li>
  <li>Click <strong>Send test</strong> and check that a test message is correctly delivered.</li>
  <li>Click <strong>Next</strong> then select <strong>Immediately</strong> or a date and time 5 minutes in the future.</li>
  <li>Click <strong>Submit Mailing</strong>.</li>
  <li>Wait for cron to run or go to <strong>System Settings &gt; Scheduled Jobs</strong> and trigger <strong>Send Scheduled Mailings</strong>. Check that the result is success.</li>
  <li>Check that the message is now in <strong>Mailing &gt; Scheduled and Sent Mailings</strong>. Click <strong>Report</strong>. Observe that <strong>Intended recipients</strong> is not zero but <strong>Successful deliveries</strong> is always zero.</li>
  </ul>
  <p><strong>Current behaviour</strong></p>
  <p>Nothing happens. No messages delivered, nothing in error logs.</p>
  <p><strong>Expected behaviour</strong></p>
  <p>Messages are sent once the scheduled job is triggered, perhaps with a batch limit. Eventually the whole job completes and the status changes to &quot;Completed&quot;.</p>
  <p><strong>Environment information</strong></p>
  <p>Browser: <em>Chrome 114.0.5735.135</em>
  CiviCRM: <em>Master/5.62.1</em>
  PHP: <em>8.1</em>
  CMS: <em>WordPress 6.2.2 running on Ubuntu 22.04</em>
  Database: <em>MariaDB 10.6.12</em>
  Web Server: <em>OpenLiteSpeed 1.7.17</em></p>
  <p><strong>Updates</strong></p>
  <p>The mailing report shows &quot;Status: Scheduled&quot; even though the schedule is in the past and a manual &quot;Send Scheduled Mailings&quot; job has been triggered and reports success. This looks like a scheduling issue.</p>
  <p>Having turned on &quot;NOTICE&quot; PHP debugging I see dozens of &quot;Undefined array key&quot; warnings. As far as I can tell they shouldn't be causing this problem and there's no easy way to fix them, but here are the first few examples in case it's relevant:</p>
  <p>2023-10-07 15:22:44.774502 [NOTICE] [3336769] [2a00:23c4:80aa:9901:6d1d:6953:a92e:8aa2:55029:HTTP2-273#beechesit] [STDERR] PHP Warning:  Undefined array key &quot;campaign&quot; in /home/beechesit/public_html/wp-content/uploads/civicrm/templates_c/en_GB/%%CA/CA3/CA322A60%%Report.tpl.php on line 147</p>
  <p>Another update in case it's relevant: I moved the installation to a new server and now I'm seeing these errors when running the CiviCRM cron job:</p>
  <p>PHP Warning:  Undefined property: CRM_Core_DAO::$mailing_id in /home/beechesit/public_html/wp-content/plugins/civicrm/civicrm/CRM/Mailing/Event/BAO/MailingEventQueue.php on line 41</p>
  <p>Another update in case it's relevant - the &quot;Notes&quot; tab has disappeared from all my contacts.</p>
  <p>I'm trying to move everything to a fresh installation but it's a very complicated process! In particular, it's hard to match contributions to contacts and a lot of information is not exportable and is being lost, for example creation dates. This has become a disaster :-(</p>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2023-06-28T20:22:56.133Z
Comments.Text: Update: Outgoing mail is currently set to use /usr/sbin/sendmail (which in turn uses PostFix, I believe). I do have access to the mail logs but there's nothing relevant - no outgoing mail attempt (the dog that didn't bark!), except when I use "Send Test" in CiviCRM, which is fine. I don't think it's a problem with the mail infrastructure because of that, and also because moving the whole (WordPress) site to a new server hasn't helped. The other "working instances" I mentioned are also on the same VPS, which rules out a lot of possibilities.
Comments.UserDisplayName: Phil McKerracher
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2023-06-29T23:40:39.627Z
Comments.Text: In case it helps, this is the log message after the sheduled job is triggered manually.
  
      Finished execution of Send Scheduled Mailings with result: Success (a:1:{s:9:"processed";i:0;})
Comments.UserDisplayName: Phil McKerracher
Tags: <mailing><failure>
Title: Mailing never starts - is this a bug?
ThreadText: # Mailing never starts - is this a bug?
  
  (Asked by: username_0 on 2023-06-28)
  
  Group emails from one of my CiviCRM installations are not being delivered (ever), which has caused some embarrassment. Messages can be composed as usual, but are never scheduled and there's no "runner" display. Pausing and restarting the mailing results in the status changing from "Scheduled" to "Running" and clicking "Report" shows the expected number of intended recipients but the "Successful Deliveries" count is always zero. In case it's relevant, I did notice that the option to send "immediately" is not selected by default (which I think it always is on sites that work), but it can be selected manually.
  
  Obviously, I have enabled the "Send Scheduled Mailings" job and tried triggering that both manually and from a cron job. The log shows success but with a count of zero.
  
  I have also tried obvious things like disabling all extensions, resetting caches and paths, comparing all settings with other installations that do work, searching the forums, bug reports and so on. I've checked that outgoing mail is configured correctly and I can send test emails. There's nothing in the error logs. Nothing makes any difference, it seems to be a bug.
  
  The problem is reproducible in the sense that it's not intermittent, but I haven't been able to reproduce it on a clean installation.
  
  I'd be prepared to move everything to a new installation to work around this but it's a heavily used instance with lots of contacts, invoices and so on and I know of no way to export all those and reimport them later to a working instance. Everything else seems to be working as usual.
  
  Reproduction steps
  
  * Create a group containing some test contacts.
  * Go to **Mailing > New Mailing** and compose a test message, with the group from the previous step selected as Recipients.
  * Click **Send test** and check that a test message is correctly delivered.
  * Click **Next** then select **Immediately** or a date and time 5 minutes in the future.
  * Click **Submit Mailing**.
  * Wait for cron to run or go to **System Settings > Scheduled Jobs** and trigger **Send Scheduled Mailings**. Check that the result is success.
  * Check that the message is now in **Mailing > Scheduled and Sent Mailings**. Click **Report**. Observe that **Intended recipients** is not zero but **Successful deliveries** is always zero.
  
  **Current behaviour**
  
  Nothing happens. No messages delivered, nothing in error logs.
  
  **Expected behaviour**
  
  Messages are sent once the scheduled job is triggered, perhaps with a batch limit. Eventually the whole job completes and the status changes to "Completed".
  
  **Environment information**
  
  Browser: *Chrome 114.0.5735.135*
  CiviCRM: *Master/5.62.1*
  PHP: *8.1*
  CMS: *WordPress 6.2.2 running on Ubuntu 22.04*
  Database: *MariaDB 10.6.12*
  Web Server: *OpenLiteSpeed 1.7.17*
  
  **Updates**
  
  The mailing report shows "Status: Scheduled" even though the schedule is in the past and a manual "Send Scheduled Mailings" job has been triggered and reports success. This looks like a scheduling issue.
  
  Having turned on "NOTICE" PHP debugging I see dozens of "Undefined array key" warnings. As far as I can tell they shouldn't be causing this problem and there's no easy way to fix them, but here are the first few examples in case it's relevant:
  
  2023-10-07 15:22:44.774502 [NOTICE] [3336769] [2a00:23c4:80aa:9901:6d1d:6953:a92e:8aa2:55029:HTTP2-273#beechesit] [STDERR] PHP Warning: Undefined array key "campaign" in /home/beechesit/public\_html/wp-content/uploads/civicrm/templates\_c/en\_GB/%%CA/CA3/CA322A60%%Report.tpl.php on line 147
  
  Another update in case it's relevant: I moved the installation to a new server and now I'm seeing these errors when running the CiviCRM cron job:
  
  PHP Warning: Undefined property: CRM\_Core\_DAO::$mailing\_id in /home/beechesit/public\_html/wp-content/plugins/civicrm/civicrm/CRM/Mailing/Event/BAO/MailingEventQueue.php on line 41
  
  Another update in case it's relevant - the "Notes" tab has disappeared from all my contacts.
  
  I'm trying to move everything to a fresh installation but it's a very complicated process! In particular, it's hard to match contributions to contacts and a lot of information is not exportable and is being lost, for example creation dates. This has become a disaster :-(
  
  **Tags:** mailing, failure
  
  > **Comments:**
  > **username_0**: Update: Outgoing mail is currently set to use /usr/sbin/sendmail (which in turn uses PostFix, I believe). I do have access to the mail logs but there's nothing relevant - no outgoing mail attempt (the dog that didn't bark!), except when I use "Send Test" in CiviCRM, which is fine. I don't think it's a problem with the mail infrastructure because of that, and also because moving the whole (WordPress) site to a new server hasn't helped. The other "working instances" I mentioned are also on the same VPS, which rules out a lot of possibilities.  
  > **username_0**: In case it helps, this is the log message after the sheduled job is triggered manually.      Finished execution of Send Scheduled Mailings with result: Success (a:1:{s:9:"processed";i:0;})  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2023-06-28. Score: 1
  
  If the mail never went out, it's likely that there's a crash occurring during the sending of the mail. This can be particularly difficult to track down, but there is often an entry in your PHP log (or WP debug log, if it's enabled). More rarely, there's an entry in the CiviCRM "ConfigAndLog" log.
  
  If you have Smarty processing for CiviMail enabled, you may want to disable it to see if the problem persists - the most common cause I've seen for a crash here is that there's malformed Smarty in an email.
  
  Another cause I've seen is an unusual SMTP response from the server - though in your case we can rule that out.
  
  Some more info to help with troubleshooting:
  
  * Does the problem occur on a very simple test message?
  * If you find PHP errors in the log, please share.
  
  > **Comments:**
  > **username_1**: Another cause - not relevant in your case - is a mismatch of PHP versions or modules between command-line and web-based PHP.  For instance, a password encrypted with `libsodium` won't work if you don't have libsodium present in your command-line PHP.  
  > **username_0**: Thanks, that's helpful. Yes, the problem occurs with a very simple test, but you've made me wonder if the unsubscribe link is triggering it somehow. There are no relevant errors that I can see in any log including the PHP log or the browser console. If I get a chance I'll enable more debug logging but I don't want to disrupt a production site and also I'm travelling and not sure how much internet access I will have for the next few days.  
  > **username_0**: Picking this up again because it's still a problem and I have some PHP errors to report. 2023-10-07 15:22:44.774502 [NOTICE] [3336769] [2a00:23c4:80aa:9901:6d1d:6953:a92e:8aa2:55029:HTTP2-273#beechesit] [STDERR] PHP Warning:  Undefined array key "campaign" in /home/beechesit/public_html/wp-content/uploads/civicrm/templates_c/en_GB/%%CA/CA3/CA322A60%%Report.tpl.php on line 147  
  > **username_0**: Also possibly relevant:  Clicking the "report" link on a simple test mailing shows  Status: Scheduled  Even though the time is in the past and a manually triggered "Send Scheduled Mailings" job has reported success.  This looks like a problem with the scheduling system.  
  > **username_0**: Update regarding Smarty: I don't use any smarty tokens in the test emails, but I couldn't find a way to disable Smarty processing completely. Is that even possible?  
  > **username_0**: Update: Just to be clear about the "undefined array key warnings" in the debug log - there are a lot of them (more than 100 with each mailing attempt) - I couldn't fit them in the comment above or find a way to add an attachment. They only showed up when I changed the PHP debug filter to "Notice". As far as I can tell they wouldn't be expected to cause this particular problem and there's no easy way to fix them.  
  > **username_1**: The undefined array key warnings seem irrelevant.  Do you have `define( 'CIVICRM_MAIL_SMARTY', 1 );` in your `civicrm.settings.php`?  
  > **username_0**: Ah, there it is. No, it's set to zero. if (!defined('CIVICRM_MAIL_SMARTY')) {   define( 'CIVICRM_MAIL_SMARTY', 0 ); }  
  > **username_1**: OK - I'm not sure how to resolve this best without either a) running a debugger or b) installing and delivering to a local mail host (like Postfix). Sorry I can't be more helpful.  
  > **username_0**: Thanks for your help, Jon G. I do already have Postfix installed, and other CiviCRM instances on the same server delivering mailings successfully using it. Sorry if that wasn't clear.  
  > **username_1**: Ah - well that's helpful to know.  Are there *any* logs in Postfix, or does the mail never reach Postfix?  Assuming it never reaches Postfix, I think you'll need to run a debugger to see the problem.  However - the one reason I've seen that causes no PHP errors to be written is if you have an out-of-memory error.  And mailing generation takes up more RAM than most Civi operations.  So...how are you triggering cron?  If you're using the CLI, does the CLI have a memory limit?  If so, what happens if you remove it?  
  > **username_0**: There's nothing at all in Postfix (postfix/smtp activity in /var/log/mail.log) as far as I can tell.   I'm prepared to run a debugger if necessary but it's a couple of days' work  to set up a staging site etc, and I'm not familiar with the environment and the code. Is there a guide somewhere to help?  Cron is triggered from the "wp" command:  /usr/local/bin/wp  --user="civicrm" --url=https://www.beeches.it --path=/home/beechesit/public_html civicrm api job.execute auth=0 >/dev/null  Triggering the scheduled job manually shows the same symptoms.  The PHP memory limit is 512MB.  
  > **username_1**: 512MB is a lot - but if you set mem_limit to -1, does the problem resolve?  Does removing the redirect to `/dev/null` show anything?  Does adding `debug=1` after `auth=0` yield anything?  You'll need to remove `/dev/null` to check obviously.  You might also want to call `job.process_mailing` instead of `job.execute` to reduce the amount of code you're looking at.  
  > **username_0**: This is all I see with debug=1 and no /dev/null:  Array (     [is_error] => 0     [undefined_fields] => Array         (             [0] => auth         )      [version] => 3     [count] => 1     [values] => 1     [xdebug] => Array         (         )  )  
  > **username_0**: With not debug=1 but also no /dev/null I see this:  Array (     [is_error] => 0     [version] => 3     [count] => 1     [values] => 1 )  
  > **username_0**: No difference with memory_limit = -1  
  
  ---
  
  