Search results

Okay just ran some tests. My delivery_log is roughly 20GB. It took 62 secs to search for any email with GIVEUP status. However, it took 0.0167 secs to search for any email with GIVEUP status and a specific campaign_id, so it doesn't take too long if you include a campaign_id (depending on if you...

How large was delivery_log in your tests? I'd imagine it becomes a issue when delivery_log is in the GBs. I'll have to look into it more, but I'm pretty sure failed emails (when using temp queue tables) are not being recorded in delivery_log for me.

Have you considered creating a temporary table for GIVEUP emails, since it can be quite performance heavy to scan campaign_delivery_log? Also, earlier I mentioned a bug where failed emails are not being put in campaign_delivery_log, were you able to identify that? Cause otherwise I'm thinking...

Any details on how this resending feature works? Does it search for delivery_log for failed emails or are you creating some sort of temp table to hold failed deliveries?

Got it, thanks!

Awesome, thank you. When will the version with this be released?

Thanks!

For $searchReplace = (array)Yii::app()->hooks->applyFilters('campaigns_get_common_tags_search_replace', $searchReplace); in CampaignHelper.php, can we get more parameters such as subscriber and campaign information?

Really? Did you even read what the error says. Clearly: "Application currently offline. Try again later!" You need to change the online / offline setting in the backend.

That would work, of course, but that means our sending is slower than I want. ElasticEmail has helped me find a temporary solution to the problem, as the problem is at their end of 30 concurrent connections limitation, while they work on a more permanent solution.

Were you able to figure out why failed emails aren't in delivery_log?

How about an easy solution something along the lines of: -Create a new "delivery_failed" table -When delivery fails of an email, instead of putting that email into "delivery_log", put it into "delivery_failed" -Every time send-campaigns cron runs, check "delivery_failed" table for emails that...

Would you consider adding it back? It seems like a critical feature for deliverability reliability, as delivery can fail for numerous reasons. What about a simple approach of simply keeping a delivery_failed database and reprocessing the emails in that database at the end of a campaign? EDIT...

What happens when delivery fails -- where is the failed delivery recorded? Does MailWizz attempt redelivery? After adding the above code, I no longer see failed deliveries (the one that threw 403 errors) in delivery_log but they also have not been delivered.

Because in their v1 API (which MailWizz uses; you may want to consider upgrading to v2) returns a GUID on successful delivery, which is 36 characters in length with 4 dashes.

in /apps/common/models/DeliveryServerElasticemailWebApi.php change this... if ($response['status'] != 'success' || strpos($response['message'], '-') !== false) { throw new Exception(Yii::app()->ioFilter->stripClean($response['message'])); } To this...

Does this include the EE requirement for {address} too?

Thanks.

Can you tell me which file to modify? Also, how can I confirm MailWizz has successfully sent emails? If it shows as sent in the backend for each campaign, can I assume the email was successfully sent?

Anyway to output verbose for send-campaigns command when there is an error? There seems to be a problem with delivering emails and I need to find out if the problem is at my side or my ESP. Using verbose=1 outputs way too much info, I only want when there is a problem. Possible?