[wp-hackers] PHPMailer was a mistake

[Callum Macdonald]

Just one small point, we can quite easily add SMTP support with 
PHPMailer, so that's one less reason to switch. I wrote a simple plugin 
which adds an options page and enables SMTP to localhost 25 by default. 
Cheers - Callum.

http://wordpress.org/extend/plugins/wp-mail-smtp/

Computer Guru wrote:
> I think that's a very important point Peter raises.
>
> In reality, developers aren't supposed to do what's "right" assuming
> they're starting from scratch at this very moment, but what's right
> for the project as a whole and its users too - keeping in mind where
> you started and where you are now.
>
> Like Windows or not, the reason its so frikkin successful ATM is
> because of backwards compatibilty. Bill Gates (back in the day)
> insisted on making every verison as backwards-compatible as possible
> with the one before it - something other operating systems at the time
> did not do and it came back to haunt them.
>
> I think BALANCE is the most important thing though. As a Windows
> Developer (I know, I know...), I've come to realize that 99% of the
> problems I as a developer and many people as end users experience come
> from the fact that Microsoft is sticking to the same code it used a
> decade ago and only repairing and improving upon it. Then again, if
> they didn't Windows would never have become the number one OS it is
> today (in terms of usage, not quality).
>
> As Peter said, ********IF********* we were to start WordPress
> development today...
>
> Well, we're not and therefore there is no easy answer. Just like
> fishing, you have to reel it in some, and let it go loose some. You
> can't overhaul all the code just because something better is out
> there, nor can you ignore it all either.
>
> With regards to PHPMailer, the real question we should be asking
> ourselves isn't if Switfy is a better library than it or if PHPMailer
> really is dead. Rather we should be asking what we would *LOSE*
> switching from PHPMailer and what we would *GAIN* and comparing the
> differences.
>
> As it currently stands:
> The only thing actually *missing* from PM is SMTP support.
> We stand to break some stuff and open a whole can of worms by
> switching to Swifty.
>
> Keeping in mind that anyone who wants Swifty can install a plugin (as
> I have done), _AND_ that it's almost trivial to add proper SMTP
> support to PHPMailer, I think the LOGICAL and UNBIASED answer is to
> just give adding SMTP support to PHPMailer a shot and see how it goes.
>
> I LOVE object-orientation. I use and recommend Swifty in my own (PHP)
> projects. But I love and understand WordPress too, and the right thing
> to do ATM, regardless of which library is "better" per-say, is to add
> SMTP to PHPMailer and go from there... IMHO of course.
>
> If we open this particular can of worms, there is no end to it. Sure,
> switching to Swifty may not break that much code and may not pose a
> security vulnerability of any sorts (not that I know that for fact),
> but what comes next?
>
> WP has managed to strike a balance all these years, now is not the time to stop.
>
> Just like switching to PDO is out of the question ATM simply because
> we don't NEED it for WP to survive and the current implementation is
> suiting us just fine (more or less, all things considered), I think
> it's the same for Swifty.
>
> Hell, if you *really* want, ship a Swifty plugin with WordPress and
> have it disabled by default. Let it overwrite the entire mailer class,
> and have fun.
>
> Anyway, just my two and a half cents (inflation, you know)...
>
> -CG
>
> On 9/15/07, Peter Westwood <peter.westwood at ftwr.co.uk> wrote:
>   
>> 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/
>>
>>
>>
>> _______________________________________________
>> wp-hackers mailing list
>> wp-hackers at lists.automattic.com
>> http://lists.automattic.com/mailman/listinfo/wp-hackers
>>
>>     
>
>
>