[wp-hackers] PHPMailer was a mistake
peter.westwood at ftwr.co.uk
Sat Sep 15 11:39:40 GMT 2007
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
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
>> 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/
(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.
This doesn't lead me to anywhere near the number of classes provided
>> 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.
> Short Version:
> 1. If this were true, then there would be issues with many more web
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
> 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.
Peter Westwood <peter.westwood at ftwr.co.uk>
WordPress Plugins: http://blog.ftwr.co.uk/wordpress/
More information about the wp-hackers