that a cool feature!

Instead of using a table, can we not work with plugin events to collect the available mail templates? It would make the thing more dynamic as often the strings are not static.
As components, which do have that functionality already self made, in their submenu and custom fields and categories are there too, would it be possible to offer mail template menu links for a component. The idea behind it is that people install a component and then do set it up. So it would be good when they do not have to leave the context of the component and do navigate away from it to set up the mails.

Beside that I really like that feature!

@laoneo I thought about several ways how to do this, but storing the templates in a table is the only thing that doesn't escalate into a horrible abomination of system. If you are talking about the available tags: You can already extend those via a plugin event when sending the mails and I'm working on adding the event when rendering the tags.

Ok, I did some more work and you should be able to save the changed templates now. Unfortunately I have some issues with the sessions and I'm getting kicked out of my installation on each click... idk. Anyway, it would be nice to get some feedback from you guys now.

When editing a template, somehow I got a broken editor, not sure if it related to the PR.

Sending cannot test currently, have to fix my email config.

The broken editor is a general issue when you have 2 different editors on the same page. That is something that we have to look into in another issue.

Pretty sure that was resolved in J3

So I have tested (Text version) and it looks good to me (except broken editing of HTML version).
I was able to add custom Tags via plugin events, and all worked:

/**
 * @param string    $mail_id
 * @param CMSObject $mail
 */
public function onMailBeforeTagsRendering($mail_id, $mail)
{
  if ($mail_id === 'com_config.test_mail')
  {
    $mail->params['tags']['beer'] = 'beer';
    $mail->params['tags']['bear'] = 'bear';
  }
}

/**
 * @param string       $mail_id
 * @param MailTemplate $mailTemplate
 */
public function onMailBeforeRendering($mail_id, $mailTemplate)
{
  if ($mail_id === 'com_config.test_mail')
  {
    $mailTemplate->addTemplateData(array(
      'beer' => 'Beeeer',
      'bear' => 'Beeeeaaaaaar'
    ));
  }
}

Couple notes:

• How the extension can add its own template? I think that forcing them to use SQL is not gut idea.
• Would be cool to have "send test" button, while editing the email
• Not very understood how multilanguage will work, if user will add some more languages on the site

Fix for Multiple editors #22341

What about the possibility to offer components to add the mailer list to their submenu? People install an extension and then they want to set it up. Editing mail templates is one task of it. Like it is now you have to go to a menu item buried somewhere in the system menu. Similar to what we have now with categories and fields. The user can stay in the context.

Beside that I really love that functionality. Code review will come later, except that I would move the it to com_mailto.

@Hackwar did you see my comments? Would love to proceed with this one.

@laoneo I'm torn on your proposal. I understand your proposal, but I do have two issues with going that way. The first is, that there are components that only send one mail (com_config, com_joomlaupdate) and it is pretty much overkill to have an extra submenu entry, list view, etc. for just this one mail template and the second is that this would only work for components. But I want this to be also used by plugins. For example, a customer of mine uses a plugin to send a mail to a user when the user is deleted. I don't know how that one would be accessible via the GUI for a plugin.

Maybe we can simply keep it the way it is now and add a second mode, where it filters for a certain extension and displays that extensions submenu when called by a specific parameter? That could be implemented in a second step when this one is merged.

What about the possibility to offer components to add the mailer list to their submenu?

I am agree with @Hackwar , this not really need for now, just a filter can be enough.
And I think it will be not that often used thing, like tags or fields.
Just an one more configuration possibilities.

So at least filters should be added before merging.

Filters have been added. Please consider this for merging and then we can add a bunch of other templates to this and add more features...

I've basically started over with this PR and did a lot of changes. There are still a few JS issues in the edit screen, where I would kindly ask for some help. I'm just not really a JS guy. Please read the initial text of this PR to know about all the changes that I did.

@Hackwar do as you can, then write what issue you have with JS, and I will try to help when will get some time

@Fedik The switch to enable/disable the input fields when editing a mail template don't work right and you can click on a tag and it is added to the input field, even though they are disabled.

I have no idea how we can add the nested tags in a good way into the UI. Maybe that is really something for a future PR... I also don't know how we can handle the same tags in plaintext and html. I'm open for suggestions (and contributions to this PR)

I had a quick look at the PR and have few feedback/questions:

1. Look like we removed two fields custom_data, system_data from #__extensions table, so the installation SQL in this PR won't work. You need to remove two fields from INSERT command

2. The code in edit, save methods of TemplateController and getItem, save methods of TemplateModel is almost the same/duplicate code of it's parent class. Why is that? I guess it's because you don't use id as primary key of #__mail_templates table instead of using id as most of Joomla tables. Personal, I don't like these duplicate code, so unless there are special reason, I would use id as primary key to remove these duplicate code.

3. We would have to find out how to handle multilingual website. From what I see, for each language, we need one record for a mail template. So how we populate these records on install? And how when user installs a new language to the site?

