[wp-hackers] PHPMailer was a mistake
dragonwing at dragonu.net
Sat Sep 15 00:05:54 GMT 2007
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.
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.
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.
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
> 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.
1. There are three things wrong with your point. The first is that half
of the statement is a matter of opinion and preference. The second is
that the last point is very rare, I've only had that problem once in all
of the years I've uploaded something and that was only a matter of
switching from passive mode to regular and uploading the files that
failed the first time. This also shouldn't be the lone reason for not
doing something as it won't effect the majority of users.
The third reason is the kicker. Are you trying to tell me that because
Swift Mailer uses a different class pattern that it is immediately at
fault? A quick code audit would have told you that a lot of the core
functionality of PHPMailer is in Swift Mailer, but correctly split into
separate classes. PHPMailer is a mess. It uses the Singleton class
pattern when it should at least, from what I've read in the comments,
into 4 or 5 separate classes.
Is object theory difficult? Hell yes, I've been researching and
developing using classes for years and I've only just recently finally
understood some of the concepts. You don't pack everything in a single
class. It is noobish and in most cases, wrong. Objects should only
encapsulate what its functionality requires. For every section of
comments, the methods below should be in their own class. Google It, and
tell me I'm wrong.
Classes should be separated, unlike the mess that is WordPress classes.
You should be able to look at the class path and be able to find the
class. This is what I've been saying! If you *NEED* documentation to
find a class, then you are doing something wrong. The benefits of
splitting the classes into their separate files, is more than this
however. It is good coding practice, because it makes it easier for
other developers, for the above and is the defined coding style of other
languages. If you don't agree with me, you *SHOULD* agree with
programmers far smarter than you and I would ever hope to even dream to be.
2. PHP 4 support is being dropped by the PHP developers, therefore your
point is invalid. Are you going to pick up programming PHP 4 for the
masses after the core developers have dropped development? It would be
pointless to continue development on a platform that is not going to be
supported. "Yes, I would like to shoot myself in my foot, willingly."
Please, WordPress should drop support for PHP 4 anyway after 8/8/08 and
you have no valid argument against this, because this is how normal
professional software development is.
Do you think software companies still develop and maintain software for
Windows 98? Nope and you'll be a fool to do so.
3. Excuse me. What about plugins? What about Subscribe2? You don't have
to support plugins, but at least don't make it difficult for those who
want a reliable mailer. By your and Matt's own admission, PHPMailer is
even more than what is required.
You are also wrong, because the whole purpose of PHPMailer is not for
core functionality, you've already admitted that it is more than what is
required, it is for external development. You are also wrong that Swift
Mailer is for mass mailers, that is not the case. It is merely a better
replacement for the built-in mail function. If you took the time to look
at what it provided or at least admit, if in fact you did more than
glance at it. You would realize that it offers enough to even replace
PHPMailer easily. Not all of the classes are required to make it work
From the documentation, it will only take 4 or 5 lines, unlike I
4. Like another person pointed out, there are many connection options
that you can use. Your argument is therefore incorrect.
Let us count up the total. Oh yeah, You're totally wrong. You lose, but
since you are a core developer, we all lose. Your opinion might matter,
because of your position, but that would only make you an ass for taking
advantage of your position. By shoving better solutions aside because of
your opinion, you have ignored facts that would better help the
community, namely the plugin one.
Lloyd Budd wrote:
> That is under consideration. 03/10/07 21:40:03 changed by ryan
> "I've been looking over swiftmailer, but it is has dozens of files
> versus phpmailer's one file. If anyone wants to experiment with
> plugging swiftmailer into wp_mail(), let us know how it goes.
> Use their php4 package rather than the php5 one."
No, it isn't, because legacy code is still being maintained. If it was,
then all of the problems (Subscribe2 as one example) that came up and is
associated with PHPMailer would have been reason enough to switch to a
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.
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.
"Neither of these things seem related to whether one is a better
solution than the other. Personally, I'd think that reliable built-in
email capabilies would be far more important implementation details like
that, regardless of what the solution is." -- Charles
I concur, really the arguments so far are piled on a stack of cards and
any real developer would see the discussion for what it is. I think the
others need to grow up and learn to face change and when it is time to
change. It is time to call it quits for PHPMailer, and find another
solution that is packaged with WordPress.
More information about the wp-hackers