Add an alternative to hook_mail() and deprecate it

Created on 18 November 2011, over 13 years ago
Updated 20 October 2023, over 1 year ago

#800434: drupal_mail, allow hook_mail_alter implementation to cancel mail β†’ adds a bit more complexity to drupal_mail() and hook_mail_alter(), but it's supporting a good feature.

However, it would be great to clean that up, hook_mail() is near the top of the list of weird hooks in core.

Pasting from irc chat with permission from Gabor.

<catch> GaborHojtsy: do you have any ideas sitting around somewhere for ways to change drupal_mail?
<catch> GaborHojtsy: not related to anything, just there is a patch in the queue for it that reminds me how much I dislike it.
<GaborHojtsy> catch: LOL
<xjm> haha
<GaborHojtsy> catch: I think we can eliminate the whole pseudo-hook-mail thing if we wanted to
<catch> GaborHojtsy: yeah it is that bit I'm thinking of. I know it was added for translation but it was a long time ago.
<GaborHojtsy> catch: that was an attempt resulting in horrifying DX to enforce localizability of emails
<catch> And plenty of stuff moved along since then.
<GaborHojtsy> catch: nothing made it really required to make us have hook_mail() so we should not have introduced it in the first place
<GaborHojtsy> catch: the idea was if we did not change the API and introduce language prominently, people would not care :D :D :D :D
<GaborHojtsy> catch: in retrospect... well... we are people we make mistakes :)
<catch> GaborHojtsy: heh.
<GaborHojtsy> catch: there is no technical requirement for us to have hook_mail, so we can just drop it altogether
<GaborHojtsy> catch: everything else would still work as-is
<catch> hook_mail?
<Druplicon> hook_mail: Prepare a message based on parameters; called from drupal_mail(). => hook_mail($key, &$message, $params) => http://api.drupal.org/api/function/hook_mail/6
<GaborHojtsy> catch: including hook_mail_alter
<catch> system_mail?
<Druplicon> system_mail: Implementation of hook_mail(). => system_mail($key, &$message, $params) => http://api.drupal.org/api/function/system_mail/6
<GaborHojtsy> catch: hook_mail() just creates arrays of other arrays
<GaborHojtsy> catch: and hook_mail alter then alters those arrays again
<catch> GaborHojtsy: so what does it look like if we completely drop that hook?
<catch> drupal_mail?
<Druplicon> drupal_mail: Compose and optionally send an e-mail message. => drupal_mail($module, $key, $to, $language, $params = array(), $from = NULL, $send = TRUE) => http://api.drupal.org/api/function/drupal_mail/6
<GaborHojtsy> catch: well, you'd pass drupal_mail() what was in D7 the output of hook_mail() for the $key
<GaborHojtsy> catch: you'd still need some identifier for the mail for the drupal_alter() stuff
<GaborHojtsy> catch: so I'd guess we'd keep $module and $key

<catch> GaborHojtsy: $key wouldn't be enough? we can tell people to namespace it.
<GaborHojtsy> catch: sure, we can namespace it
<GaborHojtsy> catch: either way, as you can see drupal_mail() just prefills some stuff to the array that hook_mail() continues to fill; we can turn that around and do a += in drupal_mail()
<catch> GaborHojtsy: mind if I copy and paste a few bits of this into an issue?
<GaborHojtsy> catch: feel free to :)
πŸ“Œ Task
Status

Needs work

Version

11.0 πŸ”₯

Component
BaseΒ  β†’

Last updated 37 minutes ago

Created by

πŸ‡¬πŸ‡§United Kingdom catch

Live updates comments and jobs are added and updated live.
  • DrupalWTF

    Worse Than Failure. Approximates the unpleasant remark made by Drupal developers when they first encounter a particular (mis)feature.

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • πŸ‡ͺπŸ‡¨Ecuador jwilson3

    Should this now be closed as part of 🌱 [META] Adopt the symfony mailer component Needs review or simply repurposed and linked into the last step of the "Stage 4: Remove the old mail system" on that issue's summary?

    Deprecate then remove the old API hook_mail() and hook_mail_alter()

  • πŸ‡¨πŸ‡­Switzerland berdir Switzerland

    My personal opinion:

    * The issue title makes this a duplicate of that meta issue.

    * The concept of comment #47 and related contrib module, a centralized system for user-configurable, translatable, reusable, ... e-mails that can be used by modules but also things like ECA is a layer/feature on top of the new mail API.

    My suggestion would be to close this as a duplicate and optionally open a new issue or just keep discussing it in the meta if and how we'd implement such a system in core.

Production build 0.71.5 2024