I'd just like to inquire about how to move the e-mail notify settings to the edit profile page. The reason being that most settings that a user can change are located there.

Comments

walker2238’s picture

Version: » 6.x-1.x-dev

Anyone know how to do this with hook_menu_alter?

berdir’s picture

Changing that makes sense I think, not sure if it should be a tab or just a fieldset though..

Feel free to provide a patch, http://drupal.org/patch

walker2238’s picture

I've actually been having troubles with this but I'll start over again sometime today. Probably best if I try to look and see how other modules do it.

My thoughts were to have it as a fieldset. The main reason being that the form is small, and doesn't really have a need for it's own tab. However if you make it a tab I believe there is a module users can use to make all children tabs of the edit tab combined. So a tab also might be a more flexible solution. onepageprofile might be the name of the module... not sure though.

walker2238’s picture

Well I took a shot. I honestly have no idea what i'm doing, so I took the road most traveled and decided just to use the form as opposed to a tab. I just bought Pro Drupal Development second edition so I'm fairly new to doing stuff outside of themes. Maybe someone else could provide a patch, but I have taken some time to try and figure this out.

So far I think it works. I tested it out briefly and no issues came up. But the route I took was via hook_menu alter and hook_user... But I guess that in the pm_email_notify module you would no long need $items['messages/notify'], as the only purpose of using hook_menu_alter was to unset/remove the messages/notify page.

Heres a quick run down... As stated if this was an actual patch we wouldn't need hook_menu_alter... but here it is anyways.

/**
* Implementation of hook_menu_alter().
*/
function mymodule_menu_alter(&$items) {
unset($items['messages/notify']);
$items['messages/notify']['access callback'] = FALSE;
}

And then we add the hook_user function to provide the form on the edit settings page.

/**
 *  Implementation of hook_user()
 */
 function mymodule_user($op, &$edit, &$user, $category = NULL) {
   switch ($op) {
    case 'form':
 if ($category == 'account') {
   global $user;
  $form['enable_pm_mail'] = array(
    '#type' => 'fieldset',
    '#title' => t('Privatemsg e-mail notification'),
    '#collapsible' => TRUE,
    '#collapsed' => FALSE,
  );
  $form['enable_pm_mail']['enable'] = array(
    '#type' => 'radios',
    '#title' => t('Receive email notification for incoming private messages?'),
    '#options' => array(
      PM_EMAIL_NOTIFY_DISABLE => t('No'),
      PM_EMAIL_NOTIFY_ENABLE => t('Yes'),
    ),
	'#default_value' => isset($edit['enable']) ? $edit['enable'] : 1,
  );
  return $form;
}
      break;
}
}

So yeah... it works but I have a feelings it's also fairly dirty... Any thoughts?

Berdir i'm not ignoring your request for me to provide a patch. I've never done it before. I had a quick look and, it looks like something I'll have to learn later this week. It does look a bit intimidating.

Also I would there be a need for pm_email_notify_user_settings_form() after these changes?

walker2238’s picture

After further testing this doesn't work at all. All it does it add the form but the changes don't take effect.

berdir’s picture

Yes, because you don't process anything.

You need to convert the function pm_email_notify_user_settings_form_submit to hook_user($op = 'submit'), I think.

Some things to change...
- remove that global $user line..
- rename 'enable', that is too generic...

walker2238’s picture

Okay I made those small changes. I changed 'enable' to 'pm_send_notifications' I'm not sure what you mean by converting the function pm_email_notify_user_settings_form_submit to hook_user($op = 'submit'). I tried to have hook_user as... hook _user($op = 'submit', &$edit, &$user, $category = NULL) if thats what you meant. I also took a look at the guestbook module and the code is as follows.

