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.

Comments

cosmicdreams’s picture

Yes! 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.

wjaspers’s picture

Theres 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?

naxoc’s picture

StatusFileSize
new22.06 KB

I 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.

justafish’s picture

StatusFileSize
new31.48 KB

Puts 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.

justafish’s picture

Status: Active » Needs review
wjaspers’s picture

Looks 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.

naxoc’s picture

I 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.

Bojhan’s picture

Hmm, 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.

naxoc’s picture

Bohjan, do you think it would make more sense somewhere else? If so where could that be?

xmacinfo’s picture

This is indeed the missing admin section. Grouping together all mail messages makes a lot of sense.

I have not tested the patch, though.

justafish’s picture

StatusFileSize
new33.6 KB

Updated against head to use the new configuration management. Also removed the "TODO" from the description text.

Status: Needs review » Needs work

The last submitted patch, 1516952-centralised-mail-11.patch, failed testing.

justafish’s picture

Status: Needs work » Needs review

#11: 1516952-centralised-mail-11.patch queued for re-testing.

Status: Needs review » Needs work

The last submitted patch, 1516952-centralised-mail-11.patch, failed testing.

justafish’s picture

Status: Needs work » Needs review

#11: 1516952-centralised-mail-11.patch queued for re-testing.

Status: Needs review » Needs work

The last submitted patch, 1516952-centralised-mail-11.patch, failed testing.

justafish’s picture

Testbot was trying to access /checkout/install.php instead of /checkout/core/install.php

justafish’s picture

Status: Needs work » Needs review

#11: 1516952-centralised-mail-11.patch queued for re-testing.

Status: Needs review » Needs work

The last submitted patch, 1516952-centralised-mail-11.patch, failed testing.

dave reid’s picture

Status: Needs work » Needs review

#11: 1516952-centralised-mail-11.patch queued for re-testing.

Status: Needs review » Needs work

The last submitted patch, 1516952-centralised-mail-11.patch, failed testing.

justafish’s picture

StatusFileSize
new31.58 KB
justafish’s picture

Status: Needs work » Needs review
BrockBoland’s picture

Needs issue summary

askhadkikar’s picture

Issue summary written. Needs some inputs for the API section.

askhadkikar’s picture

Issue summary: View changes

Issue summary written. Needs a review for the PHP API section from someone more knowledgeable with PHP.

h4rrydog’s picture

Status: Needs review » Needs work

I 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:

  • The description text for Site Information says "Change site name, e-mail address, slogan, default front page, and number of posts per page, error pages."
  • The description txt for Account Settings says "Configure default behavior of users, including registration requirements, e-mails, fields, and user pictures."
schiavone’s picture

This patch needs to be re-rolled since the structure of module info file has been moved to yml

amen’s picture

Status: Needs work » Needs review
StatusFileSize
new47.36 KB

I have refactored the code to work with latest dev.

Issues with this patch:

  • I couldn't find the link to "manage fields" and "manage display" on the contact categories.
  • I'm not sure whether the "Require E-mail Verification" checkbox should be moved here or stay in the "Account Settings" page.
  • I could't find good enough documentation on the Drupal 8 way of implementing Local Tasks, so I just did them with hook_menu.
  • I added a file named MailForm.php to the system module, I'm not sure it obeys naming conventions.

PS: First core patch ever o/

The last submitted patch, 1516952-centralised-mail-14.patch, failed testing.

Anonymous’s picture

Issue summary: View changes

Updated username in summary-original-report

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

justafish’s picture

Status: Needs work » Closed (outdated)