Hi.
I was looking at customizing the confirmation and reminder messages.

The module has forms to edit these messages located at http://yoursite/admin/settings/signup which is all well and good. I changed the default messages to what I wanted, and signed up to an event. I still received the default message. I had a friend sign up to see if there was some kind of delay, still the default message. I logged out, signed up as anonymous with an e-mail... still the default message.

I then wondered if the message was hard coded into the module. I opened textpad did a search for:
"Enter your default confirmation email message here" in "all files" in the /modules/signup folder and sure enough found the text in signup.install line 186.

function signup_insert_default_signup_info() {
  return db_query("INSERT INTO {signup} (nid, forwarding_email,
    send_confirmation, confirmation_email,
    send_reminder, reminder_days_before, reminder_email,
    close_in_advance_time, close_signup_limit, status) VALUES (0, '',
    1, 'Enter your default confirmation email message here',
    1, 1, 'Enter your default reminder email message here',
    0, 0, 1)");
}

I'm updating that hard coded info to what I want. I just wanted to report this so that it gets fixed in the future but also so other users don't get all confused like I did trying to change the message via the form and have it not work. :)

This is a fantastic module. :) Keep up the good work.

Comments

Passionate_Lass’s picture

Passionate_Lass commented

Oops.

I just realized that's creating the database table.

I checked the database and did figure out the problem. The default message was indeed changed, however, the events that were created before the default was changed did not get updated with the new default message.

I'm updating the database with the correct information and it should fix the problem.

That is kind of weird.

dww’s picture

dww
we/he/they
commented
Title: E-mail confirmation message is hard coded in signup.install » Site-wide default settings don't warn you that they only operate on new nodes, not existing ones
Version: 6.x-2.x-dev » 6.x-1.x-dev
Component: Email » User interface

Lots of people keep getting confused by this. Ultimately, all these email templates should be ripped out and redesigned -- see #290305: Split out email functionality into separate submodule(s). However, until that happens, we should probably make the help text on the settings page more obvious, and when you save it, it should print a "warning" that you only changed the defaults for new nodes, and all the settings on existing nodes are untouched.

doublejosh’s picture

doublejosh commented

Having this same problem too.
What really disturbed me was that for nodes where NO "Confirmation email" text was entered it does not use the default.
That is the normal behavior for the concept of a default, furthermore defaults should NOT be stored as data with each new node.
If a node's confirmation email is not filled out it should go to the default.

It seems to me this could be fixed with a simple empty test, without having to be "ripped out and redesigned."

Just change this function signup_send_confirmation_mail() to fix the blank using default issue.
Additionally this could be further fixed by conditionally inserting defaults during the signup_save_node() function.
These two changes would fix these defaulting issues, without a massive redesign.

function signup_send_confirmation_mail($signup, $node) {
  $user_mail = _signup_get_email($signup);
  if (empty($user_mail)) {
    return FALSE;
  }
  // HERE ARE THE CHANGES
  if($node->signup_confirmation_email != '') { $emailBody= $node->signup_confirmation_email; }
  else {
    // Get the defaults (not done by node type yet)
    $result = db_query("SELECT * FROM {signup} WHERE nid = %d", 0);
    $signup = db_fetch_object($result); 
    $emailBody= $signup->confirmation_email;
  }
  $node_type_name = node_get_types('name', $node->type);
  $params = array(
    'subject' => t('Signup confirmation for !node_type: !title', array('!node_type' => $node_type_name, '!title' => $node->title)),
    'body' => $emailBody,
    'node' => $node,
    'signup' => $signup,
  );
  // END CHANGES
  if (module_exists('token')) {
    $params['body'] = token_replace_multiple($params['body'], array('node' => $node, 'signup' => $signup, 'global' => NULL));
  }
  $language = user_preferred_language($signup);
  return  drupal_mail('signup', 'signup_confirmation_mail', $user_mail, $language, $params);
}

(PS: A single node could still accomplish a blank email with a $nbsp; if that's an issue.)

doublejosh’s picture

doublejosh commented

Ping! Seems like a serious flaw in a major module with s simple solution. Worth the small fix to me do I need to make the patch?

doublejosh’s picture

doublejosh commented

Seems straightforward, no?

kierenmccarthy’s picture

kierenmccarthy commented

I can't believe this still hasn't been sorted out. I've had people forwarding me the default messages - doesn't look very professional.

But @Passionate_Lass has a solution above: "I'm updating the database with the correct information and it should fix the problem..."

My question is: what is the best way to do that?

doublejosh’s picture

doublejosh commented

Haven't tested against any new releases but this could be fixed to work so much smoother with my fix in #3 above.