Make WordPress Core

Opened 10 years ago

Last modified 4 years ago

#28618 new enhancement

Allow PHPMailer class to be reliably overriden

Reported by: leewillis77's profile leewillis77 Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version: 4.0
Component: Mail Keywords: has-patch
Focuses: Cc:

Description

The WordPress unit test suite currently overrides the global $phpmailer variable with its own MockMailer class. (See https://core.trac.wordpress.org/browser/trunk/tests/phpunit/includes/bootstrap.php#L48)

This achieves the desired effect, but is potentially unreliable.

If the global $phpmailer object gets unset, or overridden (For example by a buggy, or otherwise badly behaving plugin), then the code in wp-includes/pluggable.php will create a new instance of PHPMailer without any way for code to override that - see https://core.trac.wordpress.org/browser/trunk/src/wp-includes/pluggable.php#L264

The end result would be that a site that shouldn't be sending emails will potentially become one that will.

Potential patch attached. This includes the change to pluggable.php to filter the object after creation, and addition to the test suite to use it.

Attachments (1)

28618.diff (1.8 KB) - added by leewillis77 10 years ago.

Download all attachments as: .zip

Change History (5)

@leewillis77
10 years ago

#1 @nacin
10 years ago

  • Milestone changed from Awaiting Review to Future Release

I don't hate this, so that's good. :) Will want some other feedback.

Another option: Note that this object does basically nothing on construct so we could probably just always construct it and work around it in our tests some other way.

#2 @chriscct7
9 years ago

  • Keywords has-patch added

Patch still applies but per comment:1 needs adjustment

#3 @desrosj
4 years ago

  • Keywords needs-refresh added
  • Milestone set to Future Release

28618.diff needs to be refreshed, and the comments above still need to be addressed.

#4 @leewillis77
4 years ago

  • Keywords needs-refresh removed

I'm not clear that the patch does need to address the comments in #1. They are a potential improvement over-and-above this change, not critical to the actual issue (unless I've misunderstood)?

Note: See TracTickets for help on using tickets.