Associated [bug tracker item]
http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=34028

@itbra i can confirm that attachments work bevor these changes using the following code on a index.php (DEV Site; Please change the example email):

$mailer = JFactory::getMailer();
$body   = "Your body string\nin double quotes if you want to parse the \nnewlines etc";
$mailer->setSubject('Your subject string');
$mailer->setBody($body);
// Optional file attached
$mailer->addAttachment(JPATH_ROOT . '/images/joomla_black.gif');
$recipient = 'myemail@example.org';
$mailer->addRecipient($recipient);
$send = $mailer->Send();

based on http://docs.joomla.org/How_to_send_email_from_components

But i will test email sending after your changes later and report it back here.

@itbra Also sending a pdf working here bevor and after the patch.

Thanks for the feedback. I wonder, why this is working with no issue for you.
However, the PR is not only to patch a specific file of this library. Moreover it is an update to the latest PHPmailer version combined with extended functionality to remove attachments.

Would you mind to test this please to push this PR to acceptance and integrate this useful functionality?

Would you mind to test this please to push this PR to acceptance and integrate this useful functionality?

Sure. But how can i test the remove attachments funktion?

After applying the PR (which will update PHPmailer to v5.2.8 and extend JMail by the new functionality) when you prepare the mailer you can remove attachments (if there are any). Just get your mailer, check for the attachments via getAttachments() and call either clearAttachments() to remove all attachments or call removeAttachment(idx) passing it the array index.
Check for the attachments again to see how it changed.

But be aware of the updated method naming in PHPmailer. It has now changed to proper camel case names beginning with lower case letters.

Also sending a pdf working here bevor and after the patch.

Yes, please report this back here and at the tracker.

But be aware of the updated method naming in PHPmailer. It has now changed to proper camel case names beginning with lower case letters.

Method names should be case-insensitive anyway, right? Then it shouldn't matter. Otherwise we would have a backward compatibility issue.

Cool @itbra here some example code with the expected result. I hope it works also for you.

Please note

1. Use your own email address
2. Make sure the example data is available.
3. The order at the email box is possible not 1,2,3

Codeexample 1

$mailer = JFactory::getMailer();
$body   = "Your body string\nin double quotes if you want to parse the \nnewlines etc";
$mailer->setSubject('Your subject string1');
$mailer->setBody($body);
// Optional file attached
$mailer->addAttachment(JPATH_ROOT . '/images/joomla_black.gif');
$recipient = 'example@example.org';
$mailer->addRecipient($recipient);
$send = $mailer->Send();

Expected Result

Email with one attachment (joomla_black.gif) and subject: "Your subject string1"

Codeexample 2

$mailer = JFactory::getMailer();
$body   = "Your body string\nin double quotes if you want to parse the \nnewlines etc";
$mailer->setSubject('Your subject string2');
$mailer->setBody($body);
// Optional file attached
$mailer->addAttachment(JPATH_ROOT . '/images/joomla_black.gif');
$mailer->addAttachment(JPATH_ROOT . '/images/joomla_green.gif');
$recipient = 'example@example.org';
$mailer->addRecipient($recipient);
$mailer->removeAttachment(0);
$send = $mailer->Send();

Expected Result

Email with one attachment (joomla_green.gif) and subject: "Your subject string2"

Codeexample 3

$mailer = JFactory::getMailer();
$body   = "Your body string\nin double quotes if you want to parse the \nnewlines etc";
$mailer->setSubject('Your subject string3');
$mailer->setBody($body);
// Optional file attached
$mailer->addAttachment(JPATH_ROOT . '/images/joomla_green.gif');
$mailer->addAttachment(JPATH_ROOT . '/images/joomla_black.gif');
$recipient = 'example@example.org';
$mailer->addRecipient($recipient);
$mailer->clearAttachments();
$send = $mailer->Send();

Expected Result

Email without attachment and subject: "Your subject string3"

@Bakual