function guestbook_user($op, &$edit, &$user, $category = '') {
  $guestbook_mode = variable_get('guestbook_mode', GUESTBOOK_SITE_GUESTBOOK | GUESTBOOK_USER_GUESTBOOKS);
  if ($guestbook_mode & GUESTBOOK_USER_GUESTBOOKS) {
    switch ($op) {
      case 'view':
        if (user_access('access user guestbooks') && empty($user->guestbook_status)) {
          $title = t("Read @username's guestbook.", array('@username' => $user->name));
          $link  = l(t('View recent guestbook entries'), "user/$user->uid/guestbook", array('attributes' => array('title' => $title)));
          $user->content['summary']['guestbook'] = array(
            '#type' => 'user_profile_item',
            '#title' => t('Guestbook'),
            '#value' => $link,
            '#attributes' => array('class' => 'guestbook'),
          );
        }
        return;

      case 'form':
        if ($category == 'account') {
          $form['guestbook'] = array(
            '#type' => 'fieldset',
            '#title' => t('User guestbook'),
          );
          $form['guestbook']['guestbook_status'] = array(
            '#type' => 'radios',
            '#title' => t('Status'),
            '#default_value' => isset($edit['guestbook_status']) ? $edit['guestbook_status'] : 0,
            '#options' => array(t('Enabled'), t('Disabled')),
          );
          $form['guestbook']['guestbook_send_email'] = array(
            '#type' => 'checkbox',
            '#title' => t('Send email notification'),
            '#description' => t("Uncheck if you don't wish to be notified of new entries to your guestbook."),
            '#default_value' => isset($edit['guestbook_send_email']) ? $edit['guestbook_send_email'] : 0,
          );
          $form['guestbook']['guestbook_intro'] = array(
            '#type' => 'textarea',
            '#title' => t('Intro text'),
            '#default_value' => isset($edit['guestbook_intro']) ? $edit['guestbook_intro'] : '',
            '#cols' => 70,
            '#rows' => GUESTBOOK_TEXTAREA_ROWS,
            '#description' => t('The text that appears on top of your guestbook.'),
          );
          return $form;
        }
    }
  }
}

Ands heres my version of hook_user

 function mymodule_user($op = 'submit', &$edit, &$user, $category = '') {
   switch ($op) {
    case 'form': // Here we add the email notify form from privatemsg to the edit profile page.
 if ($category == 'account') {
  $form['enable_pm_mail'] = array(
    '#type' => 'fieldset',
    '#title' => t('Privatemsg e-mail notification'),
    '#collapsible' => TRUE,
    '#collapsed' => FALSE,
  );
  $form['enable_pm_mail']['pm_send_notifications'] = array(
    '#type' => 'radios',
    '#title' => t('Receive email notification for incoming private messages?'),
    '#options' => array(
      PM_EMAIL_NOTIFY_DISABLE => t('No'),
      PM_EMAIL_NOTIFY_ENABLE => t('Yes'),
    ),
	'#default_value' => isset($edit['pm_send_notifications']) ? $edit['pm_send_notifications'] : 0,
  );
  return $form;
}
      break;
}
}
berdir’s picture

You need to add a case for $op = 'submit', (or maybe insert and update) and save the information in the correct table (you can re-use the code from that function). Currently, it's just saved in the user table, but that's not what we access in our code.

walker2238’s picture

Okay well as you might be able to tell i'm doing this totally by trial and error. Thanks for your patience.

I added the submit case but still doesn't work... I hope I'm at least getting a bit closer.

 function fp_privatemsg_user($op, &$edit, &$account, $category = NULL) {
if ($$category == 'account') {
  
switch ($op) {

case 'form':
  $form['enable_pm_mail'] = array(
    '#type' => 'fieldset',
    '#title' => t('Privatemsg e-mail notification'),
    '#collapsible' => TRUE,
    '#collapsed' => FALSE,
  );
  $form['enable_pm_mail']['pm_send_notifications'] = array(
    '#type' => 'radios',
    '#title' => t('Receive email notification for incoming private messages?'),
    '#options' => array(
      PM_EMAIL_NOTIFY_DISABLE => t('No'),
      PM_EMAIL_NOTIFY_ENABLE => t('Yes'),
    ),
	'#default_value' => isset($edit['pm_send_notifications']) ? $edit['pm_send_notifications'] : 1,
  );
  return $form;
break;

case 'submit':
db_query("UPDATE {pm_email_notify} SET email_notify_is_enabled = %d WHERE user_id = %d", $edit['pm_send_notifications'], $account->uid);
break;

	}
  }
}
TapSkill’s picture

