So I sent myself a message using the contact module, and the message is prepended with a bunch of information that I felt would be confusing for a large percentage of my users. I decided to look into changing it, and possible changing the site name being prepended to the subject.

davidw,

davidw (http://www.rism.ac.th/risweb/index.php?q=user/1) has sent you a
message via your contact form
(http://www.rism.ac.th/risweb/index.php?q=user/1/contact) at RUAMRUDEE
INTERNATIONAL SCHOOL.

If you don't want to receive such e-mails, you can change your settings at
http://www.rism.ac.th/risweb/index.php?q=user/1.

Message:

Just checking the personal contact form. 

Notice that the actual message itself is less than 20% of the total number of characters sent. In terms of usability this needs work. The solution to fixes this message is to install the locale module and translate the strings that form the message. However it seems to me that this is a feature the contact module should include by default, just like all of the other configurable email forms that exist.

I'm happy to install Drupal 7.x and work out a patch for this behaviour. It seems that there has been a push to keep the contact module small and light, but this feature would require an additional settings page, and slightly reworked logic to create the message so it's minimal code.

Anyone think this is worth adding to Drupal Core?

Comments

damien tournoud’s picture

This message is passed thru t() in contact_mail():

      $message['body'][] = t("!name (!name-url) has sent you a message via your contact form (!form-url) at !site.", array('!name' => $user->name, '!name-url' => url("user/$user->uid", array('absolute' => TRUE, 'language' => $language)), '!form-url' => url($_GET['q'], array('absolute' => TRUE, 'language' => $language)), '!site' => variable_get('site_name', 'Drupal')), $language->language);

That means that you can actually override it with the String Overrides module.

The usability issue here is tricky, because if you allow that message to be configured via the interface, you also loose the ability to translate it properly (except by installing i18n and playing with variable translation). This last issue is also a big one in term of usability on multilingual setups.

dwees’s picture

Yes, I can install a module to override this one string. I can also edit this string in my settings.php file. I know it is possible to change this string, I just think that in a core module, fixing one string should be easier than the current options. The reason why this particular issue is important to me is that as I am developing a site, I want to make it as easy as possible for my end users to change things on the sites when I leave, without having to resort to learning Drupal + Php at an intermediate/expert level.

What is the performance hit per page for installing the stringoverrides module if I only want to "translate" this one string (given my content is all in English)?

If a multi-lingual set up is the only time when we have an issue with this (I can see the problem there, we'd have to let them translate it each time for each language somewhere, and inside the contact module is not the place to do that), is there a way of 'detecting' a multi-lingual set-up or is this too prone to upgrade and compatibility problems?

This is obviously part of a bigger issue, which is to require all of Drupal core be compatible with a multi-lingual set up, hence making changing strings in core more difficult than it needs to be. So it seems to me that this is "by design" or "won't fix".

dwees’s picture

Also, we already do exactly what I am looking for in the various email messages for the user module. Shouldn't these be translatable too then, by the same logic (since it is conceivable one could create a registration form in multiple languages)?

Dave

gpk’s picture

The user registration/account setup emails can be configured at admin/user/settings. Seems reasonable that the additional stuff output by contact.module in its emails should also be configurable on a settings page provided by core.

Having said that String overrides is a must-have for tweaking user interface text on a monolingual English site.

[update] Also there is hook_mail_alter(). Check the full content of $message especially $message['params'] ... should be possible to modify $message['body'] to get it as desired.

guillaumeduveau’s picture

sub

dave reid’s picture

Version: 7.x-dev » 8.x-dev
Status: Active » Postponed

This is not likely to make it into Drupal 7. Let's put this on our TODO list for D8.

dave reid’s picture

Title: Default message prepended to user messages is difficult to configure » Add option to configure contact mail content (like user mails)
shark’s picture

+1 on this. I'd love an easy to set the format to something a bit more user friendly (namely, putting the message closer to the top followed by additional info, as is pretty standard on emails like from mailing lists or automated systems):

davidw says:

Just checking the personal contact form.

---------------------------------------------------

You can view davidw's profile at http://www.rism.ac.th/risweb/index.php?q=user/1

This message was sent via your contact form (http://www.rism.ac.th/risweb/index.php?q=user/1/contact) at RUAMRUDEE INTERNATIONAL SCHOOL. Your username is davidw.

If you don't want to receive such e-mails, you can change your settings at http://www.rism.ac.th/risweb/index.php?q=user/1.

NickAT’s picture

I agree, since several other mail types are templated/tokenized for admin edits, it only makes sense to add this as well. Particularly since the default configuration adds information that may confuse the general end-user, as stated above.

j4’s picture

We could also go one step more? And give the admin a checkbox with an option to include or not the text about changing settings?

Jaya

webchick’s picture

Status: Postponed » Active

D8 is available for development now. No reason for this to be postponed.

andypost’s picture

Version: 8.0.x-dev » 8.1.x-dev
Status: Active » Postponed

does not fits in beta

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

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now 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.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now 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.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now 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.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now 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.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now 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.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.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.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.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.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

quietone’s picture

Status: Postponed » Active
quietone’s picture

Status: Active » Closed (outdated)

formatting of ccs is checked automatically now. I am closing this as outdated.

quietone’s picture

Status: Closed (outdated) » Active

Sorry, wrong issue.

quietone’s picture

Status: Active » Postponed

The Contact Module was approved for removal in #3476879: [Policy] Move Contact module to contrib.

This is Postponed. The status is set according to two policies. The Remove a core extension and move it to a contributed project and the Extensions approved for removal policies.

The deprecation work is in #3520460: [meta] Tasks to deprecate the Contact module and the removal work in #3520466: [meta] Tasks to remove Contact module.

Contact will be moved to a contributed project after the Drupal 12.x branch is open.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.

andypost’s picture

Project: Drupal core » Contact
Version: main » 1.x-dev
Component: contact.module » Code
Status: Postponed » Active