Symphony.

A new extension, “SMTP Email Library” is now available for download. Comments and feedback can be left here but if you discover any issues, please post it on the issue tracker.

Awesome! This is great, I’ve been wanting this for ages, but haven’t gotten around to building one.

One thing for me though is that when I enable the extension I lose all my styles/javascript/images from the admin area (actually it didn’t do that the first time until I set the preferences - it removed the styles etc. on save). I just upgraded my installation to 2.0.7 prior to installing the extension. As soon as I disable the extension everything returns to normal. Any ideas?

Haven’t yet tested to see if the extension delivers my mail yet, but thanks heaps for the extension :).

Building such an extension for the swiftmailer library is on my to-do list. Any reason you choose PEAR Mail over swiftmailer?

No more core hacking. Thank you Alistar!

One thing for me though is that when I enable the extension I lose all my styles/javascript/images from the admin area

This extension doesn’t do anything to styles/js/etc. The only thing I can think of is the .htaccess update it makes might be messing stuff up. When it is installed, what does your .htaccess file look like?

Any reason you choose PEAR Mail over swiftmailer?

Not really. I liked the PEAR SMTP Mail class.

Actually I just went and set it up again to check the differences between the .htaccess files and it all seems to be working today, strange, but awesome. Thanks anyway :).

I’m getting following error using this extension in 2.0.7 RC1:

Fatal error: Class ‘GenericErrorHandler’ not found in /home/stobrava/webapps/bnwpl/extensions/smtp_email_library/lib/pear/Mail/smtp.php on line 322

I’ve tried on different server and same error appear. Anyone got this extension working?

I think that the problem is with PEAR Mail or with ssl on both hosts. I’ve changed extension to use swiftmailer and ‘hacked’ to use with ssl and now works.

icek, you beat me to modifying this extension to use swiftmailer, care to share/ make it available?

@newnomad - when I make it working with new members extension I will release it as alternative on github :)

@icek - great. Is that the long awaited official members extension?
FYI fellow symphonian Michael-e might also be working on adding swiftmailer to it …

No, I have not started working on this, because compatibility is “2.0.6: unsure”. At the moment I have no time to work on a 2.0.7 beta. (Live sites still use 2.0.6.)

I should add that this extension does not replace all emails sent by Symphony. Emails such as password reminders from the core will still use Symphony’s own email sending method. This extension provides an alternative “Send Email” event filter. I’m not sure whether it can be used in conjunction with Rowan’s Email Templates Filter…

I would prefer not to have two different ways of sending simple text emails. A developer will then have to test each of the two methods (and most of the time forget to test the core method). That’s why I am worried about the Members extension relying on the SMTP Email Library.

Is there any chance to completely replace the email core functionality using an extension? I think this would be the best way to go.

@michael-e Agreed. I think Symphony should have a SMTP functionality as part of the core, and library dependencies isn’t such a good thing.

SMTP Email Library updated to version 1.1 on 12th of February 2010

I would prefer not to have two different ways of sending simple text emails.

Fair enough. Then I would suggest you don’t bother installing the Extension. Don’t forget, this extension serves primarily as a library class for developers who need more flexibility. The new Event filter is just a bonus/byproduct.

A developer will then have to test each of the two methods (and most of the time forget to test the core method).

A developer will only have to test the method which he/she uses. Like I said, this is a library extension. The developer is not forced to use both. They can quite easily hook into the existing General::sendEmail() function, or opt to use this more robust solution.

I think Symphony should have a SMTP functionality as part of the core, and library dependencies isn’t such a good thing.

Perhaps it should, but I am not about to rewrite the PEAR SMTP library so it is does not require PEAR. We needed a more robust email sending library for the Symphony site. This extension is the public release of that code.

For a good explanation, I suggest you read Allen’s response.

library dependencies isn’t such a good thing.

I agree that the core should be free of dependencies, hence why this was released as a separate Extension due to the dependance on PEAR. However, I do not share this concern with regards to Extension dependencies. Furthermore, if it is really such a concern, then the Extension developer can rip out the important classes in this (or other) Extension and roll it into their own eliminating such a “problem.”

@Alistair: on some machines your extentension crashes, this is besause PEAR::Mail use variable =& new Class syntax.

From php site:

Since PHP 5, new return reference automatically so using =& in this context is deprecated and produces E_STRICT level message.

In Members extension you use that syntax too when creating =& new Cookie.

@Alistair

Perhaps it should, but I am not about to rewrite the PEAR SMTP library so it is does not require PEAR

That’s why I highly recommend swiftmailer, its not part of a library and specifically crafted for email. It should be standard and maintained enough (just like jquery) to be part of the core.