4 users online. Create an account or sign in to join them.Users
using phpswiftmailer as mailing module in an extension/event
This is an open discussion with 45 replies, filed under General.
Search
You can always edit the event’s PHP-file directly and put custom stuff like swiftmailer there.
so youre saying there is no need for the default /symphony/lib/toolkit/events/event.section.php it could as wel be in the default mailing event?
Just take a look into your /workspace/events/event.eventname.php, change the return value of allowEditorToParse() to false (otherwise Symphony will overwrite your customizations once you click “edit” in the backend) and put your custom stuff in __trigger().
Whatever you had in mind, it will happily do that in case of that event.
thx!
Many extensions bundle Events or Data Sources inside them. So you can include the Swfitmailer library and your custom Event in your extension, and they remain separate from the core.
My Gravatar extension packages a Data Source which is installed when the extension is enabled. The convention is to add a lib folder to the extension to contain external libraries (e.g. Firebug Profiler that includes the FirePHP core).
If I was 2 write a second extension, for example a newsletter mass emailer, also using swiftmailer, would you recommend including it again? Or merging the 2 extensions? Is there a recommendation for jointly used libraries across extensions?
Create a generic one that includes swiftmailer and supplies simple email-functionality for events.
Then create the massmailer and document the dependency in the README.
@newnomad: Are you building a newsletter extension? This is what I am about to do as well.
I intended to use Swiftmailer as well, which seems to be a very good framework. But I am bit worried about bugs not being solved, like this one which is connected to caching. What do you think?
I do not think that Symphony needs two different Newsletter extensions. So if you really want to build one, why not work together? I could send you my concept next weekend. (At the moment I am in Italy, trying to calm down a bit and at the same time finish a big project for one of my German clients, which makes it impossible for me to finish the concept right now.)
@michael-e my priority now is building my own webshop, products imported as xml from openerp, and orders resulting in pdf invoice automatically emailed. This means I can stay with symphony for all my needs (no zend or django), and ofcourse later would like to replace pommo with a symphony extension. And add the google translator toolkit for community translations. If I get to the newsletter before you, I definitely value working together. If you send it to me now, I’d probaly lose focus ;-)
As for alternatives, codeigniter or zend also do have email classes, but putting an entire framework into an extension seems overkill to me. also pear Something to consider might be to completely switch to smtp, using a gmail account (max 500 i think) but I’d think that still needs helper classes for throttling and such? Do you have some insight in swiftmailer, when using only smtp, does it offer advantages over some basic php code? Or does it only shine as sendmail replacement?
The Swiftmailer guys recommend using SMTP over Sendmail:
It’s a common misconception that because the Sendmail Transport returns a result very quickly it must therefore deliver messages to recipients quickly – this is not true. It’s not slow by any means, but it’s certainly not faster than SMTP when it comes to getting messages to the intended recipients. This is because sendmail itself sends the messages over SMTP once they have been quickly spooled to disk.
The Sendmail Transport has the potential to be just as smart of the SMTP Transport when it comes to notifying Swift Mailer about which recipients were rejected, but in reality the majority of locally installed sendmail instances are not configured well enough to provide any useful feedback. As such Swift Mailer may report successful deliveries where they did in fact fail before they even left your server.
So SMTP is the way to go. The main advantage of Swiftmailer will probably be throttling, attachment, encoding and stuff like that.
On a personal level I’d never recommend sending newsletters through your own SMTP server (on shared or even dedicated hosting). Dedicated providers such as Campaign Monitor, Mail Chimp etc.
Sending mass mails through an open-relay SMTP server has never been effective in my experience. There are very high bounce rates for a variety of reasons (no reverse DNS entry, incorrect MX records, no SPF record, blacklisting) and you run the risk of overloading the server entirely.
Providers such as Campaign Monitor have ties with the large email providers (Hotmail, Yahoo etc) and are virtually guaranteed to be on whitelists. They also provide great reporting too.
Or maybe I’m way off the mark.
I agree with Nick. FWIW, for the Public Culture site I set up a newsletter section whose entries are both browsable in the frontend and can also be accessed in our email template format with a special URL. For each new newsletter, I just point CampaignMonitor to that special URL and voila, I have my mailing ready to go.
If you want to manage recipients, I haven’t experimented with working with the lists much, but CM imports and exports CSV, so it shouldn’t be too difficult…
What about local european ISP’s I doubt campaignmonitor is tied into those?
Also I think it all depends on your setup its perfectly possibel to avoid the reasons nick notes?
And what do you guys think about using your (google apps domain) gmail account trough smtp instead of through your hoster?
But mostly, its not free,(nor is emma, mailchimp,…) and some clients mind find that an issue.
I’ve also done as czheng describes, web + email versions, and link it into Campaign Monitor. Very smooth operation (compared to Dreamweaver). I also have the ‘preview’ email vs ‘full content’ email options.
As far as using a blasting service or not, most of them add value beyond their white-/blacklist management, for instance I know CM gives you decent analytics, as Nick says. Replicating the email address-specific tracking would be prohibitive IMHO. Our sales guy will actually use that info (e.g. follow up with prospects based on their click-thru).
I haven’t looked into CM’s API lately, but I think they’ve been making improvements; would be cool to get a CM extension going (mainly for managing the lists, etc).
would be cool to get a CM extension going (mainly for managing the lists, etc)
Abso-muchly-lutely — we use CM at Airlock every so often and I’m about to use it for a personal project, so I may be able to look into this some more.
Nick, I’d be willing to look into it with you if that would be helpful.
That it would.
Michael could you chime in about CM or other services being more focused on US emailcampaigns, or aren’t they? What if 80% of your clientbase has emailadresses from local european ISP’s?
Also we really need a way to fork discussions into new treads once they go offtopic, nick?
I actually do not know if CM is delivering emails better in the US than it does in Europe. But in my projects I see several problems with using a hosted service like CM:
- My clients are afraid of legal problems with hosted services (because their clients’ email addresses would be stored elsewhere, even in a foreign country in the case of CM); Germany has rather restrictive laws regarding data storage;
- It would be hard to build a seemless integration (in German, in my case);
Although I know about the problems that Nick has described, and even some more (like provider restrictions), I will try and build a Symphony extension and deliver emails via SMTP. It will require a lot of testing and thorough documentation. In the beginning it will have no integrated bounce handling nor statistics. But I love the idea of having full control in Symphony. So I will simply try.
Create an account or sign in to comment.
Is it possible to use an independant mailing module like swiftmailerin an extension and/or event?
Because the default mailing system in symphony uses parts from the core library, I wondered if this had a reason, if the default mailing could be reengineered to work only from within an extension with event?
Beacuse if the use of swiftmailer meant you’d had to put it in the library, then it would brake on each update.