Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.The user-register emails typically include a password and/or a login link, but these variables are not available through mail_edit.
The subscriptions emails should also include a link to the node as well as additional information, e.g. the node type and the category (e.g. forum name) for taxa. This information does not seem to be available through mail_edit, so why would I want to use mail_edit?
Apparently, mail_edit is now a requirement for Subscriptions — does that mean that Subscriptions will be limited to mail_edit's set of variables? The ability to customize the email texts is a nice new feature, but I've already had that because my sites are translated, and losing the case-specific variables would be a big step backwards!
If I did venture to try changing a message with mail_edit, would I have any chance to return to the old state?
Another question: The explanation on the edit forms goes
The subject of the mail (if no type) or the the private message sent instead of the mail.
What does the "if no type" bit mean?
Comments
Comment #1
chx commentedThank you so much for bringing this to my attention. I added a mail_edit_variables hook. This made for example subscriptions module a lot cleaner because now that does not query the mail_edit table. And also, yes, that was a bug in subscriptions.
Comment #2
salvisYou've addressed some of the issues, but not all.
I still think that the admin/build/mail_edit page needs some explanations of what we're actually doing here, and especially how (if?) you can revert what you've changed there.
As you say, you've updated the Subscriptions module to supply additional variables. (I haven't been able to get it to work properly for category subscriptions, but I'm still investigating.) This is fine for Subscriptions, but you're hooking all modules that want to send email, e.g. user.module (core) and user_status.module (contributed). These modules don't know about mail_edit and they don't supply their variables — but without the variables the messages are useless!
It seems like mail_edit would need to be in core and mail_edit_variables() would need to be an official hook, in order to make this work. Until then, you probably have to limit yourself to hooking only modules that implement the mail_edit_variables() hook, and maybe some others that you know will work (contact.module?).
Comment #3
Zen commentedThe mail_edit module is technically not part of the privatemsg module as such. It will be spun out into a separate project very shortly. Please move this issue once that is done.
Moving issue out of the critical queue.
-K
Comment #4
salvis