[wp-hackers] PHPMailer was a mistake

[Computer Guru]

Quick question:
On every single shared host (and dedicated) I've seen, PHP was
configured to use localhost:25 no password to send email.

Assuming that the lack of an SMTP server is an obstacle, wouldn't it
suffice to have it set to localhost:25 by default?

On 9/15/07, Jacob Santos <dragonwing at dragonu.net> 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.
>
> 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."
>
> >
> > 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.
>
> >
> >
> > 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.
>
> >
> >
> > 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.
> 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.
> 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.
>
> 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?
> > 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.
> >>
> >>
> >> grtz
> >
> > 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.
>
> By your logic PHPMailer should also be packaged as a plugin, so I can
> enable it when I need a better solution. If Swift Mailer is too much for
> core, then PHPMailer is also too much, because they exist to solve the
> same problem and therefore should be able to be used one or the other
> for the solution.
>
> Jacob Santos
> _______________________________________________
> 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/