[wp-hackers] PHPMailer was a mistake

[Peter Westwood]

On 15 Sep 2007, at 07:36, Jacob Santos wrote:

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

WordPress is designed to be easy to use and install for end-users.   
Therefore we have to support the installed base of software (mysql/ 
php/etc) not what the "manufacturers" of this software say we should  
support - in $dayjob we have learnt this the hardway our customers do  
not have the money to upgrade to the latest and greatest version of  
windows - therefore even though Microsoft may not support a Windows  
version we need to support our customers in the best possible way.

We should only ever deprecate  support for a version of PHP / mysql  
on technical reasons - this is the kind of sound technical judgement  
we as a development community have to take.

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

So all the OO Code written in C in the Linux Kernel is just wrong is  
it.  Using the features of the language in a way which fits in with  
your programming paradigm is sound development practise.

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

 From what I know HTML Purifier and KSES don't do exactly the same  
thing - the biggest problem in switching to HTML Purifier over KSES  
is proving that it doesn't open any security holes.  You don't change  
something that isn't broken.

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

As someone who spends all day at $dayjob writing highly OO code I  
don't agree with you here - once of the biggest mistakes that nieve  
OO developers make is to spilt there code into too many classes.

Classes need a purpose - creating more just to split out the code  
does not make good OO practise.

If I was to sit down and design an OO model for sending email then I  
can see myself coming up with the following class structure:

A Class to represent an EMail - accessors and mutators for all the  
common parts of an email - To/From/CC/Subject/Body/HTML Body/ 
Attachments etc.
(If i wanted to process incoming emails then I would ensure this  
class could successfully parse as well as generate emails)

In my first design I suspect that sending and email would just be a  
case of calling a method on the email itself.

If I wanted to enhance this design and abstract away the sending then  
I would probably create an interface for mail transfer and create  
implementors of these for the transfer methods I had in mind - e.g.  
mail(),smtp etc.

This doesn't lead me to anywhere near the number of classes provided  
by swiftmailer.

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

This is a problem - our user base have trouble uploading files - this  
is something we have to be aware of and need to include in our  
decision making process.

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

As I said above - we want to support our user base - not alienate  
them - when PHP5 is the standard for webhosts then we can consider  
dropping PHP4 support - until then there is no technical reason to do  
so.

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

So it does - but why does the simple example code not use mail() then  
- afterall that would be the simplest way of using SwiftMailer and  
require the least code.

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

If we were to start WordPress developement now then PHP5 would  
probably be the way to go - we could write something much more OO  
(like Habari maybe ;-))

Our roots are PHP4, we have endusers running on PHP4 - we don't want  
to alienate them or hold them to ransom.

westi
-- 
Peter Westwood <peter.westwood at ftwr.co.uk>
Blog: http://blog.ftwr.co.uk/
WordPress Plugins: http://blog.ftwr.co.uk/wordpress/