@wilsonge That's the least of the problems with the UX/UI of this component

To be brutally honest this shouldnt have been accepted. As it is right now its no where near ready for real world use. To the best of my knowledge there has never been a request for this type of feature for the core messages and for those that really wanted it then there are extensions.

... in terms of getting J4 out of the door there is nothing lost by removing this feature at this time. It can always be put back into 4.1 when it is ready.

this feature at this time is beter put back into 4.1 when it is ready

maybe time to create issues or milestone J4.1 and move it there?

but I have no knowledge of how much users needs this feature, if people need it a lot it should be in j4

I'm not planning on removing it right now. For now this issue and #26489 are what I'm interested in fixing. If you want to submit issues on anything else related to mail templates please submit an issue and I'll prioritise it

The most confusing thing in it is the multilanguage handling being completely different to everywhere else.

And that's in issue #26489 so please let's not pollute this issue with other issues already tracked ;)

I wouldn’t say one post as reminder is pollution, especially as the issue you mentioned handles only parts of the multilanguage stuff.

@wilsonge Good luck with fixing both of these issues. They are caused by the fundamental design of this component and not something that can be easily fixed. Honestly there are bigger issues to deal with if we ever want to get a beta release

Regarding adding it into 4.1: That would require a B/C break, which is why this has not been introduced in 3.x, even though the code has been there for years. The problem is not the API or the component, but that the core code couldn't be switched over to this. If you customised your language files for the mails that Joomla sends and then we introduced this feature and changed the core components over to this system. All of a sudden those customisations don't work anymore. So we either introduce this in 4.0 or we drop it.

Well I guess it is clear then - either the two release blockers are resolved very quickly or it will have to be dropped

Agreed. Looking into what is a sane deadline for this and how much time I can devote here.

for me it's realy an important feature for joomla :

• easy to customize joomla email
• extendable for other components !!
• an important piece of workflow component ! we can't acheive a good workflow system if we can't manage notification

Can I also add, there is no way to "delete" a template once created. You can edit it, but not delete it.

I want to suggest the following changes.

Even if technically this is different from an article/category/menu I think we need to provide a user interface people are familiar with.

UI:

I would change it that it works like menus, you create an item chose a template, select a language and then you can add information.

If you don't have an overwrite the list will be empty.

This allows also to use the association component to translate a template in another language.

Implementation

Any component will have an XML File in administrator/components/com_abc/mails.xml

This file has the information what emails are available for the component. Makes it easy for 3rd part developers to use this functionality.

Besides the change of the com_mails component we need to be a bit more clever to find the right email. Because we have to clean the "#__mail_templates" table and only have a row when we have an overwrite. So this means we have to parse xml before we can send an email. Not a big deal, we do this from time to time.

I would volunteer to make this changes over the next week.

Seems like a good plan. Either that or kick it out as its not fit for purpose or ready for j4 as was stated 15 months ago

The problem is, that with your proposal, plugins can't add such mails. Besides that, you can only have hardcoded mails. An extension couldn't add mail templates on the fly by simply inserting the entry in the table.

The problem is, that with your proposal, plugins can't add such mails.

How a plugin should do this?

Besides that, you can only have hardcoded mails.

Don't understand why this should be the case.

An extension couldn't add mail templates on the fly by simply inserting the entry in the table.

Why this should be needed? You have to change the template to use this functionality, so on the fly doesn't makes sense to me.

The problem is, that with your proposal, plugins can't add such mails.

How a plugin should do this?

I don't understand what you mean.

Besides that, you can only have hardcoded mails.

Don't understand why this should be the case.

When the templates which you can edit are only stored in the XML, the plugins also need a way to show up in the list of possible new mail templates.

An extension couldn't add mail templates on the fly by simply inserting the entry in the table.

Why this should be needed? You have to change the template to use this functionality, so on the fly doesn't makes sense to me.

A form component could use this component to handle the mails its sending out. So for every form you have in the form component, you might have one or more different mails which are send out. These mails right now could simply be inserted in the table and then you can create the different language versions from there. With your proposal, these wouldn't show up in the "new" mail template dialog.

I would rather have a component that works and is usable than a component that is incomplete and almost impossible to use. Being theoretically able to extend its use is completely irrelevant if its unusable. I said this 15 months ago

