[wp-hackers] PHPMailer was a mistake

[Computer Guru]

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
>


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