Tell me more ×
Drupal Answers is a question and answer site for Drupal developers and administrators. It's 100% free, no registration required.
up vote 1 down vote favorite

My aim is to create a new menu item and display the user profile form on that page.

Here is the code I am using.

/**
 * Implements hook_menu().
 * 
 */
function profile_preferences_menu(){
    $items['user/%/edit/profile-preferences'] = array(
        'title' => t('Profile Preferences'),
        'page callback' => '_profile_preference_display_preference',
        'page arguments' => array(1),
        'access arguments' => array('access profile preferences'),
        'type' => MENU_LOCAL_TASK,
        'weight' => '0'
    );
    return $items;
}

/**
 * Implementation of hook_permission().
 */
function profile_preferences_permission() {
    return array(
        'access profile preferences' =>  array(
            'title' => t('Access List of profile preferences'),
            'description' => t('Access permission to view all the profile preferences.')
        ),
    );
}

/**
 * Function to fetch and display preferences form.
 */
function _profile_preference_display_preference() {
    global $user;
    module_load_include('inc', 'user', 'user.pages');
    $form = drupal_get_form('user_profile_form', $user, 'account');
    unset($form['account']);
    return $form;
}

When I access it using the administrator account, it works perfectly; when I access using another user account (who has the required permission) it gives me the following error.

enter image description here

I wonder if there is any issue with the implementation of hook_menu().

share|improve this question
1  
As side note, title and description of a menu item should not be passed to t(); that is automatically done by Drupal core code. – kiamlaluno♦ May 15 at 8:18
Remove this line: unset($form['account']);. That should fix the warning – Clive♦ May 15 at 8:21
What is exactly the purpose of showing the user edit form without some of the form fields? Users can edit their account information / preferences without editing their username (which can be edited only from users with one of the following permissions: administer users or change own username), email, or password. – kiamlaluno♦ May 15 at 9:57
I don't know if this is the error but your path should be user/%user/... rather than user/%/... – Alfred Armstrong May 15 at 9:59

1 Answer

up vote 1 down vote accepted

The code that is causing the error is the following one, executed from DrupalDefaultEntityController::load().

  // Create a new variable which is either a prepared version of the $ids
  // array for later comparison with the entity cache, or FALSE if no $ids
  // were passed. The $ids array is reduced as items are loaded from cache,
  // and we need to know if it's empty for this reason to avoid querying the
  // database when all requested entities are loaded from cache.
  $passed_ids = !empty($ids) ? array_flip($ids) : FALSE;

I could not track down which function is calling user_load() or a similar function to load a user entity. As far as I can see, the form validation and form submission handlers added to the form use $form['#user'] or $form_state['user'] (which is set from the $account parameter passed to user_profile_form()). Keep in mind that $form and $form_state are used when saving the entity, such as in the following function call done from user_profile_form_submit().

entity_form_submit_build_entity('user', $account, $form, $form_state);

It is always a bad idea to unset a form item, as that would be causing problems with the code that expects those form items to be present.
Removing them, you are also avoiding that the corresponding items in $form_state['values'] are present. This is probably causing the error you see.

As side note, your page callback is getting a parameter, but that is not used. Instead, your code is using the global user object, which means the shown form is for the currently logged in user, not for the user whose ID is passed in the URL.

I would also change user/%/edit/profile-preferences with user/%user/edit/profile-preferences. The latter automatically validates the user ID and loads the user object, which is then passed to the page callback.

share|improve this answer
@clive I have removed unset($form['account']) code, but still it is not working. My point of view if there is problem with unset($form['account']) then it should not work all the account, but in my case code is working fine for admin account, it doesn't work for authenticated users role – mohit_rocks May 15 at 9:34
It all depends from the code that is executed. Surely, there is a module that is loading a user entity when I would not expect it to happen (since the user object is already available on $form_state['user']). I cannot say if it is a Drupal core module that does it, or a third-party module. Since the same error doesn't happen with the user account form showed by Drupal in user/%user/edit, there must be something that interferes with the form. – kiamlaluno♦ May 15 at 9:45

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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