Method names should be case-insensitive anyway, right?

I think you're not right. There are many method names in camel case format like e.g. setSender(), setBody(), etc. They are in fact case sensitive. PHPmailer used to name its methods like e.g. SetSender(), SetBody(), etc., which is case sensitive as well and doesn't meet common naming conventions. This has changed and all method names now start with lower case letters as per convention.

The names of the wrapper methods of JMail were not touched. In fact i updated only the names of the PHPmailer methods called by the wrapper methods like e.g.:

JMail::__construct()
{
   . . .
   $this->SetLanguage('joomla', JPATH_PLATFORM . '/phpmailer/language/');
   . . .
}

was changed to

JMail::__construct()
{
   . . .
   $this->setLanguage('joomla', JPATH_PLATFORM . '/phpmailer/language/');
   . . .
}

So, as long as the PHPmailer functions are called through the corresponding wrapper method of JMail there shouldn't be any backwards compatibiliy issues. However, when calling methods directly on PHPmailer there will be compatibility issues. It might be possible that a user wants to call a method not yet wrapped by JMail. To prevent this kind of issue JMail should wrap most required functionality. I found the removal of attachments a required functionality missing so far and decided to add it to JMail to circumvent potential issues by forcing users to call these methods directly on PHPmailer.

@zero-24
Thanks for testing and your feedback.

I think you're not right. There are many method names in camel case format like e.g. setSender() , setBody() , etc. They are in fact case sensitive. PHPmailer used to name its methods like e.g. SetSender() , SetBody() , etc., which is case sensitive as well and doesn't meet common naming conventions. This has changed and all method names now start with lower case letters as per convention.

I think I read that PHP doesn't care. You could call the method using $mail->SeTsEnDeR() and it would work. But I honestly never tried it myself.

So, as long as the PHPmailer functions are called through the corresponding wrapper method of JMail there shouldn't be any backwards compatibiliy issues.

I think it's almost certain that someone uses it directly. Even if it's bad practice to do so.

@Bakual
Would you mind to test this PR and report back here as well as to the bug tracker? I'd love to see it merged.

Is

protected function add($recipient, $name = '', $method = 'AddAddress')

what you want, or rather now:

protected function add($recipient, $name = '', $method = 'addAddress')

Tests use 'AddAddress', 'AddCC', etc.

@infograf768
Not sure if i got you the right, but if you mean to have this proxy method doin' all work regarding adding something to the mailer, then what about the setXYZ- and removeXYZ-methods?

Actually this kind of proxy methods would be nice to have for all the functionality of PHPmailer. This would ensure that no important accessor was unaccessable through JMail.

If this is not what you mean, could you be more specific, please?

Side Note
While i was thinking about the proxy accessors and changed naming in class PHPmailer and viewing the methods of class JMail i noticed, that every instance of JMail now has access to both mehtods (if there are). Every instance of JMail should now have a function send() (method of PHPmailer) and a function Send() (method of JMail). I did some testing on this topic and found that method naming case in fact doesn't matter.

What should i/we accordingly do now? Revert all changes regarding cases of called PHPmailer methods? Or leave the changes just to reflect the changes in PHPmailer indicating it now follows common naming conventions?
As changing the cases has no impact on backwards compatibility i'd plead to keep the updated cases to reflect PHPmailer's intention.

What do you guys think and suggest about it?

What should i/we accordingly do now? Revert all changes regarding cases of called PHPmailer methods? Or leave the changes just to reflect the changes in PHPmailer indicating it now follows common naming conventions?

Leave the changes in. They're fine.

@itbra & @Bakual It is correct that PHP doesn't care about the case of the method name. I read the same thing and tested it with this PR. Mails are sending fine if I change the case. So that is not an issue.

@zero-24 for the great test instructions

@test: Works perfect. I received all 3 mails as expected with the correct attachments.

Thanks for testing and reporting, guys!

Merged into 3.4-dev. Thanks!