Tracking works on manual sends; but doesn't using cron job sends

My Mautic version is: Latest 4.1
My PHP version is: 7.4.24
My Database type and version is: 5.7.34

My problem is:
If I manually send out segment emails, open and link tracking works great. If I used cron jobs to send, open and link tracking doesn’t work properly, only registering a handful of opens and clicks (when there are hundreds of opens and dozens of clicks.

I originally had this problem with automated campaigns and was able to fix it by disabling tracking in Postmark, my SMTP service. But now that I’ve setup crons to send segment/broadcast emails out, I’m having the same issue (even with Postmark’s tracking disabled).

Why on earth would tracking work when emails are manually sent, but then NOT work then they are triggered by a cron?

Steps I have tried to fix the problem: I tried setting email sending to “send immediately” and “queue,” same results. Sending worked great using either, but tracking was borked if sent via cron.

I also tried embedding the tracking pixel using the token {tracking_pixel}. Same results. Tried disabling the “add tracking pixel” and then adding the token into the email, same results.

Totally stumped why this messes up tracking. Any thoughts or suggestion?

Chris Blair

May I suggest posting your logs? Its difficult to troubleshoot based on narrative alone.

Are the emails actually sending? Anything in your mautic/Var/spool directory?
In the past I’ve gotten 404 errors upon clicking a link because of mautic/var/log permissions errors, and this messed up my open/tracking results.

When you opening the tracking pixel from an email - are you getting a 404 error?

Logs posted below from last 2 days (when issue was occurring) and so far today. Emails are all sending fine regardless of method used (manual send or by cron and with either “send immediately” or “queue” selected).

No 404 errors that I’m detecting anywhere. How do I find and open the tracking pixel from the email? I’m was using Mautic’s automatic embed function for it. I also tried inserting the tracking pixel token with and without the “automatically add the tracking pixel” selected.

I’ve disabled all tracking in Postmark so that should’ve eliminated any conflict with that.

[2021-10-10 23:46:51] mautic.NOTICE: PHP Notice - SessionHandler::gc(): ps_files_cleanup_dir: opendir(/var/lib/php/sessions) failed: Permission denied (13) - in file /home/91427-72367.cloudwaysapps.com/synpghdgkd/public_html/vendor/symfony/http-foundation/Session/Storage/Handler/StrictSessionHandler.php - at line 106 {“maxlifetime”:1440}

[2021-10-11 02:43:20] mautic.NOTICE: PHP Notice - SessionHandler::gc(): ps_files_cleanup_dir: opendir(/var/lib/php/sessions) failed: Permission denied (13) - in file /home/91427-72367.cloudwaysapps.com/synpghdgkd/public_html/vendor/symfony/http-foundation/Session/Storage/Handler/StrictSessionHandler.php - at line 106 {“maxlifetime”:1440}
[2021-10-11 14:25:55] mautic.NOTICE: PHP Notice - SessionHandler::gc(): ps_files_cleanup_dir: opendir(/var/lib/php/sessions) failed: Permission denied (13) - in file /home/91427-72367.cloudwaysapps.com/synpghdgkd/public_html/vendor/symfony/http-foundation/Session/Storage/Handler/StrictSessionHandler.php - at line 106 {“maxlifetime”:1440}
[2021-10-11 15:32:36] mautic.NOTICE: PHP Notice - SessionHandler::gc(): ps_files_cleanup_dir: opendir(/var/lib/php/sessions) failed: Permission denied (13) - in file /home/91427-72367.cloudwaysapps.com/synpghdgkd/public_html/vendor/symfony/http-foundation/Session/Storage/Handler/StrictSessionHandler.php - at line 106 {“maxlifetime”:1440}
[2021-10-11 19:47:01] mautic.NOTICE: PHP Notice - SessionHandler::gc(): ps_files_cleanup_dir: opendir(/var/lib/php/sessions) failed: Permission denied (13) - in file /home/91427-72367.cloudwaysapps.com/synpghdgkd/public_html/vendor/symfony/http-foundation/Session/Storage/Handler/StrictSessionHandler.php - at line 106 {“maxlifetime”:1440}

[2021-10-12 03:42:02] mautic.NOTICE: PHP Notice - SessionHandler::gc(): ps_files_cleanup_dir: opendir(/var/lib/php/sessions) failed: Permission denied (13) - in file /home/91427-72367.cloudwaysapps.com/synpghdgkd/public_html/vendor/symfony/http-foundation/Session/Storage/Handler/StrictSessionHandler.php - at line 106 {“maxlifetime”:1440}
[2021-10-12 15:24:15] mautic.NOTICE: PHP Notice - Undefined index: ct - in file /home/91427-72367.cloudwaysapps.com/synpghdgkd/public_html/app/bundles/PageBundle/Controller/PublicController.php - at line 456 {“redirectId”:“b9068440ba517f3c4d6e01a57”,“logger”:"[object] (Symfony\Bridge\Monolog\Logger: {})",“redirectModel”:"[object] (Mautic\PageBundle\Model\RedirectModel: {})",“redirect”:"[object] (Mautic\PageBundle\Entity\Redirect: Mautic\PageBundle\Entity\Redirect with ID #107)",“url”:"{contactfield=url_link_for_email}",“query”:}
[2021-10-12 17:58:01] mautic.NOTICE: PHP Notice - Undefined index: ct - in file /home/91427-72367.cloudwaysapps.com/synpghdgkd/public_html/app/bundles/PageBundle/Controller/PublicController.php - at line 456 {“redirectId”:“b9068440ba517f3c4d6e01a57”,“logger”:"[object] (Symfony\Bridge\Monolog\Logger: {})",“redirectModel”:"[object] (Mautic\PageBundle\Model\RedirectModel: {})",“redirect”:"[object] (Mautic\PageBundle\Entity\Redirect: Mautic\PageBundle\Entity\Redirect with ID #107)",“url”:"{contactfield=url_link_for_email}",“query”:}
[2021-10-12 17:58:04] mautic.NOTICE: PHP Notice - Undefined index: ct - in file /home/91427-72367.cloudwaysapps.com/synpghdgkd/public_html/app/bundles/PageBundle/Controller/PublicController.php - at line 456 {“redirectId”:“b9068440ba517f3c4d6e01a57”,“logger”:"[object] (Symfony\Bridge\Monolog\Logger: {})",“redirectModel”:"[object] (Mautic\PageBundle\Model\RedirectModel: {})",“redirect”:"[object] (Mautic\PageBundle\Entity\Redirect: Mautic\PageBundle\Entity\Redirect with ID #107)",“url”:"{contactfield=url_link_for_email}",“query”:}

No error when opening the tracking pixel, although Gmail seems to do some weird stuff with the image. But when I open it from the Mautic URL that’s inserted into the email, it opens fine.

I also opened it from other email clients and appears ok.

Chris

Actually, it appears the tracking pixel is getting stripped out of the emails sent using the cron job. Here’s the snippet from an email I sent manually:
img height=“1” width=“1” src=“http://phpstack-72367-2136201.cloudwaysapps.com/email/616520714b239267131151.gif

And here’s the same snipped from the same email sent using the cron:
img height=“1” width=“1”

Only difference in the two sends was one was a segment email sent by manually clicking “send,” and the other was sent by waiting for the cron to fire. Everything else was identical.

The URL above is from a staging site. The live site is using a domain and SSL etc. and I did tests from it and got the same results.

Chris

Seems to be a file permission issue here. May need to chown the directory appropriately. Are you testing while logged in to Mautic or not logged in?

Everything I’m doing is when logged into Mautic. I’ll try changing permissions. I’m not a programmer but isn’t that error suggesting that a setting is off in PHP possibly? Or am I misreading that?
Chris

Another wrinkle in this. Emails sent using the cron have all the links stripped out. They still show as a link in the email but there is no URL, which appears to be what happens to the tracking pixel. This makes zero sense to me. How would everything else in the email get sent but those links not??

I tried enabling CORS thinking that might be the culprit, but didn’t solve. Thought I’d add this to the issue.
Chris

I’ve never heard of this issue. If you can address your permissions issue and it doesn’t fix the issue I’m honestly thinking it may be a mechanism of your ESP. Change SMTP provider temporarily (use a free trial of something maybe) and see if the issue persists.

I’ve tried changing permissions to 777 as a test and got the same results. I had also previously duplicated the issue on AWS and a client mail server I use (MXRoute). So it does not appear to be an SMTP provider issue. I have another instance of Mautic on the same VPS server but it runs from a sub-folder of the client website. I remember reading another post with a similar issue and the fix was to run Mautic from a sub-domain. So I’m going to test that next. This just seems like such a bizarre problem to me though. I’d be interested to know exactly how sending a cron-initiated segment or campaign differs from initiating the send manually. My guess is that temp files are created and placed in folders, which are then queued and sent over time. But I do not see how that could cause this, especially since the rest of what’s in the email’s layout code gets sent. Why on earth would linked URLs get stripped out and why wouldn’t the other images I’m using in the email (also links to AWS via BeeFree) ALSO get stripped out? I guess the clue is the stripped images and links are coming from my Mautic domain and the others from an AWS domain.

It very well may be a cross-origin issue. Right click on your browser window and select inspect, and then open an email in the browser for example one sent to a gmail account and see what errors you can see in the console.

First off, THANKS for the help here in the forum! Much appreciated.

Second…figured this out. Two settings changes got links working in emails and read/link tracking for sending via cron:

  1. In my configuration: system settings, I had originally entered my domain name without a prefix (no http://, www etc.) So I added http://. This got the links working in the emails, but click tracking still wasn’t working.

  2. Setup IP MaxMind GeoLite 2 download lookup service (just the freebie one) along with my UN:PW credentials from my account. This got link tracking working.

Those two things got it all working. So was misconfiguration on my part. Still doesn’t make sense to me why sending manually tracks everything WITHOUT these settings. But hey…I’ve spent hours trying to figure this out so hopefully it helps someone.

I went and looked at my other working Mautic instance and noticed I had entered the full URL (with prefix) in the Configuration: System Settings and had the IP lookup service enabled and downloading successfully…so I matched it in this instance and VOILA!. What’s weird is I never had any problems with the other instance and it does nothing but automated campaigns (I’ve never sent anything manually). So guess I should’ve looked at that setup long ago!!!

Chris Blair

2 Likes