When the templates which you can edit are only stored in the XML, the plugins also need a way to show up in the list of possible new mail templates.

It's not the template what is stored in xml it is only what templates are available.

But what we can do is to have a table instead of xml, from where we get the data is not really a problem. The problem comes when we deinstall a compoente who has made inserts into the table. An other idea could be a plugin event getEmailTemplates and this gives a list of additionals templates.

At the end of the day it is only implementation and that is up to us. More important is a consistent UI.

I see the point in having an XML, but I don't see this as a short term solution to get it "release ready" (or at least a very low priority, because it's not really necessary to ship this extension).

For me, the following changes would bring the whole extension in an "OK-ish" status:

• Remove the Mail Format option in the settings. It should not be the task of the mail template manager to decide if the email is send as HTML or plain. So both fields should be always available when editing an template.

• Assign each template to an extension (on DB level). So if the extension is disabled/uninstalled, then the entry is at least not visible in the list anymore (when the extension does not remove the entry on uninstall). This can be later extended with a trash function, but that's not needed yet.

• Remove the dropdown from the title to edit/create. Instead when clicking on the title the edit form is opened directly with the default language content visible. On the top-right I would add a dropdown with a language selector where the user can switch between the different language, which then are loaded via Ajax (kind of like the category switch in com_content when custom fields are activated)
  

• (optional) Remove the "no template" and "template" column or make the flags clickable to jump directly to the specific translation

• (optional) Improve the attachment folder field in the options

For me this would make the whole thing logical enough without losing any existing functionality and it can be extended in the future if needed.

Remove the Mail Format option in the settings. It should not be the task of the mail template manager to decide if the email is send as HTML or plain. So both fields should be always available when editing an template.

Disagree as it will confuse people to see the empty html field for default messages

Assign each template to an extension (on DB level). So if the extension is disabled/uninstalled, then the entry is at least not visible in the list anymore (when the extension does not remove the entry on uninstall). This can be later extended with a trash function, but that's not needed yet.

Agree

Remove the dropdown from the title to edit/create. Instead when clicking on the title the edit form is opened directly with the default language content visible. On the top-right I would add a dropdown with a language selector where the user can switch between the different language, which then are loaded via Ajax (kind of like the category switch in com_content when custom fields are activated)

Agree but I have my doubts the current codebase can accommodate that. This was the number one comment made when the component was submitted and @Hackwar said it has to work this way and we are "daft" for not understanding it.

This has been going on for over a 15 months. This component was not ready to be merged and should not have been merged. It would not have been accepted from any other contributor as it was not complete. It was merged on the understanding that the UX would be improved. A mistake we have seen before and was proven again here. Merging an incomplete feature means that it stays incomplete forever.

Sorry for ranting but if we had never merged incomplete and unfinished major pieces of work then we could have release joomla 4.0 by now and this could have waited until 4.1 or whenever it was actually ready. The code was clearly written in a rush against a deadline. Thats fine, shit happens, but for the contributor to then wash their hands of it and say any changes are simply wrong is not acceptable. It's not accepted from a greek contributor why is it accepted from this one. (And yes I had two major features that I wanted to see in 4.,0 but I held them back to 4.1 so we could actually release joomla 4)

To me, this feature is okay the way it is. I don't think that the current GUI is such a high hurdle for users that they can't use it or that it is majorly confusing. You disagree, fine with me, then lets change it. @bembelimen made a proposal and I can live with his changes.

What I can't live with are the implied racism accusations. The only contribution that I know of from the person in question was withdrawn by himself after he was asked to fix the issues that our automated system reported. As I remember we were even favourable in the production team to merge that PR, but before we could even react, he closed his PR and denied us to ever use his code again. And that is apparently due to us being racists? Sorry, no.

Regarding this being merged in 4.0: Implementing this feature in the core components to me means a b/c break and thus is not possible in a minor release. So if this hadn't been merged into 4.0, the component could have been merged in 4.1, but none of the core mails could use this feature until Joomla 5.0. That is why this, too, was discussed in the production team and eventually was declared to rather be merged into 4.0 than later. Considering that the original PR which introduced this feature was from September 2018, its also not that this was rushed in.

