Problem/Motivation
System mail configuration lies at multiple places. This includes admin/config/system/site-information for storing email address, admin/config/people/accounts for user mail templates and admin/structure/contact/edit/N for Contact mail templates. To add complexity to this problem, each module that allows email functionality stores the information in a different location. This would make it difficult to maintain a single version of the truth and make maintenance of email related configuration very tedious.
Note: This summary is updated till comment #24.
Proposed resolution
Having email have its own config group would solve this problem. A patch that was posted in Comment #3 and #4 implements menu entries in System with separate tabs for User mail and Contact form mail. However separate admin sections may not be frequently accessed. The implementation is also currently updated to use the new configuration management.
Remaining tasks
The latest patch submitted in comment #22 is under review.
User interface changes
A new menu under System with separate tabs for User email and Contact form email.
API changes
Not familiar with PHP API so this needs to be updated by someone with more knowledge. Patch shows that the function user_mail_settings() has been rewritten.
Original report by webchick
Right now, system mail configuration is pretty tedious. The email address that system mails get sent out under is at admin/config/system/site-information, you configure User mail templates at admin/config/people/accounts but Contact mail templates at admin/structure/contact/edit/N, and every other module you enable that offers mail-related functionality puts it in yet another spot.
It'd be great if there was a centralized place to manage all of this that contributed modules could hook into.
| Comment | File | Size | Author |
|---|---|---|---|
| #28 | 1516952-centralised-mail-14.patch | 47.36 KB | amen |
| #22 | 1516952-centralised-mail-12.patch | 31.58 KB | justafish |
| #11 | 1516952-centralised-mail-11.patch | 33.6 KB | justafish |
| #4 | centralise-mail-settings-1516952-3.patch | 31.48 KB | justafish |
| #3 | centralize-mail-1516952-3-do-not-test.patch | 22.06 KB | naxoc |
Comments
Comment #1
cosmicdreams commentedYes! it would establish a conventional place for all mail applications in Drupal. If I wanted to create a contributed module that handles the publication (in this case distribution) of mail messages from my Drupal site and wanted to provide a place to configure that, I'd probably establish my own config group.
In this future Drupal where mail already has it's own config group, I wouldn't have to.
Comment #2
wjaspers commentedTheres a project in the Application queue for Swiftmailer #1174572: Swift Mailer module.
Ideally, a mailhandling system could be pluggable--much like the theme layer, or adopt portions thereof of work already completed for other mailhandling purposes.
Part of the problem, I believe, may stem from that the way we ant to work with email traditionally isn't thought about the same way we do, content. As such, it gets sporadically placed around the administrative tools of the site, on a case by case basis. Maybe we could get totally crazy here and create an Entity type which specifically represents a complete "e-mail" (prior to sending), so the email template either becomes a living, functional piece of content within the site.
Thoughts?
Comment #3
naxoc commentedI made a new menu entry under "System" and started to put mail config stuff in there. Uploading what I have so far so we can work more people on this at the Copenhagen Code Sprint.
I am going to start fixing the tests.
Comment #4
justafishPuts the User mail and Contact form mail settings into tabs under the centralised Mail area. This should also allow other modules to easily put items in this section.
Comment #5
justafishComment #6
wjaspers commentedLooks ok thus far, tested, no errors, no git complaints. Would put to RTBC, but I haven't checked if it is actually accessing/sending correctly.
Comment #7
naxoc commentedI put a TODO in the menu item text because I am not too good with wording of that stuff. I'll see if I can get someone with more UX skills than me to take a look.
Comment #8
Bojhan commentedHmm, is the solution to this really to make a separate admin section? I hope its not one of those area's in core no one ever goes to.
Comment #9
naxoc commentedBohjan, do you think it would make more sense somewhere else? If so where could that be?
Comment #10
xmacinfoThis is indeed the missing admin section. Grouping together all mail messages makes a lot of sense.
I have not tested the patch, though.
Comment #11
justafishUpdated against head to use the new configuration management. Also removed the "TODO" from the description text.
Comment #13
justafish#11: 1516952-centralised-mail-11.patch queued for re-testing.
Comment #15
justafish#11: 1516952-centralised-mail-11.patch queued for re-testing.
Comment #17
justafishTestbot was trying to access /checkout/install.php instead of /checkout/core/install.php
Comment #18
justafish#11: 1516952-centralised-mail-11.patch queued for re-testing.
Comment #20
dave reid#11: 1516952-centralised-mail-11.patch queued for re-testing.
Comment #22
justafishComment #23
justafishComment #24
BrockBoland commentedNeeds issue summary
Comment #25
askhadkikar commentedIssue summary written. Needs some inputs for the API section.
Comment #25.0
askhadkikar commentedIssue summary written. Needs a review for the PHP API section from someone more knowledgeable with PHP.
Comment #26
h4rrydog commentedI think this is a cool idea.
Unfortunately, after applying the patch in #22 and going to admin/config/system/mail from the UI, I get the following errors when going to the "general settings" tab:
Notice: Undefined index: system_mail_settings in drupal_retrieve_form() (line 773 of core/includes/form.inc).
Warning: call_user_func_array() expects parameter 1 to be a valid callback, function 'system_mail_settings' not found or invalid function name in drupal_retrieve_form() (line 817 of core/includes/form.inc).
The "users" tab with the email templates appears to work fine, although I haven't tested actually sending out an email.
Also, I believe that the copy in various places in the UI also should be changed to reflect the fact that the mail settings will be centralised now:
Comment #27
schiavone commentedThis patch needs to be re-rolled since the structure of module info file has been moved to yml
Comment #28
amen commentedI have refactored the code to work with latest dev.
Issues with this patch:
PS: First core patch ever o/
Comment #29.0
(not verified) commentedUpdated username in summary-original-report
Comment #35
justafish