nbcommunication

Hi @montero4, I'm sorry, I'm still not following? There's nothing stopping you changing the src - you should resize the image first: // Get the image $image = $page->images->first; // Resize the image $image = $image->size(1024, 468); // Output the image echo "<img src='$image->url' alt='$image->description' srcset='$image->srcset'>"; // Or alternatively echo $image->render(); PageimageSrcset recognises that it is an image variation and then uses the original to generate srcset variations. It isn't really this module's job to handle the src attribute. In theory you could do some manipulations of the "srcset" value to extract the first or last image for use, but I'd say it is a lot cleaner just to resize the image. Cheers, Chris

For folk using the module - is the configuration of sets in the textarea working OK for you? I've been mulling over trying to build something a bit more user-friendly, like a kind of repeater field for entering data, but I'm not convinced that it would actually be easier to work with, particularly as I usually only enter an image width per line and that's it. In a future version I want to add the configuration on a per-field basis (maybe even per-image even though that would be overkill), so I want to get the configuration method as solid as possible first. Perhaps retaining the textarea, but with a live preview would be the best option? I'm also not sure whether it is useful to have portrait mode and UIkit widths as config options. Ultimately the module is meant to extend Pageimage so that srcset and sizes can be used - I feel these config options are a result of my own bias in how I use the module, and yet I don't think I've used the portrait option at all! Any ideas/thoughts you have, please come with them! Cheers, Chris

Hi @adrian, Finally gotten a look - it was as I expected. When an email address is passed to WireMail::to() it is run through WireMail::sanitizeEmail(). This passes the email through both strtolower() and trim(). addRecipientVariables() was just using Sanitizer::email(), which doesn't pass the email through strtolower/trim, resulting in different keys. I've changed it to use sanitizeEmail(). Sorry it's taken so long to fix! Cheers, Chris

Hi, With the deprecation of Instagram's API and therefore the end of the Instagram Feed module, I've developed a replacement module which uses the Instagram Basic Display API: https://github.com/nbcommunication/InstagramBasicDisplayApi To use this module you'll need: ProcessWire >= 2.7 A Facebook Developer account Access to the Instagram user account you wish to use Prior to installation, you'll need to create a Facebook app. The app you will create uses the User Token Generator for authentication - it does not need to be submitted for App Review (and therefore stays in Development mode). The README contains full instructions on how to create and set up the app and also how to use the module. The primary reason for this module's development was to retain functionality on existing websites that use the Instagram Feed module. To assist with upgrading, this module replicates some methods provided by Instagram Feed. I've already upgraded a couple of sites and it was quick and painless ? Cheers, Chris

@teppo, having read a bit about <picture>, it probably would make sense to provide this functionality in the module, but possibly as a separate method distinct from render(). I’ve got a fair bit I want to do on this module, but it’s behind a lot of other work at the moment. I’ll add this to the todo list, but for the time being, I would go with writing something for your own use. Cheers, Chris

Hi @montero4, Can you please give a code example? From your description, it seems to me that all you need to do is resize the pageimage before rendering/getting attributes. Cheers, Chris

Hi @teppo, I've not used <picture> myself, so will need time to do a bit of research. Off the top of my head though, I do feel that this module wouldn't necessarily be the best place for it. When I get a chance I'll have a think through the implications. Cheers, Chris

Hi @adrian, Apologies for the lack of response - been fairly in the thick of a project since being back to work after the new year. Hoping to get this looked at soon. Chris

Hi @adrian, Yep, that'll do it - I'll pop strtolower() in place when assigning the key value to prevent that from happening. Cheers, Chris

Hi, that could effect the count I think. I’m pretty sure it should be an associative array argument, so it would be $to[$emailAddress] = “”; (name omitted) I can’t actually see the implementation of the argument in WireMail::to() here - https://processwire.com/api/ref/wire-mail/to/ - on my mobile, but it should behave in the same way when using it with WireMailgun. Looking at the WireMail.php source I think maybe a sequential array is accepted - will need to look at this further!

Hi @adrian, That's bizarre! I've just done a test using 200 test emails (string length > 998 [nearer 15000] so using folding for recipient variables) and it returned the correct number of emails sent. I don't think it is one for Mailgun support - the number/count generated is 1 if batch mode is off, and if it is on, as it is in this case, it returns the recipient variables count. If to() is set, it adds this to the recipient variables too, but because the recipient variables array is keyed by email, this shouldn't increase unless there are different emails in the to and recipient variables arrays. In other words, the count is internal; it's not returned by the Mailgun API. My first point of attack on the problem would be the Mailgun logs, followed by adding a few $this->log($data["recipient-variables"]); or $this->log(count(json_decode($data["recipient-variables"], 1))); calls in the module where appropriate to try and figure out where the problem is occurring. I don't actually have access to Mailgun logs here, so will get a better picture on Monday - perhaps sending in test mode is skewing my tests! Are you using this with ProMailer? Wondering whether the issue is integration with another module? Cheers, Chris