4. I have the feeling that the MailTemplate is doing more than it needs. I could not think of a case when I could define attachments, BCC/CC emails... when the mail template is inserted into database. If I have to add attachments, I would do that in $mail object before passing it to MailTemplate, same for BCC/CC emails. These data usually dynamic data, not static.

These are few minor issues with the code, but I will review it later, depends on the decision for #2

to 1. I will have a look at that.

to 2. That is related to using a master template and then the different languages. The key for a template is always the identifier com_config.test_mail and then the language. I don't like that duplicate code either, but it is far better than the alternative of introducing an unnecessary integer ID here.

to 3. This IS ready for multilingual websites. Each mail template in the beginning consists of a master template that has translateable language strings. If there is no language specific mail template, then it will use the master template and simply translate the language strings. You can then go and edit the master template for a specific language and save that and it will generate a language specific template. That is why there are switches next to the subject and bodys. You can switch using those language strings or your custom template on or off.

to 4. The static attachments is aimed at shops, etc. which want to send out their ToS as a PDF via mail. I could come up with several more scenarios. The BCC I personally would use to have a log of the mails that my system has sent out and to be able to test this over a certain period of time.

Hello Sorry I'm jumping on this a bit late. There is a PR we are currently working on to merge our tj-notifications system in Joomla to allow easy editing of all system emails and provide a centralised notification system. My Original detailed blog on this is lost as it was hosted on joomla.com and i missed renewing it :( .

However the GitHub can be checked here : https://github.com/techjoomla/TJ-Notifications/wiki This is in use now for 2 odd years in production and is pretty stable..

There is a little bit of an overlap on this PR on it. In this PR we would simply need to add the Notification magic method in all places that currently triggers an email. This will allow further extension to notifications via SMS, Push etc.

In addition to the notifications, I would also be willing to donate the code of Email Beautifier/TJNotifications (or merge it in this PR to bring any features we have there that are missing here).

cc @manojLondhe @techjoomla @coolbung

I tried to use patch tester to install this and I got this message ×
Error
The file marked for modification does not exist: administrator/components/com_config/Model/ApplicationModel.php

Are you using this on a Joomla 4.0 installation?

Are you using this on a Joomla 4.0 installation?

Ah of course, whoops

@Hackwar please look Hackwar#26

A note: I would remove MailsHelper::mailtags (it hardcoded HTML) and use a "sub template" instead (eg edit_mailtaglist.php).

One issue still left, with HTML Body editor. If it initialized as Disabled it not possible to enable it (and vice versa), we do not have an API for it.
Maybe we can leave it always enabled (on initial state) for now or? And use PHP to prevent of saving changes if "switcher == 0"

please, add my AMP-mail feature request #24393

Your request has nothing to do with this PR and is completely unrelated. You also already got a decision in your issue regarding that.

I installed via patch tester and then I also discovered com_mail but when I go to the system link it says 404 component not found. Did I do something incorrectly? Also the language string under system is broken. I don't find anything in components only in system, but I think that is right according to the PR?

This PR has unfortunately gathered some dust in the last few months... Today @wilsonge and I tried to make it all work again and we partially succeeded. The component works 98%, but there are 2 issues remaining that I can't fixed:

• The switcher elements have a legend attached to them, which I'd rather have not visible. How can I remove that? @brianteeman?
• The WYSIWYG editors (or specifically TinyMCE) don't react on the change to the underlying textarea element. So switching the field on or off does not work. I don't know how we can best implement this. I would actually expect that a change to the readonly attribute of a textarea results in the editor making this editable again.

If someone could help out with this, I'd be really happy.

The switcher elements have a legend attached to them, which I'd rather have not visible. How can I remove that? @brianteeman?

@Hackwar are you referring to this

Thats because you dont have a label in the xml.

Please don't do this. At a minimum it should be just the text. If you want to add a flag as well then it must obey the setting in content_languages

The switcher elements have a legend attached to them, which I'd rather have not visible. How can I remove that? @brianteeman?

@Hackwar are you referring to this

Thats because you dont have a label in the xml.

When I'm adding a label, it is still displaying that label. I don't want to have anything there, just the switcher.

How would anyone know what the switch is for?

Not sure I understand all of this, as it looks pretty hard for non-coders to create their own mail template, but here is a remark concerning language based on the example proposed for send mail test.

Using type="contentlanguage" looks wrong to me because we may have a site with multiple languages but NOT set as a multilingual site, i.e. where the Content Languages have been deleted because they are useless (thereefore no specific flag or sef).

In the case of sending test mail, which is done from backend, it should imho just depend on the admin language in use. Therefore filtering by Content Language as well as using getContentLanguages instead of getInstalledLanguages with client administrator is wrong.

Hint: see isAdminMultilang for admin modules.

There is no interest in letting normal users create their own templates. This is a way for an extension to allow for complex mails with translated content. You can edit existing templates, not create new ones.

