Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
I have a global htmlmail.tpl.php template in my e-mail theme which works fine for all my emails (i.e. webform mails). However, this template isn't used for user e-mails (like password recovery), unless i specify a more specific template.
For example: htmlmail--user--password_reset.tpl.php works for password recovery e-mails, but when I remove it, the global htmlmail.tpl.php template isn't used for this e-mail.
Comment | File | Size | Author |
---|---|---|---|
#9 | htmlmail-remove-default-templates-1170576-9-7.patch | 12.76 KB | alexdmccabe |
Comments
Comment #1
pillarsdotnet CreditAttribution: pillarsdotnet commentedYou'll need to remove the extra template from both the htmlmail module directory and your theme directory, if you're using an email theme.
Then you'll need to visit admin/config/development/performance and clear your cache.
If this doesn't work, then let me know, because something is broken and I need to fix it.
Comment #2
pillarsdotnet CreditAttribution: pillarsdotnet commentedI should document this better.
Comment #3
adriaanm CreditAttribution: adriaanm commentedThanks for your quick response, it works when i remove htmlmail--user--password_reset.tpl.php in the htmlmail directory.
However, isn't it strange that the template for password recovery in the htmlmail directory is used over my custom template in my e-mail theme? This is not the case with htmlmail.tpl.php. Shouldn't the module give precedence to custom template files in the e-mail theme directory?
Removing htmlmail--user--password_reset.tpl.php in the htmlmail directory works, but this file will always be recreated when updating the module.
Comment #4
pillarsdotnet CreditAttribution: pillarsdotnet commentedIf you have a file called htmlmail-user--password_reset.tpl.php in your e-mail theme directory, and it isn't getting used for password reset emails, then I want to hear about it.
The order of precedence should be:
$theme_directory/htmlmail--$module--$key.tpl.php
$module_directory/htmlmail--$module--$key.tpl.php
$theme_directory/htmlmail--$module.tpl.php
$module_directory/htmlmail--$module.tpl.php
$theme_directory/htmlmail.tpl.php
$module_directory/htmlmail.tpl.php
If that order is not being followed, please tell me and I'll try to fix the problem.
Comment #5
pillarsdotnet CreditAttribution: pillarsdotnet commentedComment #6
pfrenssenIsn't it a better idea to remove the htmlmail--user--password_reset.tpl.php file from the module entirely? This just serves as an example and places an additional burden on the users of the module.
I suspect the most common use case is to *not* have a customized user password email. To make this use case work as expected there are two options now:
I would not throw away this file, as it is useful as an example. But a better home for it would be inside a documentation page, and not in the module folder.
Comment #7
pillarsdotnet CreditAttribution: pillarsdotnet commentedOr maybe an examples folder.
Comment #8
Joolee CreditAttribution: Joolee commentedIsn't it just weird that templates in the module folder get preferred over the template folder? It shouldn't be necessary to change the module folder. Now I need to remove all template files from there to use a htmlmail.tpl.php in my theme folder.
Why not only search the module folder after all tries in the theme folder have failed? That would be a lot more logical and more in line with other systems.
The Module folder shouldn't be edited.
Comment #9
alexdmccabeI completely agree with #8. Hacking a contrib module should not be necessary to achieve obvious functionality. Can you imagine if core shipped with a node--article.tpl.php that overrode node.tpl.php in a custom theme, and the SOP was to hack core to delete that template? It would never happen, because of https://www.drupal.org/best-practices/do-not-hack-core.
Hacking contrib is a very small step down from hacking core - many of the same reasons from that link apply:
Contrib modules are supposed to allow their functionality to be modified with strategic use of hooks and templates, not "well, just delete this file".
To that end, here's a patch that removes all templates other than htmlmail.tpl.php from the htmlmail module.
Comment #10
alexdmccabeSetting to needs review.
Comment #11
salvisI agree with #6 and #7:
I also agree with the reasoning in #9, but...
I disagree with throwing away these files.
Will Drupal still find the templates recursively under the module folder, say, if they're in an 'example-templates' folder? If yes, then we could rename them by appending '.example' to the file names.
HOWEVER: We have a major problem which is that some sites may have come to rely on these templates, and we must not break them inadvertently. I acknowledge that this is an issue for you, but simply shifting the burden to someone else is not the solution.
I see one way out of the dilemma: write a hook_update_NNN() function to check the theme registry to find out whether any of these templates are being used, and if they are, then alert the user that they've been moved/renamed and tell them what they need to do to restore the theming that they had before.
Comment #12
alexdmccabeI think it will recursively find the files, yes, but appending .example should stop it from finding them.
I think your idea of implementing hook_update_N is a good one. I think many users would still miss it and complain, though. This just isn't a great situation to be in.
Maybe this needs to wait for a version jump, to 7.x-3.x perhaps?
Comment #13
salvis