I would like everything on one edit page instead of lots of tabs. However, I don't understand how to work with Drupal's tabs or this module well enough to change this. You shouldn't assume everyone's an expert coder. If we were, we'd just do the work ourselves instead of waste our time requesting changes and rarely seeing any real help.

Drupal is a CMS; not a forum system (even if it has that functionality), so I can't expect all these features to be easily set up, either.

litwol’s picture

FJGamer rewrite your post in a less condescending tone with more constructive suggestions and you might actually get some help. cheers.

TapSkill’s picture

litwol, I wasn't even asking for help here... I was replying to Bendir, who was basically telling the person to do the work himself. Not everyone can code, and not everyone knows enough about Drupal or this module.

walker2238’s picture

FJGamer I appreciate what your trying to say, but I actually don't have a problem with it. Personally Bendir has helped me with a lot of previous issues. And at one point, was helping me out with about one issue a day.

walker2238’s picture

Also concerning all the tabs... post another issue. I had similar request and managed to do everything..... except validating this form with hook_menu_alter. I completely changed all the tabs.

berdir’s picture

who was basically telling the person to do the work himself

Yes, I did. What's wrong with that?

This is open-source. I developed (and I am still developing) *many* patches for this module, just because I like it and because I want to contribute something back. I do not receive anything for this, do not confuse me with a paid developer that you can blame if your custom program does not work.

I am really trying to help where I can, my tone might sound inappropriate for some, which is partly because I'm not a native speaker, but to be honest, I do not really care.

If you do not like something, you have three options:
- *ask* (and not demand) for help
- change it yourself
- pay someone to do it for you

You might want to re-read the following sentence of the GNU GPL, under which this project is published:

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
berdir’s picture

Edit: double post

berdir’s picture

Status: Active » Needs review
StatusFileSize
new5 KB

Try the attached patch. You were quite close, but there were a few wrong bits and pieces :)

berdir’s picture

Category: support » task

I think we should do this, so setting the correct category...

naheemsays’s picture

Status: Needs review » Reviewed & tested by the community

This works as expected, and the code looks good, so marking as rtbc.

However, I have not used this module as was surprised at the couple of instances of:

variable_get('pm_email_notify_default', PM_EMAIL_NOTIFY_ENABLE)

I would have thought disabled would be a better default? (not a problem with the patch, but the two constants should end in ENABLED and DISABLED IMO - the extra D at the end will show that it is not a command, but it is information.)

naheemsays’s picture

Status: Reviewed & tested by the community » Needs work

Moving to CNW over two things:

1. The constant names.
2. Bikeshedding over the the default choice.

granted, neither are related to this patch, but they can all be fixed at once.

My personal gut instinct over the bikeshed is that no module should start sending emails after being enabled - there should be a further step needed to activate the email sending - mainly in case the server is misconfigured, or to avoid accidental spam.

I can also see the other side as if you are activating this module, the whole reason is to allow the sending of emails, so the messages sent out would not really be accidental.

berdir’s picture

Hm, I will update the constants.

But it makes sense to be enabled by default imho. It's an additional sub-module that does send mails and nothing else. All those messaging_* sub-modules send mails/whatever when they are enabled too (unless they have to be configured) for example.

naheemsays’s picture

ok, not too fussed over what the default is - so leaving it as is is a good choice. This has the added bonus of not "breaking" the functionality for people who have already activated this module.

berdir’s picture

Status: Needs work » Needs review
StatusFileSize
new6.29 KB

Ok, cool.

And it is not something we introduced in this patch and no-one has complained so far...

Updated the constants...

naheemsays’s picture

Status: Needs review » Reviewed & tested by the community

ok, seems good to go.

litwol’s picture

Status: Reviewed & tested by the community » Fixed

Looks good. cheers.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.