1

I have a hook_form_user_profile_form_alter (hook_form_FORM_ID_alter) where I'm capturing user information that was changed when a user updates their profile.

I want some of that information available in hook_user_update, which is called after the form alter - maybe no more than 6 fields.

Is there a way to hold some of the information from the hook_form so it is available when I get to hook_user_update? I'm looking for a server side solution. In Java I could use class variables or session storage. I see PHP has session storage. Is that the best practice or is there's a Drupal specific solution or a better PHP usage pattern?

Since someone will probably ask why I don't perform what I need done in hook_form_user_profile_form_alter: That function gets called twice (which can be problematic) and I cannot be sure that the transaction is complete until I get to hook_user_update. So I feel that hook_user_update is a much better place to execute what I need to execute, because I'm synchronizing information with another application. I need to be sure the transaction went through before I perform the call to the other app.

Improve this question
2
  • It would be much easier to provide a good advice if you give some more information about data, that's available in hook_form_alter and not available in hook_user_update. Also if you just add custom #submit callback to user_profile_form_submit form, it will run AFTER drupal saves user and invokes hook_user_update.
    – m1r1k
    Commented Nov 22, 2013 at 18:42
  • I hesitated to mention that I'm interested in password information because that opens the door to all kinds of comments about worries regarding doing anything with a password. It seems like everyone becomes a security expert when the word password shows up. So, I opened the door, I'm hoping that anyone viewing this can just stick to the question and not get all worried about passwords! $form_state['input']['pass']['pass1'] would be the primary thing I'm after. I have some secondary targets, but I may be able to get that information from hook_user_update
    – Software Prophets
    Commented Nov 22, 2013 at 22:15

1 Answer 1

Reset to default
3

As far as I'm aware, all form element values entered by the user on the profile edit form are available in the hook_user_update()'s $edit argument. The only element that won't be there is the plain text password.

There is no "drupal way" to avoid this, as core handles this functionality and it's trying to stop you from accessing the plain text password.

REMOVING SUGGESTION PER @znerol. Will update later this evening

Improve this answer
10
  • I kind of figured this would be the solution and I agree that most everything seems to be available in the $edit argument, except for the plain text password. One question: I'm curious why you suggest adding a validate versus just adding the session assignment in hook_form_user_profile_form_alter?
    – Software Prophets
    Commented Nov 23, 2013 at 12:47
  • 1
    Because the validate function only gets called right after the user submits the form. If you put your validate/processing code in the form_alter() implementation, the form_alter() can get cluttered up pretty quick. IMO, better to keep form processing (validate) and form displaying (form_alter) code separate.
    – Joe Corall
    Commented Nov 23, 2013 at 13:53
  • @edl and anyone else, please do not follow the advice given in this answer. The content of $_SESSION superglobal gets stored into the database. Ultimately the clear-text passwords of your users will end up in the sessions-table in your Drupal database.
    – znerol
    Commented Nov 24, 2013 at 13:14
  • @jcorall: It would be much saver to use a normal global variable or the drupal_static pattern. Please update your answer and advice against using $_SESSION.
    – znerol
    Commented Nov 24, 2013 at 13:19
  • @znerol I appreciate you pointing out drupal_static. That's exactly what I was looking for when I said, "Drupal specific solution" above. I'm concerned though that you might be being unduly concerned? Noting that jcorall indicates that I should, "unset the plain text variable at the end of your hook_user_update() logic" that would likely ensure that it doesn't end up in the database, right? I don't know the lifecycle of $_SESSION as it relates to storage in the database, but it probably stores at the end of the request which would be well after the unset, so jcorall's answer is fine, right?
    – Software Prophets
    Commented Nov 25, 2013 at 12:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.