On 2013-11-18 1:07 AM, Matthias Paul wrote: Have you tried using $wgSMTP?

It should be. A quick ack/grep doesn't show anything else.

Yes that hook allows an extension to override the mail()/PEAR::Mail handling and implement an alternative mailer backend. Not that I know of. But it would be a nice project. PHPMailer is pretty nice, it's even in composer too. Which makes me a little happy, while also reminding me that someone has made a "feature" our lack of a composer.json file – which we could otherwise have put a PHPMailer into, incorporated composer into the release process depending on libraries directly, and not having to go and shove a big blob of 3rd party code into our codebase with absolutely no handling for when it becomes outdated.

Nah it's just another part of MW that is legacy code with a bit of NIH sprinkled on it. ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]

On 2013-11-18 4:42 AM, Matthias Paul wrote: Go ahead and try $wgSMTP, I'm not telling you not to use PEAR-Mail. Library wise PHPMailer is better than PEAR-Mail, but PEAR-Mail still works fine. Our code in this area IS legacy, but PEAR-Mail does work. So go ahead and use PEAR-Mail if it works. Using the PHPMailer instead of mail() or PEAR-Mail is just a backend technical detail relevant to developers writing MW core. It's not relevant to simply running a wiki. Even if you started using $wgSMTP now and in the future we decided to overhaul includes/UserMailer.php to completely use PHPMailer instead it would be completely backwards compatible. Your wiki would continue to seamlessly run even after you upgraded. If you've got an issue of not being able to use the PEAR tools it should be possible to use it. PEAR-Mail is simply required from the install path. So you can just download PEAR-Mail from PEAR's website and dump it somewhere in the install path. You can either modify the install path using LocalSettings.php to include the directory PEAR-Mail is inside or dump it into a directory that is already on the install path (eg: I'm not sure but $IP might be in it. If so you could just dump it alongside the MW code.) Yes, composer is a dependency-management tool, but for PHP libraries. Using it we'd have a composer.json file that listed PHPMailer and a version as a dependency and running `{command to execute composer} install` would install/bundle PHPMailer locally and also allow you to update it and monitor it for updates. For MediaWiki releases we'd incorporate that composer run into the release process so that tarball users still have every library they need out of the box. You can ignore my comments about it, I'm just griping about something semi-relevant to the idea of incorporating PHPMailer directly into core. If you wanted to implement PHPMailer in an extension, yes the extension would *use* the AlternateUserMailer hook. By registering a hook function using $wgHooks or Hooks::register. And then implementing the code to send the email using PHPMailer instead of PEAR::Mail or mail().So far, thank you for your answers :) ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/] _______________________________________________ MediaWiki-l mailing list MediaWiki-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l