[#44769] - [5.4] Fix extension query in mailtemplates
- Closed
- 30 Jan 2026
- Medium
- Build: 5.2-dev
- # 44769
- Diff
- SniperSister:5.3-mailtemplate-select
User tests: Successful: Unsuccessful:
Summary of Changes
The mail templates list view shows a list of all available templates from the #__mail_templates table. While doing so, it checks if the associated extension is enabled.
However, it uses the value of the "name" column in the #__extensions table for the subquery (which might hold a human-readable name and not the technical "element" name), causing templates to be not listed if the name and element of the associated extension do not align.
Testing Instructions
- Temporarly change the value of the "name" column of com_contact in #__extensions from com_contact to Contact
- List the available mail templates
Actual result BEFORE applying this Pull Request
- com_contact templates missing
Expected result AFTER applying this Pull Request
- com_contact templates listed
Link to documentations
Please select:
-
Documentation link for docs.joomla.org:
-
No documentation changes for docs.joomla.org needed
-
Pull Request link for manual.joomla.org:
-
No documentation changes for manual.joomla.org needed
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Category | ⇒ | Administration |
Hackwar
- 
it seems we are using the extensions name and not the element:
Those are the elements? See the #__extensions table
it seems we are using the extensions name and not the element:
Those are the elements? See the #__extensions table
Yes, because for components, modules and templates the name and the element columns have the same value in our installation SQL. For other modules they differ.
Are the extensions which can be assigned to mail templates restricted to certain types, e.g. components?
If so, it could make sense to add a restriction for that (WHERE type IN ...) to the where clause of the subquery which is modified by this PR.
Are the extensions which can be assigned to mail templates restricted to certain types, e.g. components?
Nope, basically anything works.
This pull request has been automatically rebased to 5.3-dev.
| Title |
|
||||||
This pull request has been automatically rebased to 5.4-dev.
| Title |
|
||||||
| Labels |
Added:
bug
PR-5.4-dev
|
||
I have tested this item 🔴 unsuccessfully on 27319fc
Tested with JBT
- Before PR 28 mail templates are listed, changed table
#__extensions, entrycom_contact, fieldnamefromcom_contacttoContact, only 26 mail templates are listed - Applied PR with Patch Tester
- ❌ Only 24 mail templates are shown
- Reverted
#__extensions, entrycom_contact, fieldnametocom_contact, still 24 mail templates - Reverted PR and 28 templates are shown, difference (not found after PR) are:
- plg_user_joomla.mail
- plg_task_updatenotification.mail
- plg_task_privacyconsent.request.reminder
- plg_multifactorauth_email.mail
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/44769.
| Status | Pending | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2026-01-30 17:38:56 |
| Closed_By | ⇒ | SniperSister |
Hmm, when filling the mail templates table for new installations it seems we are using the extensions name and not the element:
https://github.com/joomla/joomla-cms/blob/5.2-dev/installation/sql/mysql/supports.sql#L410-L440
So I'm not really sure if this PR is right or if it needs changes at additional places.
Pity that the
extensioncolumn of the#__mail_templatesis a string with a name or whatever else and not an integer with the extension ID (which would allow a foreign key whenever we will support that).