[wp-hackers] PHPMailer was a mistake

Sat Sep 15 19:01:43 GMT 2007

Exactly! :-)

On 9/15/07, Callum Macdonald <lists.automattic.com at callum-macdonald.com> wrote:
> 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
> >>
> >>
> >
> >
> >
>
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>


-- 
Computer Guru
Director,
NeoSmart Technologies
http://neosmart.net/blog/