Leaderboard

I have thought a bit about newsletter integration and how an emailer setup would work from within ProcessWire, either by building something natively or integrating with Campaign Monitor / Mailchimp. I have a couple of sites for organisations with medium-sized memberships. These need to email their members from time to time so I built a dead simple module to do this which supports a single email template. You can take a look here. Please feel free to build upon this, or just take the basic idea and run with it. https://github.com/ffub/ProcessMailer These are the benefits I can see from building a complete web mailer in PW: Ease of use My clients already know how to use the PW backend All of them find Campaign Monitor and MailChimp very hard to understand and use, especially the latter Content management all in one place. They can manage their web presence all from the backend of their site [*]Tight integration with user database. You can easily create a mailing lists with PW’s awesome selector engine, eg: $users->find(“roles=5810, newsletters=news|offers”) [*]Create email templates based on the PW templating and field system Multiple email templates Familiar API Keep your templates alongside your front end templates Use templates for system messages [*]Because sent mails would be stored in the system as Pages and the templates would be on the server, These are the negatives Your server will get blacklisted! Preventing users from marking your email as spam is a pretty herculean task. If you use the web server the site is hosted on to send the email then a blacklisting will also affect the system messages send out by all the sites on that server. You can work around this somewhat by allowing the web mailer to use a separate SMTP host in its settings. Hiring an SMTP host for bulk mailing will typically cost you more than just using Campaign Monitor or MailChimp. Hosts such as Gmail will only let you send up to 500 messages and will frown upon sending bulk mailings through their service. Performance: Sending multiple HTML emails can be very slow. I’m not sure how much offsetting the sending to an SMTP server improves this, but it’s definitely a concern on a web server. Bounces: You would have to setup the mailer on your server to route these to ProcessWire. Even then, it’s quite a job working out which are actual bounces and which are Out of Office messages or genuine replies. Metrics: Email analytics is a task best suited to the big boys. How would you build an emailer in processwire? I think it would actually be pretty simple to build a pretty powerful Mailer. Lists would be created by choosing a role, or using a selector for more advanced ones. Templates would be stored alongside regular page templates and you’d use the familiar $page API within them. Eg $page->subject. The rich text editor field might need some trickery to make sure all links and image paths are absolute URLs including the hostname. Campaigns or Messages would be created as pages. You could have draft and sent statuses or parents. It would be possible to view them on the front end too. Your email templates could easily pull in data via the Page field type, allowing you to sent out emails for events and the like with ease. Text versions could either be based on an alternative template (multiple files per template may be tricky) that strips out any HTML or by running the HTML template through Lynx on the server, which makes for a unix/cygwin dependency. If you used Textile or Markdown for your body field rather than TinyMCE this would be less of an issue to work around. An analytics field in the settings would let you enter a Google Analytics ID. Links could then be tracked with Google's campaign tracking I’m certainly keen to look into the templating side of this over Spring as I’d like to use HTML templates to send some of my notification messages. thanks, Stephen

Just a very quick one from me on the subject - I do love the idea of pulling together emails using content from other pages and templates - simply have a basic template with an introduction field, then a latest news PageField that can select multiple pages and use their contnt, then maybe another text box and so on... you're limited only by your imagination here! What I wouldn't then do is send the email from my own server, due to the blacklisting reasons ffub mentions above. It's a right pain in the arse to get yourself de-listed and all it takes is for a few users to click "Junk" instead of "Trash" (that was an issue years ago so I hope most free email providers have clarified their terminology by now) and you'll be fighting an uphill battle in no time, which is never fun. What I would do personally is use PW to pull together the content and then use a service that allows you to import contents via the API. I know MailChimp can do that and with a basic shell template in the dedicated email service, I don't see why you shouldn't be able to then just inject the HTML you've created from your template in PW into something like MailChimp. Then you have the best of both worlds. And a slight headache from programming a module to shunt the parsed email contents over to the email service, but worth it in the long run You could really go to town with the programming if you wanted to and simply never have your user see the 3rd party interface - I know the MailChimp API lets you pull subscriber lists and stats, and activity reports etc - I find their interface confusing so it would be great to just pull in the information you need. And all of this under its own tab in the PW admin. Well, I can dream can't I? I do like the idea of sending email and handling it all from within PW but I've just had too many bad experiences with subscribers accidentally/intentionally getting a server blacklisted.

As per https://github.com/r...essWire/pull/84 Nice! Although it isn't very useful when adding a bunch of modules at once. Also if a module has multiple, with dependencies, it's likely that the links jump to the non-installable version(s). Although there's a note in the description if module dependencies is set. So what if they're also an anchor to the intallable module mentioned? If there is any way to make this a little more clever it would be awesome. We already discussed this a while ago but can't find thread.

Maybe something as simple as having the options to show only uninstalled/installed, and core/noncore modules would already be very useful

Cool! I think you only need this line: $field->derefAsPage = FieldtypePage::derefAsPageOrFalse; Edit: just reading again... you want to select fields not pages? Why not just use a simple select? I think ASM select and the others depend on the fieldtype page, which hold the setting to select multiple or only one. Not sure if there's a way to use ASM select for this, as it's always possible to select multiple.. just 1 will be saved. I need to think again what you're really trying Edit: oh and in modules you can always just use. $this->modules->get("nameofmodule"). Edit: I recently used something like this in my DataTable module, maybe this is of help too. $field = $this->modules->get("InputfieldSelect"); $field->attr('id+name', 'filter_template'); $field->label = "Filter by Template"; $field->description = "...."; $field->addOption('', 'Show All'); foreach($this->templates as $t) { $name = $t->name; if(($t->flags & Template::flagSystem)) $name .= "*"; if($this->optionTemplate == $t->name) { // optionTemplate is just example, depending on how you save the settings in your case $field->addOption($t->name, $name, array("selected"=>"selected")); } else { $field->addOption($t->name, $name); } } }

Hi! This is my first post here ;-) I solved the issues mentioned by Soma by editing bootstrap.css. Go to /wire/templates-admin/styles/bootstrap.css Remove or comment line 2063 to 2087 (.modal class) and replace it by: body.modal { background-position: 0 -60px !important; } body.modal div.topbar, body.modal ul#breadcrumb { display: none; } body.modal div.container-fluid { min-width: 300px; } body.modal div.container-fluid > div[style] { padding-top: 15px !important; }

Yep - I didn't think it would be an issue really memory-wise, but as I just installed an 8kb (huge ) module and looked down the list at a few others that run on page load an/or save, I just thought they might begin to stack up eventually. I suppose the only issue with those is if they're designed to use selectors and have a lot of data to look through and are being loaded unnecessarily, but then that's probably more to do with the module's design, as if it's built well enough then one of the first checks on one of the first lines of code should be whether you're in the admin or not (if that's a check you need to run in a specific module). I guess I worry with my own modules more than others