HI @adrian - I've had a good look at it but can't find the issue running the code with some test data. Getting a 200 response and no errors logged. Are you able to see the "to" address in the Mailgun log for the request? If so, is there anything there that might indicate what is causing the "to" address to be invalid?

Ah ok, I'll see what I can find ?

Hi @adrian, was just about to test and noticed the extra $ on line 3&5 - I think it should be $u->email?

Hi @adrian, will be back in the office on Friday so will take a look then. Happy New Year to all when it comes! Chris

Hi @Jonathan Lahijani - I've just seen the open issue in Github, which should be resolved now. Are you still getting the issue above on this latest version?

Hi @ryan, Thanks for the new module! During the development of a module this week, I wondered whether it was possible to save module config data without the "modules" log being added to. I think this may be a useful addition as I'm finding that when I've got a log open in the admin and a new entry is generated and fetched with AJAX, UserActivity is saving config data (hookProcessWireFinished), and generating another "Saved module 'UserActivity' config data" entry. Perhaps there's a simpler tweak that could be made, e.g. checking if AJAX, but a quiet mode for saveModuleConfigData might be a good addition and solve this very minor issue! Cheers, Chris

Yep - that happens! Mac Mail was doing the same to me when testing last night.

Haha, up to version 1.1.6 now. I realised that ProMailer probably needs to use batch mode, so I've added some checks in the module config to set batch mode to on by default if it is installed.

Hi @adrian, I've made another update to the module. I've removed the inferring of "id" if addRecipientVariables() isn't used, as it was confusing and didn't really work anyway... I'm not getting the comma issue (also using Mac Mail), and multiple batches is working for me also - if it still persists for you after the latest update, please let me know and I'll debug further in the morning. I've added an example to the README which should hopefully explain batch sending/recipient variables a little more: // If using batch mode, the recipient variable "name" is inferred from the `to` addresses, e.g. $mg = $mail->new(); $mg->to([ "user@domain.com" => "A User", "user2@domain.com" => "Another User", ]) ->setBatchMode(true) ->subject("Message Subject") ->bodyHTML("<p>Dear %recipient.name%,</p>") ->send(); // to = A User <user@domain.com>, Another User <user2@domain.com> // recipientVariables = {"user@domain.com": {"name": "A User"}, "user@domain.com": {"name": "Another User"}} // bodyHTML[user@domain.com] = <p>Dear A User,</p> // bodyHTML[user2@domain.com] = <p>Dear Another User,</p> // Alternatively, you can omit the `to` recipients if setting `recipientVariables` explictly e.g. $mg = $mail->new(); $mg->setBatchMode(true) ->addRecipientVariables([ "user@domain.com" => "A User", // "name" is inferred "user2@domain.com" => [ "name" => "Another User", "customVar" => "A custom variable", ], ]) ->subject("Message Subject") ->bodyHTML("<p>Dear %recipient.name%,</p><p>Custom: %recipient.customVar%!</p>") ->send(); // to = A User <user@domain.com>, Another User <user2@domain.com> // recipientVariables = {"user@domain.com": {"name": "A User"}, "user@domain.com": {"name": "Another User", "customVar": "A custom variable"}} // bodyHTML[user@domain.com] = <p>Dear A User,</p><p>Custom: %recipient.customVar%!</p> // bodyHTML[user2@domain.com] = <p>Dear Another User,</p><p>Custom: A custom variable!</p> // %recipient.customVar% only prints for second email, so not a particularly useful example! // You can also use `addRecipientVariables()` to extend/override the inferred `recipientVariables` e.g. $mg = $mail->new(); $mg->to([ "user@domain.com" => "A User", "user2@domain.com" => "Another User", ]) ->addRecipientVariables([ "user@domain.com" => [ "title" => "A User (title)", ], "user2@domain.com" => [ "name" => "Another User (changed name)", "title" => "Another User (title)", ], ]) ->setBatchMode(true) ->subject("Message Subject") ->bodyHTML("<p>Dear %recipient.name%,</p><p>Title: %recipient.title%!</p>") ->send(); // to = A User <user@domain.com>, Another User (changed name) <user2@domain.com> // recipientVariables = {"user@domain.com": {"name": "A User", "title": "A User (title)"}, "user@domain.com": {"name": "Another User (changed name)", "title": "Another User (title)"}} // bodyHTML[user@domain.com] = <p>Dear A User,</p><p>Title: A User (title)!</p> // bodyHTML[user2@domain.com] = <p>Dear Another User (changed name),</p><p>Title: Another User (title)!</p> Cheers, Chris

