User tests: Successful: 0 Unsuccessful: 0
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.
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 |
Category | ⇒ | Administration |
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.
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
extension
column of the#__mail_templates
is 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).