[wp-hackers] PHPMailer was a mistake

[Jacob Santos]

I probably should have cut this down some, but I need to provide some 
clarity.

I'm not calling out anyone's skill as a developer, just that the 
motivation is suspect for arguments against this. This encompasses the 
complete argument against what some of the core developers believe to be 
truth and lack of acceptance towards PHP 5. If there is anything that 
makes me more angry, it is when the facts are ignored. I make this 
mistake, as do all humans, but to not consider something that doesn't 
fall into some perceived paradigm is a way to never grow as a developer 
and I say this from personal experience.

Jacob Santos wrote:
> 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.

Short version: When official support by the programmers of PHP 4, 
software support should also be dropped. No, the world will not stop if 
this is not done, but if needed, older versions that still run on PHP 4 
can be maintained for a while out. Ultimately, it is up to you, whether 
you want to stay in the stone age.

While WordPress maintains its ease for end users, it is terrible, aside 
from the plugin implementation, for new developers. Tell me then, 
external libraries are for the purpose of applications to use and so 
that the application doesn't have to implement those features 
themselves. I would say that if you were to compare LOC of Swift Mailer 
and WordPress, WordPress would still be massive.

What am I saying? WordPress goes so far as to create a PHP 4 Exception 
class, that can't be handled as an exception. I suppose to get ready for 
a PHP 5 move in some distance future, but it is "interesting."

>
> 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.

I would say the same for maintaining Kses, instead of using HTML 
Purifier, which is already being maintained by another skilled developer 
who knows what he is doing. The point of using external libraries is to 
not rewrite the wheel over and over again. If a better solution is out 
there, it shouldn't be rejected for the reason that it isn't beautiful 
enough, because some components are WordPress code are anything by pretty.

>
>
> 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.

I explained this more above and below in the post, but allow me to 
iterate. If you were to do it right, you would split the Singleton into 
multiple classes and create a class library, which Swift Mailer already 
is. If you did it wrong and continued to pile methods into PHPMailer 
class, then please learn more about Class Patterns and OOP. Further, are 
you going to add features that Swift Mailer already has and pull 
resources away from WordPress development.

>
>
> 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
Short Version:
1. If this were true, then there would be issues with many more web 
applications.
2. This is invalid because not only is PHP 4 support being dropped for 
Swift Mailer, but development of PHP4 is being dropped next year.
3. Not really. It can be used to easily solve the mass mailing problem 
that plagues mail(), but it can easily be used for a replacement for 
PHPMailer and mail().
4. Wrong. Swift Mailer includes three major mailing techniques: 
sendmail, SMTP, and mail(). Two others are for load balancing, try that 
with PHPMailer.

I would not take your number 2 argument into consideration and not 
because I prefer to develop using PHP 5, but because PHP 4 is dieing and 
will soon be dead. Therefore we should stick with a crappy mail() 
replacement until you decide that enough is enough and we should use a 
real class library that actually doesn't suck?
> 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.

By your logic PHPMailer should also be packaged as a plugin, so I can 
enable it when I need a better solution. If Swift Mailer is too much for 
core, then PHPMailer is also too much, because they exist to solve the 
same problem and therefore should be able to be used one or the other 
for the solution.

Jacob Santos