Yeah, took me a minute to track down too since it was rolled up with the PSR-2 changes.Mixing code format changes with actual functional changes...I've noticed an error in the attached diff in the file names - still using Word Press convention in pluggable but files not renamed in the PHPMailer Auto Loader.I've amended the pluggable name and the new attached patch works for me. Contributors live all over the world, so there are discussions happening at all hours of the day.Our core development meeting is every Wednesday at UTC in the #core channel on Slack.
This would avoid any file changes from upstream, and even though we also strip extras, languages, POP3, and all other package files, it still benefits from being moved. @nacin, how about pushing to a subfolder, and still just sticking with the following files: LICENSE (since it is LGPL, not GPLv2 - probably should be included), class.phpmailer.php, php, and PHPMailer ? If I can draw every bodies attention to the 3 questions I raised when opening the ticket - I believe this proposed solution provides a reasonable answer to 1 and 2 and answers question 3 with a reasonable response.As suggested in ticket #25014 I am opening a new ticket to where we can review the inclusion of PHPMailer libraries in Word Press (possibly from 3.8). I'll be back to this for a deeper review later here, likely adding some back compat API to go with this, but just some quick notes for now: (1) Yes, I think it's time to move this to it's own folder since we're being pushed to add new file(s) for the first time in years.Things I think we need to consider: 1/ PHPMailer uses an Auto Loader that needs including now, should we move to a sub-folder like other external libraries to aid file management as we now have 3 or more files to manage 2/ Should we keep with the '.' file notation of PHPMailer now or continue renaming and editing files using Word Press '-' notation. (2) The only reason we keep renaming these files was for back compat purposes, and if this is moved to a new folder, we'll just end up either deciding to break this, or adding a bare placeholder include file in it's place.I doubt they will accept a PR to remove the autoloader check because it would be trivial to subclass PHPMailer and just not call the parent constructor.It seems forced to me, what they're doing, but I guess it is for backwards compatibility reasons, so I can only complain so much. Considering it is basically the entire constructor, this is not (yet) difficult to maintain.