We don't know if a template is used in the frontend or backend when editing the template. So I wont know if to use isAdminMultilang. The same issue is with the contentlanguages vs installed languages. I have to choose one of the two for the form XML and as we had this discussion in the past, I chose the content languages, among other reasons because you might have several content languages for one installed language.

I chose the content languages, among other reasons because you might have several content languages for one installed language.

It is wrong in this test case as I clearly demonstrated.
Never heard of anyone keeping content languages and only one installed language for ever: this makes no sense at all and would be totally useless.

Now that you have added labels I am even more confused about what they do

Now that you have added labels I am even more confused about what they do

How about you click them?

Now that you have added labels I am even more confused about what they do

How about you click them?

You shouldnt have to in order to understand their purpose. But I will install the branch and look

maybe something like "Customize HTML body" or "Edit HTML email" can be better for label?
or "enable editing"

I think the best solution would be to write a ten page essay as label...

Might have helped me if I had noticed that there was some JS in this PR - oops

Edit Subject yes/no
Edit Body yes/no

@brianteeman email has 2 body, for a plain text and for a html.
"Edit Body yes/no" maybe not enough

Edit Subject yes/no
Edit Body yes/no
Edit HTML Body yes/no

done

Thanks

It should not depend on Content Languages

I can understand a reason why it made like that.

@Hackwar @infograf768 what do you think about next approach:

• by default the template sets to all languages, language = *
• inside the template allow to use placeholders like {TEXT:FOO_BAR_LANG_STRING} for translatable strings, eg:

<h1>{TEXT:HELLO_USER}</h1>
<p>{TEXT:WELCOME_MESSAGE}</p>

In theory it will allow to simplify the thing for Users a bit, will use a default (active) language, and will separate Site/Admin.

Is it will be hard to implement?

I wonder if you guys actually looked at this in depth. You don't have to create any templates at all, because it will always fall back on a translation string. IF you create your own template, it takes that translation string, translates it and prepopulates the respective input with that. In that translated string, you already have placeholders for the actual data. You can then reorder that whichever way you want or add it multiple times. It even contains the code to use subtemplates, even though that is not available via the GUI yet. Something for 4.1 or 4.2.

I don't see any reason to change it to what @Fedik described above.

The one thing that is missing to make this truly useful is the ability to send yourself a test email

The one thing that is missing to make this truly useful is the ability to send yourself a test email

Seems slightly non-trivial because you'd need to manually add all the data that can be injected with tags into the body of the email.

@Hackwar Is this ready for testing? If so, could you please resolve the conflict?

Conflict fixed. As far as I'm concerned this will do for feature completeness for now. I kind of agree with @brianteeman 's comment about test mails but also understand that it can be complicated for this and am happy to leave this for a future Joomla version.

I believe the only thing left here beyond testing is to make a final call whether to use content languages or installed languages for the emails (I leave that to people who actually build multilang sites) - probably one for a Production Department call @HLeithner ?

@wilsonge For me, a test email doesn't need actual values, in general you just want to see how the mail will look like.

You still need some sort of value however which is going to be context specific

@wilsonge Did you fix the issue with the HTML editor enabling/disabling?

I believe the only thing left here beyond testing is to make a final call whether to use content languages or installed languages for the emails (I leave that to people who actually build multilang sites) - probably one for a Production Department call @HLeithner ?

My opinion is that it should be content specific but last time I tried (it's a long time ago) content languages with out a similar installed language doesn't work properly so I didn't used it.

Having here the "Pizza-Bugs-and-Fun" with @roland-d I tried to get this PR tested. However, I had a clean installation of Joomla 4 and applied the patch. First, the extension didn't get corrected installed, i.e. the mysql DB was not updated correctly, when I opened http://localhost/joomla-cms3/administrator/index.php?option=com_mails&view=templates locally this error appeard.

I updated the DB myself but then this error appeared:

What can I do to get the patch run?

Thanks

@Hackwar I sent PR Hackwar#33 to fix the SQL errors.

thx @roland-d

You should add to the test instructions that you have to delete the autoload_psr4.php file (/ libraries) and the Javascript files have to be rebuilt (npm run build: js)

Merging this as a starting point as the basics work. I fully accept there needs to be some work here as we move through getting 4.0 to stable. Personally for example the way if you enable html mails don't show the text at all for the sample mail is confusing (although having dived through the code I think I finally understand the logic of why). So let's start with this get some user testing done as it ends up in the nightlies and see how things go.

Thanks @Hackwar

hello thanks for this great feature a question, no plan to use with new workflow system ?
link transition action to a specific email template will be a great function
both feature will be improve and polished
thanks @Hackwar

No, right now the workflow is not implemented here. I'm open to improve this in the future; for 4.0 I would keep it the way it is and postpone this to 4.1 or similar.

ok cool ! thanks i will be a great function !!!