[wp-hackers] PHPMailer was a mistake

[Jacob Santos]

Going over the previous thread, it seems that only the bad/wrong 
suggestions are being heard, while the more correct arguments are being 
ignored. Perhaps, I might have better luck, but I doubt it. At least be 
open to reason. This will be long and it will be harsh.

Reasons Swift Mailer should be used:

1. PHP 4 support will be available long enough for the package to have 
reached stable enough status and it would probably only be another 6 
months before PHP 4 support will be dropped altogether. Supporting PHP 4 
after that would not be the wisest decision.

2. Swift Mailer already has a close enough API to PHPMailer that 
switching would not be difficult and has more features that would have 
to be added by the core developers or by patches. It is not a viable 
choice to continue supporting a dead project when an already better one 
with more features that are correctly implemented exists.

3. Swift Mailer supports PHP 4 and PHP 5 currently and is in the third 
version. Thus, it meets and exceeds the requirements for WordPress and 
will be a long term solution for plugin developers.

4. Swift Mailer is maintained by a skilled developer, therefore 
WordPress developers are wasting time maintaining PHPMailer. Every bug 
report, patch, and commit to class-phpmailer.php is only wasted 
resources that could be better spent making WordPress even more kick ass.


Matt Mullenweg wrote:
> PHP-Mailer is not that big. If we're in a situation where we're 
> maintaining it anyway, let's just give it its own repo and make it 
> available as a public good for others in the same situation as us. 
> (Needing a small, but functional mailer that falls back to mail().)

Something like this already exists and it is called Swift Mailer.


Peter Westwood wrote:
> For me the things that turn me off SwiftMailer over PHPMailer are from 
> a quick look at it:
>
>  1. The number of files - this increases the chance of someone 
> breaking there install with a dodgy ftp transfer.
>  2. PHP4 support is being dropped so by next year we will be in the 
> same place we are now - supporting the mailer ourselves
>  3. SwiftMailer is designed for mass-mailing PHP applications - not 
> something required in the core
>  4. SwiftMailer requires configuring with an smtp server - it doesn't 
> use mail() which means we have to add more options to the admin which 
> must be configured - giving a slower install (mail is sent during 
> install)
>
> For me, especially once you take 2 into account, we are better staying 
> with PHPMailer now - if we can make that work better than mail() for 
> 90% of our users then we will be in the right place - the last 10% 
> will realistically be difficult to support and better suited to a 
> wp_mail replacement plugin.
>
> westi 

1. There are three things wrong with your point. The first is that half 
of the statement is a matter of opinion and preference. The second is 
that the last point is very rare, I've only had that problem once in all 
of the years I've uploaded something and that was only a matter of 
switching from passive mode to regular and uploading the files that 
failed the first time. This also shouldn't be the lone reason for not 
doing something as it won't effect the majority of users.

The third reason is the kicker. Are you trying to tell me that because 
Swift Mailer uses a different class pattern that it is immediately at 
fault? A quick code audit would have told you that a lot of the core 
functionality of PHPMailer is in Swift Mailer, but correctly split into 
separate classes. PHPMailer is a mess. It uses the Singleton class 
pattern when it should at least, from what I've read in the comments, 
into 4 or 5 separate classes.

Is object theory difficult? Hell yes, I've been researching and 
developing using classes for years and I've only just recently finally 
understood some of the concepts. You don't pack everything in a single 
class. It is noobish and in most cases, wrong. Objects should only 
encapsulate what its functionality requires. For every section of 
comments, the methods below should be in their own class. Google It, and 
tell me I'm wrong.

Classes should be separated, unlike the mess that is WordPress classes. 
You should be able to look at the class path and be able to find the 
class. This is what I've been saying! If you *NEED* documentation to 
find a class, then you are doing something wrong. The benefits of 
splitting the classes into their separate files, is more than this 
however. It is good coding practice, because it makes it easier for 
other developers, for the above and is the defined coding style of other 
languages. If you don't agree with me, you *SHOULD* agree with 
programmers far smarter than you and I would ever hope to even dream to be.

2. PHP 4 support is being dropped by the PHP developers, therefore your 
point is invalid. Are you going to pick up programming PHP 4 for the 
masses after the core developers have dropped development? It would be 
pointless to continue development on a platform that is not going to be 
supported. "Yes, I would like to shoot myself in my foot, willingly." 
Please, WordPress should drop support for PHP 4 anyway after 8/8/08 and 
you have no valid argument against this, because this is how normal 
professional software development is.

Do you think software companies still develop and maintain software for 
Windows 98? Nope and you'll be a fool to do so.

3. Excuse me. What about plugins? What about Subscribe2? You don't have 
to support plugins, but at least don't make it difficult for those who 
want a reliable mailer. By your and Matt's own admission, PHPMailer is 
even more than what is required.

You are also wrong, because the whole purpose of PHPMailer is not for 
core functionality, you've already admitted that it is more than what is 
required, it is for external development. You are also wrong that Swift 
Mailer is for mass mailers, that is not the case. It is merely a better 
replacement for the built-in mail function. If you took the time to look 
at what it provided or at least admit, if in fact you did more than 
glance at it. You would realize that it offers enough to even replace 
PHPMailer easily. Not all of the classes are required to make it work 
<http://www.swiftmailer.org/wikidocs/v3/tutorials/basic>.

 From the documentation, it will only take 4 or 5 lines, unlike I 
suspect PHPMailer.

4. Like another person pointed out, there are many connection options 
that you can use. Your argument is therefore incorrect.

Let us count up the total. Oh yeah, You're totally wrong. You lose, but 
since you are a core developer, we all lose. Your opinion might matter, 
because of your position, but that would only make you an ass for taking 
advantage of your position. By shoving better solutions aside because of 
your opinion, you have ignored facts that would better help the 
community, namely the plugin one.


Lloyd Budd wrote:
> That is under consideration. 03/10/07 21:40:03 changed by ryan
> http://trac.wordpress.org/ticket/3862#comment:7
>
> "I've been looking over swiftmailer, but it is has dozens of files
> versus phpmailer's one file. If anyone wants to experiment with
> plugging swiftmailer into wp_mail(), let us know how it goes.
>
> http://swiftmailer.org/
>
> Use their php4 package rather than the php5 one."
>
> Cheers,
No, it isn't, because legacy code is still being maintained. If it was, 
then all of the problems (Subscribe2 as one example) that came up and is 
associated with PHPMailer would have been reason enough to switch to a 
better solution.



Marcos Sader | marcosmedia wrote:
> Email is used just for notifications in the core and phpMailer does the job,
> not to mention that it is a one file solution, whereas Swift Mailer has
> probably the same size that WordPress.
>
> If you are developing a plugin and need a solid email framework to build
> upon, then use SM, build a wrapper and pack it in a plugin.
>
>
> grtz

If that is the case, then the built-in solution mail() should be used 
instead and phpMailer should also be a plugin, albeit, probably a plugin 
that is packaged with WordPress. I would then say that Swift Mailer 
should be along that package and provide both along side each other for 
plugin authors. Or at least include both and allow the plugin authors to 
call either one they wish.

"Neither of these things seem related to whether one is a better 
solution than the other. Personally, I'd think that reliable built-in 
email capabilies would be far more important implementation details like 
that, regardless of what the solution is." -- Charles

I concur, really the arguments so far are piled on a stack of cards and 
any real developer would see the discussion for what it is. I think the 
others need to grow up and learn to face change and when it is time to 
change. It is time to call it quits for PHPMailer, and find another 
solution that is packaged with WordPress.