Ticket #937 (closed defect: wontfix)

Opened 3 months ago

Last modified 3 months ago

100k PHPmailer should be a plugin and not in the core

Reported by: _ck_ Assigned to:
Priority: low Milestone:
Component: Back-end Version: 1.0-alpha-1
Severity: minor Keywords:
Cc:

Description

I could not disagree more with putting big, bulky and slow PHPmailer in the core when 99% of installs will not need it's functionality.

The email functions are in pluggable.php for a reason, any replacement should be a plugin.

If you insist on including it, it should at least be in bb-plugins with the bozo and akismet plugins so I can disable it.

What if people want to use Swift Mailer instead?

Please roll back the old mailer in pluggable so it keeps the core size small and light.

Change History

08/19/08 09:37:48 changed by csseur3

i'm agree with you _ck_ :p

08/19/08 11:38:22 changed by fel64

Shouldn't email functions be outsourced into backpress?

08/20/08 00:09:50 changed by sambauers

  • version set to 1.0-alpha-1.

PHP Mailer is in BackPress.

It is only loaded when an email is sent, so it doesn't really increase the footprint for the vast majority of page loads.

To replace it with Swift Mailer you can re-define bb_mail() in a plugin. That is the only place it is included.

The version we have added to BackPress is really well tested as it has come from WordPress, and we have had lots of issues with the previous implementation.

If/when BackPress is utilised in WordPress, this library would be included at that time anyway.

08/20/08 00:44:12 changed by sambauers

  • priority changed from high to low.
  • severity changed from major to minor.

08/20/08 08:15:06 changed by _ck_

I still don't understand why it's included by default in BackPress when most users won't be using it. Shouldn't the 1% with hosting issues be the ones required to bulk-up only their install with additional code?

What happened to the concept of lightweight?

A fully integrated install of bbPress 1.0 with WordPress 2.6(even using the shared BackPress core) plus plugins will be over 1 meg of PHP code per instance - 100k of additional code is significant, especially if on a NFS filesystem that's slow to respond (like Dreamhost).

When bbPress is enhanced with plugins to perform typical forum behaviors like sending emails when new users sign up or emails when new posts are made in tracked topics, emails happen much more often than you'd think, especially on a busy site.

08/26/08 21:21:12 changed by mdawaffe

  • status changed from new to closed.
  • resolution set to wontfix.
  • milestone deleted.

I agree that PHP Mailer is not perfect, but PHP Mailer is proven to be a better solution than bbPress' old mail() solution. WordPress made a similar transition (also not without controversy).

As an anecdote, I recently used PHP Mailer's SMTP wrapper to send hundreds of thousands of emails over a short period of time and have since improved my code (not PHP Mailer's) to speed up that process by a multiplicative factor.

PHP Mailer is never loaded unless you're actually sending an email. If you plug bb_mail() as a Swift Mailer wrapper or a mail() wrapper, PHPMailer will never be loaded.

Including this "100k of additional code" in the distribution does not impact page load times, memory usage, or any other efficiency measure: the file is almost never loaded. There may be 1M of PHP files per install, but not all of that is loaded for any given page load. We could package bbPress with a 30M how-to video and similarly not effect your site's performance.

Also, you don't know that you're one of the "1% [of people] with hosting issues" until it's too late: your users can't login because they never got an email.

If bbPress is plugged or enhanced to send more emails, and someone demonstrates that PHP Mailer truly is slowing things down, and that an alternative exists with the needed features and cross-compatibility, we can decide to use something else.

Until then, you can always plug bb_mail() to use something that better suits your needs.

Marking this as wontfix for now. Let's address this again when we get real world data.