Hi @adrian, Ah bugger, I'll see if I can figure that out... As I understand it, WireMail calls should always use to() to set the recipients. However, it does make sense to allow for recipients to be set from addRecipientVariables(), as this prevents repetition should you want to set custom variables (id and name are the ones inferred from the "to" recipients). Hopefully this example makes some sense of that: $to = array(); $recipientsArr = array(); foreach($recipients as $u) { if($u->$email) { $name = $u->first_name . ' ' . $u->last_name; $to[$u->email] = $name; /* If addRecipientVariables() isn't used, the recipient variable is inferred as: $recipientsArr[$u->$email] = array( 'id' => $i++, // index increment (%recipient.id% in bodyHTML) 'name' => $name, // (%recipient.name% in bodyHTML) ); */ $recipientsArr[$u->$email] = array( 'id' => $u->id, 'toName' => $name, // (%recipient.toName% in bodyHTML) ); } } // Previous usage $mailer = $mail->new(); $mailer->setBatchMode(true); $mailer->to($to); $mailer->addRecipientVariables($recipientsArr); $mailer->from('me@google.com', 'My Name'); $mailer->subject($newsletter->title); $mailer->bodyHTML($message); $numSent = $mailer->send(); // Now simplified, no need for to() $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(); // After the next update, records in $recipientsArr above must contain a value for either "name" or "toName" // for this to be set as the "to" recipient name, e.g. $mailer->to($email, $name); Some more info about toName: $mail["toName"] is set by the core WireMail.php to() function as seen in the example in my previous post. The reason I pull the recipient emails from $mail["toName"] is that this array is a key=>value store of email addresses and the name set for them (if set), whereas $mail["to"] just contains the email addresses. In WireMail::send(), $mail["to"] is traversed and the name is set if it exists in $mail["toName"]: // WireMail.php 611-619 foreach($this->to as $to) { $toName = isset($this->mail['toName'][$to]) ? $this->mail['toName'][$to] : ''; if($toName) $to = $this->bundleEmailAndName($to, $toName); // bundle to "User Name <user@example.com>" if($param) { if(@mail($to, $subject, $body, $header, $param)) $numSent++; } else { if(@mail($to, $subject, $body, $header)) $numSent++; } } I suspect this is probably a result of an earlier implementation of WireMail that didn't have the toName option - I think it makes more sense to traverse $mail["toName"] in this module's implementation. The WireMail::toName() method isn't actually used by this module directly - in core WireMail this sets the "name" for the last added "to" email address, so could be used like so: $mg = $mail->new(); $mg->to("email@example.com") ->toName("An Example Name") ->subject("A Subject") ->bodyHTML("<p>Test</p>") ->send(); // Sends to "An Example Name <email@example.com>" // An alternative to $mg->to("email@example.com", "An Example Name"); On another note, while reviewing the docs I see there's a line length limit on X-Mailgun-Recipient-Variables which I'll likely need to handle too. Will see what I can do with this. Cheers, Chris

Hi @adrian, How are the "to" email addresses being passed? As I understand it, the "toName" variable should be populated when calling WireMail::to()? // WireMail.php 304-309 if(empty($toName)) $toName = $name; // use function arg if not overwritten $toEmail = $this->sanitizeEmail($toEmail); if(strlen($toEmail)) { $this->mail['to'][$toEmail] = $toEmail; $this->mail['toName'][$toEmail] = $this->sanitizeHeaderValue($toName); } I think what you're saying is that you aren't using the to() method, and instead the "to" addresses are being set using addRecipientVariables()? I've tweaked the module to handle this implementation. Technically the recipients should be set using to() and addRecipientVariables() is for overriding the recipientVariables set by default from $mail["toName"], but I can't see the harm in allowing for this different implementation. Cheers, Chris

Hi @adrian, I'll check this later, but I'm pretty sure it should work as expected - "to" is set on line 469 regardless of batchMode, and then overridden if split into batches (line 594) so "to" and "recipientVariables" are limited to 1000 at a time. Cheers, Chris

Hi @adrian, Got a chance to look at this today. Batch requests (batch mode on, to emails > 1000) now get split up into separate API requests with 1000 emails per request. The only way I could test this was to reduce the limit to 2 and then try sending a batch request to more than two email addresses. Seems to work fine, however I'd recommend enabling test mode and testing with this to confirm that it works correctly for emails being sent to 1000+ users prior to sending for real. I've also moved the batchMode setting into the module config, so it can be set to ON by default. Cheers, Chris

Hi @adrian, I did look at using the SDK for the module, but felt it was overkill for what was required - A more fully featured Mailgun API module could be built with it, but that's a job for someone with more experience and need for it. I'll have a look at this in the next week though. Not sure I'll be able to test it fully, but it should just be a case of splitting the to array into batches of 1000 and sending each of these. Cheers, Chris