[6.2] MailTemplate should work with interface

[laoneo]

• I read the Generative AI policy and my contribution is either not created with the help of AI or is compatible with the policy and GNU/GPL 2 or later.

Summary of Changes

The MailTemplate class should work with an injected MailerInterface and not concrete implementation to be more flexible. Additionally this pr deprecates the optional parameter to be able to remove the deprecated Factory usage.

Testing Instructions 1

• Log in on the back end
• Got to the global configuration server tab
• Send a test mail

Actual result BEFORE applying this Pull Request

Mail is sent.

Expected result AFTER applying this Pull Request

Mail is sent.

Testing Instructions 2

• Log in on the back end
• Set HTML as mail format on /administrator/index.php?option=com_config&view=component&component=com_mails
• Create a new user and enable Receive System Emails
• Create a GET request task with the url https://downloads.joomla.org/api/v1/latest/cms and Manual execution as Execution Rule
• In the advanced tab of the task form enable success notification and the respective user group from the previously created user
• Save the task
• Click on the "Run Task"

Actual result BEFORE applying this Pull Request

Mail is sent with attachment in HTML format.

Expected result AFTER applying this Pull Request

Mail is sent with attachment in HTML format.

Link to documentations

Please select:

• Documentation link for guide.joomla.org:

• No documentation changes for guide.joomla.org needed

• Pull Request link for manual.joomla.org: MailTemplate should work with interface Manual#620

• No documentation changes for manual.joomla.org needed

[CSGoat0]

I have tested this item ✅ successfully on a59506a

I followed the instructions, everything works fine.

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/47677.}

[exlemor]

I have tested this item ✅ successfully on a59506a

I have tested this successfully! Thanks @laoneo!

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/47677.}

[richard67]

RTC

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/47677.}

[MacJoom]

Please check

[joomdonation]

I would question about the valid of this PR. Maybe someone with stronger OPP background should look at this more carefully

• You modified code to allow using MailerInterface but in the code of MailTemplate class, you have code to check for a concrete implement. Is MailerInterface incomplete ?
• In terms of features, although the intent is support MailerInterface, any implementation which is not Mail class will loose the functions provided by MailTemplate (because you hard code the check with a concrete implement before calling certain code):

• Loose the feature to use custom SMTP parameters for each mail template
• Lose the feature to handle attachments as string

[laoneo]

All it does is to support the interface and doesn't restrict to the Mail class as we should work with interfaces. If you need these parameters like isHTML, then extend from Mail class. But there is no point to not work with interfaces. If I have a plugin which redirects everything to a custom Mailer service or whatever, there is no need to configure SMTP, etc. This brings a lot of flexibility while not loosing any settings from before.

[joomdonation]

I think it just a fake support to interface because if you pass any implement of the interface which is not a Mail instance, you will loose the features of MailTemplate which I mentioned earlier. Plus the support interface while having to check for concrete implement seems not right to me.

That's what I see from looking at the change in this PR. I will leave it to other maintainers and release managers to look at it further and make final decision.

[laoneo]

Due all respect, but your comment doesn't make sense at all. This is how support for the interface should be implemented in a backwards compatible way. Mailer instances which come from the factory doesn't have to be always a Mail class. If a plugin would implement it's own mailer (which is not a Mail class) and set it in the global container, then this code would badly break. When this gets merged, then we can convert the rest of the code away from Factory::getMailer, otherwise we will have to life forever with it.

[joomdonation]

Sorry, I do not see the point of supporting interface if it causes loosing features of MailTemplate. I have expressed my concerns in my earlier comments, it's normal that you do not agree or I am wrong. Let's wait for feedbacks from others.

[laoneo]

No problem, don't expect it either.

[MacJoom]

I would like to have two new tests @exlemor , @CSGoat0 - with Html tested.

[richard67]

Back to pending. See previous comment.

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/47677.}

[MacJoom]

Please test attachments too.

[laoneo]

I'v updated the testing instructions with HTML and attachment test.