That's the problem - you dont see a problem and yet everyone else does. This code is holding back the release of Joomla 4. If you say that it cant go in a 4.1 release then sorry but it will have to wait till 5.0.

28 Jan 2000

@brianteeman wrote

Well I guess it is clear then - either the two release blockers are resolved very quickly or it will have to be dropped

@Hackwar wrote

Agreed. Looking into what is a sane deadline for this and how much time I can devote here.

I am sure that everyone can agree that you have not done that - or if you have then you have not communicated it.

I have no idea what you are referring to about racism or any specific person. Discrimination of any form is something I am very sensitive to and is absolutely not something I would ever imply. If I believed there was racism in any form anywhere in the project then after 15 years of knowing me I am sure you would know that I would be open and direct in stating it. (Something I have sadly had to address in Joomla far too many times)

I have no idea what you are referring to about racism or any specific person.

The racism thing came up on Twitter where a well known former contributor blamed the community to make differences between people with Greek names and with Nordic names.

Your comment above seems to pick that up:

It's not accepted from a greek contributor why is it accepted from this one.

I don't appreciate people talking behind my back like that. I withdrew the first WebAuthn contribution not because the automated system picked up some PHP styling issues — which I fixed. I withdrew it because a. I had asked explicitly for instructions and got sod all; b. I was told by actual humans that I should magically know about the JavaScript workflow and code style which was at the time nowhere documented, at all. FYI the latter came as a response to me wondering where exactly the JS styling rules are documented. I literally got told I should know about what is not documented! Also, in case you haven't heard, a few months later I redid the contribution from scratch and as you know it's already part of Joomla 4 for nearly a year now.

I am terribly surprised to hear that a core contributor is unaware of my contributions, considering the fact that he was ostensibly an active member of the Joomla community the past 12 years I have contributed features and bug fixes such as: fixes to the redirection code in Joomla 1.6, support for commercial extensions updates, the upload files scanner, update quick-icons in the Control Panel page and the entire quick icons concept, Joomla Update, the Update Sites page, Two Factor Authentication, Post-installation messages, WebAuthn and of course FOF itself. The Joomla project has also copied a lot of the FOF 1.x and 2.x features without attribution, features which were a product of the R&D I did on my own dime and time.

As for my complaints, let me just give you a small selection of the first and the last instances of what I've experienced.

The first instance was in 2009 when I was explaining that the change of the session data storage from TEXT to VARCHAR(20000) ostensibly because this would inline it in the table record increasing performance was utter nonsense. I liked to the MySQL documentation which explained that the MyISAM engine used by Joomla at the time would store all variable content length fields separately, thereby making no distinction between VARCHAR(20000) and all TEXT column types with regards to performance. I even wrote a benchmark. This was not just rejected without consideration by Andrew Eddie, I was also told I don't know how to write code. Imagine my surprise when almost a year later the field was changed from VARCHAR(20000) to MEDIUMTEXT because it makes no change in performance but having it too small would break Joomla due to the session overflowing. I was not mentioned anywhere as the original person reporting it, nor anyone apologised. The only difference is that the first time I was the one reporting it, the second time it was the person who had called me a useless developer that reported the exact same thing I had.

When I proposed that Joomla 3 should support SVGs I was told it can't be done in Joomla 3 because it's a "major" feature that requires handling the security of SVGs. Even though a solution to that existed, I was told that the production leadership considered it and decided it still can't go in. I vehemently disagreed with this decision and I closed my PR. Imagine my surprise when a few months later a new Joomla version comes out where the JSST proposes a rule in .htaccess which is less complete than my proposed solution. So either the JSST had a simultaneous stroke which afflicted everyone in it with selective amnesia about my proposal or their real problem was that the proposal came from me.

I'd be happy if these were the only instances.

These are 12 years apart. In the 12 years in between there have been many cases like that. I report something, I get ignored at best, actively hounded at worst. For example, I have been talking about the Joomla installer and updater bugs for a decade. I have proposed to fix them multiple times, every time I'm told it's a major change and I cannot be allowed to touch it. Then Phil Taylor files a PR and y'all consider it for merging in Joomla 3. What changed in the three weeks between my public ticket and his PR? You do realise that people can actually see the difference in treatment and draw their own conclusions.

