adrian

Maybe it is art, but you know what would be logical and efficient ? ..... fixing issues via PRs 🙂

Hey @bernhard - you've probably already seen this comment via Github, but I'll repost here for others. I like your proactive approach with module, but I fear that it might actually slow down fixing these things in the core because if users start adopting it, they'll be less likely to add their voice to the actual issue reports and so Ryan won't see that the issue affects other users as well. I hope I am wrong though and I really do appreciate your effort!

Thanks for all the great updates (and the new examples) Chris, Latest version is looking good so far - I expect I'll be testing more again tomorrow and will let you know if I notice any issues. Cheers!

Thanks Chris, I had forgotten about the ability to pass an array to the wireMail to() method - I was thinking it only handled one address or address / name pairing. Perhaps given that, there isn't really a need to pull the email and toName from the recipientVariables array, although it is a nice shortcut still. Sorry if I sent you on a wild goose chase with that. One minor point - do you know why in my email client (Mac Mail) there is a comma after the "to" address, even if I only send it to one recipient: It's not super important, but it seems a bit weird and wasn't happening before I started using batch mode.

Just testing this new version (using my code above) - it now works for one recipient when batchLimit is set to 1000, but if you are sending to 2 or more (presumably anything up to 1000), only the first recipient is sent the email. Sorry, I think it is actually working - looks like my email client is not showing one of the messages because perhaps it thinks it's a duplicate even though they are going to different addresses?

There's a good chance I don't understand how this is meant to be done. I assumed that using addRecipientVariables() completely negated the need to use the to() method. In my mind, the to() method only makes sense if you are sending in non batch mode. How do you use it in batch mode for sending to multiple recipients - I don't understand that. Also, I am curious about the toName() method. I thought the way you had things set up, in batch mode you should use this, but rather add a toName key to the recipients array. This is basically what I am doing where $recipients is a PW page array: $recipientsArr = array(); foreach($recipients as $u) { if($u->$email) { $recipientsArr[$u->$email] = array( 'id' => $u->id, 'toName' => $u->first_name . ' ' . $u->last_name, ); } } $mailer = $mail->new(); $mailer->setBatchMode(true); $mailer->addRecipientVariables($recipientsArr); $mailer->from('me@google.com', 'My Name); $mailer->subject($newsletter->title); $mailer->bodyHTML($message); $numSent = $mailer->send(); Does this make sense to you and should this work with your most recent commit?

I think the issue is that on line 469, the value of $this->mail["toName"] passed into getEmails() is an empty array. I think this is because we don't explicitly set it in batchMode when passing recipientVariables, so we need the logic inside the if($deferredCount) section to handle getting the email's details. Thanks for looking into it.

@nbcommunication Thanks Chris for the speedy work on this - sounds great! The catch I am seeing is that if you try to send to less recipients than "batchLimit", the "if($deferredCount)" check fails and you end up without the "to" address being set. Can you confirm the issue at your end as well?

Hi Chris, Thanks for your hard work on this! I am about to implement this new version and will be looking to use the batch sending option but noticed the 1000 recipient limit. Then I discovered the MailGun's PHP-SDK handles this for you automatically: https://stackoverflow.com/questions/36063534/mailgun-api-batch-sending-vs-individual-calls https://github.com/mailgun/mailgun-php/tree/master/src/Message Any thoughts about implementing the SDK into this module to make batch sending a little easier? Thanks, Adrian

Now that PHP 7.4 is stable, I have updated the Tracy core to the latest version and also made a few other fixes to the module for PHP 7.4. Please let me know if you notice any problems. Note that this issue in the PW core (https://github.com/processwire/processwire-issues/issues/1041) currently breaks the RequestInfo panel on 7.4.

You can also modify breadcrumbs as needed, eg: https://github.com/adrianbj/AdminRestrictBranch/blob/4964a3f5b83338f7313f7c6daeefe6c6793640b0/AdminRestrictBranch.module.php#L131-L144

Not terribly helpful, but here is an old discussion about this:

@formulate - I think Pete ran out of steam on this years ago, which is when I picked it up, but I haven't actually ever used it myself so my motivation to continue is not really there I'm afraid. The module really needs a complete overhaul and most importantly needs a replacement for the flourish library which is no longer maintained. Do you feel like investigating alternatives for Flourish and perhaps taking over the module?

Textformatters shouldn't be an issue because they are not applied in the admin - sorry for that initial suggestion - you can see that I removed that a while ago in my post above. Perhaps you can try on a fresh install and confirm it's working and then figure out what modules or settings on the current problem site are causing the problem?

@tires - it's working fine here: Sorry, I don't know what might be causing the problem at your end. Can you try debugging at various steps in the module to determine what is causing the failure for you?