adrian

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?

Working now - thanks!

Thanks - awesome, except I am getting this error when updating via PW's Upgrade module. "File could not be downloaded (https://gitlab.com/rockettpw/seo/jumplinks-one/-/archive/1.5.59/jumplinks-one-1.5.59.zip) 404 Not Found: (tried: curl)" Any reason you can think of?

Yeah, it's the priority setting, but also you use addHookBefore and PagePathHistory used AddHook (alias of AddHookAfter) so to get it to not log a 404 for those URLs handled by PPH, I changed Jumplinks to use addHookAfter and set the priority to 1000 - remember that 100 is the default. Any thoughts on committing these changes to JL? Thanks, Adrian

Thanks @sz-ligatur - that hook is very helpful. @Wanze - the catch with the hook approach is that the FB preview doesn't show the correct image - is there an easy way to fix that? Thanks!

@Wanze - I am curious if you would be willing to adjust the inheritance model a little. I am looking to be able to have site editors set the OG image on the homepage and have it inherited by all other pages unless they specifically upload an image to another page. Currently the only way I can see to do this is to set the field's main default image to the URL of an image that is uploaded to the homepage, which means the editors need to explicitly name the image so the URL is always the same. I think it would be great if pages inherited values from their parent pages, rather than just directly to the field's default values. Does that make sense and sound useful? Thanks!

@Mike Rockett - I am seeing entries appearing the on the 404 Monitor tab that are actually being properly handled and redirected by PagePathHistory. I am wondering if it's a matter of adjusting the load priority for the Jumplinks module relative to PagePathHistory, or if there is more to fixing this, but it would be great if they weren't being recorded. Any thoughts? Thanks!

I'll defer to horst on the troubleshooting of it actually sending. I am just talking about the deliverability issues you are likely to deal with. If the emails are only to site editors/staff you may be ok, but if they are being sent to site users then it's likely going to be an issue at least in my experience. Maybe others will disagree?

Unfortunately this is probably a path to disaster these days - spam has made email painful and I think the only reliable option these days is to go with a transactional email service like MailGun, Postmark, SendInBlue etc. And be sure to spend the time to learn about and properly implement DKIM, SPF, and a DMARC policy.

Wow - another post about this - I deleted one already ? Please see my response here: https://processwire.com/talk/topic/4388-phone-number-fieldtype/?do=findComment&comment=193502 about how to set values for FieldtypePhone fields.

Ok, so I found the source of the problem: https://github.com/processwire/processwire/blob/4e4b3afdcbe9aef27d03170dab64dc6e8e6c5a4d/wire/modules/Process/ProcessPageLister/ProcessPageLister.module#L1100-L1106 Lister (the base version in the core) checks to see if a test page is editable but it doesn't ever set the parent: // determine how many templates are editable $test = $this->wire('pages')->newPage(); foreach($templates as $template) { $test->template = $template; $test->id = 999; // required (any ID number works) if($test->editable()) $numEditable++; } Without knowing the parent, when AdminRestrictBranch hooks into editable() it has to return false. If you want to test this out, add: $test->parent = xxxx; where xxxx is the ID of the branch parent you are restricting to - with that in place, you won't need the ProcessPageLister::getSelector hook. I feel like that code in Lister is a bit hacky and will cause problems with lots of modules that hook into editable(). I am not sure this is a good way for me to workaround this. Perhaps I could have an option in AdminRestrictBranch to automatically add this hook: $this->wire()->addHookBefore('ProcessPageLister::getSelector', function($event) { $event->object->allowIncludeAll = true; }); rather than having to add it manually. But I still think it's really weird that for Lister to work as expected you can't rely on inherited template edit permissions in the first place. Although this reason for this is obviously the lack of parent for the $test page - it can't rely on inherited permissions because it doesn't have a template to inherit from.

I see that too but it's weird to me that access permissions aren't inherited from the home template in this case. Why should we have to explicitly set permissions for the specific template for this to work? Do you agree or am I missing something? Thanks, I can also confirm this - will see if it's fixable.

@JeevanisM - I don't know why the integer phone number isn't working, but for the phone number field you have to set the subfields separately, eg: $u->Phone->country = 944; $u->Phone->number = 6196667; or if you have the field set up to keep the area code in a separate subfield: $u->Phone->country = 944; $u->Phone->area_code = 619; $u->Phone->number = 6667; and don't forget to use the field's formatting options to style the output how you want.

That debug code also works perfectly in the Tracy console ?

Did you read this thread?