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.
| Comment | File | Size | Author |
|---|---|---|---|
| #23 | privatemsg_mail_edit2.patch | 6.29 KB | berdir |
| #17 | privatemsg_mail_edit.patch | 5 KB | berdir |
Comments
Comment #1
walker2238 commentedAnyone know how to do this with hook_menu_alter?
Comment #2
berdirChanging 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
Comment #3
walker2238 commentedI'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.
Comment #4
walker2238 commentedWell 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.
And then we add the hook_user function to provide the form on the edit settings page.
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?
Comment #5
walker2238 commentedAfter further testing this doesn't work at all. All it does it add the form but the changes don't take effect.
Comment #6
berdirYes, 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...
Comment #7
walker2238 commentedOkay 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.
Ands heres my version of hook_user
Comment #8
berdirYou 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.
Comment #9
walker2238 commentedOkay 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.
Comment #10
TapSkill commentedI 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.
Comment #11
litwol commentedFJGamer rewrite your post in a less condescending tone with more constructive suggestions and you might actually get some help. cheers.
Comment #12
TapSkill commentedlitwol, 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.
Comment #13
walker2238 commentedFJGamer 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.
Comment #14
walker2238 commentedAlso 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.
Comment #15
berdirYes, 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:
Comment #16
berdirEdit: double post
Comment #17
berdirTry the attached patch. You were quite close, but there were a few wrong bits and pieces :)
Comment #18
berdirI think we should do this, so setting the correct category...
Comment #19
naheemsays commentedThis 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:
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.)
Comment #20
naheemsays commentedMoving 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.
Comment #21
berdirHm, 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.
Comment #22
naheemsays commentedok, 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.
Comment #23
berdirOk, cool.
And it is not something we introduced in this patch and no-one has complained so far...
Updated the constants...
Comment #24
naheemsays commentedok, seems good to go.
Comment #25
litwol commentedLooks good. cheers.