Further to that, do you want to talk about the time you banned me from the dev mailing list because I defended myself against an ad hominem attack from Andrew? An ad hominem attack, I may add, regarding the inclusion of FOF in the core which the OSM president at the time (Paul Orwig) had begged me for, on his own volition and I had reluctantly accepted even though it meant I would have to work my ass off night and day for two months to hit the deadline. I got banned, Andrew didn't even get a slap on the wrist.

I'm really not sure what your problem is. You can't claim that I am "hard to work with" when this behaviour from Joomla goes back to my first ever attempt to contribute where I was VERY polite and patient. The "hard to work with" is the result of being treated like crap by the Joomla project over 12 years. After Joomla's reneging on its promises with regards to FOF being included in the core — leaving me unable to maintain my now framework, almost killing my business on a year I had lost a third of its assets to the Cypriot banking collapse, leading me to fork my own framework which nearly nine years later is still a source of confusion I have to waste my time explaining to people — I would say I got very salty indeed. If you blame me for that ask yourselves what you would have done in my place.

Moreover, I see that the double standards keep on applying. I say something in my Twitter feed I'm being mistreated and I'm pretty sure it's because I'm Greek and it's held against me. A Joomla team leader says on his Twitter feed they explicitly want the project to write a backup component so my software and company will cease to exist and nobody bats an eyelid. ARE YOU PEOPLE FOR REAL?! Either our personal views have nothing to do with the project and neither person's tweet get mentioned OR our personal views have everything to do with the project and we both get a ban. If you keep holding what I write on my own, personal feed against me but don't apply it to your team leader you are just a bunch of hypocrites, in the objective definition of the word in a dictionary.

For what it's worth, what I said on my personal Twitter was of course an exaggeration in the heat of the moment, mostly hoping to get a bloody response about the question that's been in my mind for the past 12 years: WHAT IS THEIR PROBLEM WITH ME, ANYWAY?! I am willing to accept it's not bigotry because I know most of you for years and you don't come across as consciously bigoted. So what THE HELL is your problem with me?

You know what? I don't even care anymore. I've had enough of being treated like shit from a project I dedicated most of my professional life for. I'm done with this toxicity. I have stopped contributing since 2020 and I am not coming back. You've won. This is what you wanted all along, right? Now, can you please stop dragging me into your toxic mess of a project and stop talking about me? it's not too much to ask and I've been asking for that for a year already. Thanks.

Then Phil Taylor files a PR and y'all consider it for merging in Joomla 3.

Shhh... they are not merged yet ;-) Still time for them to be rejected :)

And in true style @SharkyKZ drove by and closed/rejected them...

Remove the Mail Format option in the settings. It should not be the task of the mail template manager to decide if the email is send as HTML or plain. So both fields should be always available when editing an template.

I would keep this option in global config.
But I agree that in the editign form should be always available both editors: plain and html, independed from that option.

Remove the dropdown from the title to edit/create. Instead when clicking on the title the edit form is opened directly with the default language content visible...

I like that idea. Not sure about ajax, maybe some redirect would be also enough.

Assign each template to an extension (on DB level)

I would leave 3d extensions integration for 4.x.

Disagree as it will confuse people to see the empty html field for default messages

in theory we can duplicate the plain message to the HTML when it empty,
simple nl2br() (kind of like was made in #32118 for HTML fallback)

Additionally I see as user some easy UX improvements in the layouts as for example changing "Availabe Tags" to "Insert Tag".

What confuses me: Why are there edit switches? If a user has permission for editing why does he need to use a switch?
I would prefer toggle buttons instead of switches, but why do we need a switch there?

Why are there edit switches?

I think the original idea is to have: "default content" (lang. constant), and "user content".
But yea it not very obvious.

Maybe we can drop them, and always display the content, instead of lang. constant.
But then need a way to User to reset the content to default, in case he/she deleted something accidentally or something like that.
Maybe replace the switcher with button "Reset to default content".

So I looked at this discussion and made PR #33230 base on your feedbacks (some but not all). Please take look at it to see if that PR could be solution for this problem.

PR #33230 should address our concern about Mail Templates, so I'm closing this issue. If it is not accepted, I will re-open.