Provide user view categories as separate panes

Nope. profile_fields.inc covers profile.module.

I wanted to mean profile categories as built by user_build_content() in user.module. This is what user_profile.inc implements, but it wants to output all categories. BTW, this content type does not work. hook_user('view') does not return data, rather it builds $account->content. This is a different issue, though... or maybe not.

One problem I see if we want to provide a form to select categories, is that we don't have a real user context yet, so we can only guess profile categories by using the current user account, or something similar. So ideally, we would have to provide a method that allows us to select profile categories at runtime. We already have hook_profile_alter(), but this is also invoked by user module when building the user profile page. So, maybe we could add an additional drupal_alter() here, say hook_ctools_profile_alter($account, $subtype, $conf, $panel_args, $context). ¿?

I have filed a separate issue, bug report, to fix user_profile content type: #569508: Fix and clean up of user_profile content type.

Once that one is fixed it should be easy to focus on how we could extend this content type to add the ability to choose user profile elements, so that we can position them independently on a pane.

Now that the other patch has been committed, I believe it is now easier to see what can done here.

I've been thinking about it for a while, and it is not possible to guess which user view categories and elements are going to be available in real-time. Note that these categories are added by 3rd party module using hook_user('view'), and they may not generate anything depending on several factors, user pesmissions, settings, etc.

So I think if we want to be able to show only one set of these items in panels, we need some kind of real-time hook. Here's what I think it could be done.

1) We can add a text field to the settings form of this user_profile content type. It could be labelled "keyword", for example. And the form (which is now empty), becomes something like this:

/**
 * Returns an edit form for custom type settings.
 */
function ctools_user_profile_content_type_edit_form(&$form, &$form_state) {
  $conf = $form_state['conf'];

  $form['keyword'] = array(
    '#type' => 'textfield',
    '#default_value' => !empty($conf['keyword']) ? $conf['keyword'] : '',
    '#title' => t('Keyword'),
    '#description' => t('This keyword will be added to the account object when passed to <a href="@user-build-content">user_build_content()</a> and it can be checked from your implementation of <a href="@hook-profile-alter">hook_profile_alter()</a> to filter user profile categories. When no keyword is specified, or if you do not implement hook_profile_alter() to filter out items, the whole user profile will be rendered.', array(
      '@user-build-content' => 'http://api.drupal.org/api/function/user_build_content/6',
      '@hook-profile-alter' => 'http://api.drupal.org/api/function/hook_profile_alter/6',
    )),
  );
}

2) This keyword is attached to the $account object before user_build_content() is invoked. And user module will then invokes hook_profile_alter() where we can check for the ctools keyword we added here, and alter the $user->content structure accordingly.

+  // Pass user specified keyword to hook_profile_alter().
+  if (!empty($conf['keyword'])) {
+    $account->ctools_keyword = $conf['keyword'];
+  }

   // Retrieve all profile fields and attach to $account->content.
   user_build_content($account);

3) Our implementation of hook_profile_alter() could look like this:

/**
 * Implementation of hook_profile_alter().
 */
function my_custom_module_profile_alter(&$account) {
  if (!empty($account->ctools_keyword)) {
    // Here we know we're rendering a user profile content type in panels, and we
    // can alter the output of this particular pane in real-time.
    // Note that $account->content contains the rendered items of the user profile.
  }
}

Attached patch implements this. Thoughts?

Just wanted to mention that I do not really need this feature in CTools. I'm just using a custom module because I need to implement custom code for my hook_profile_alter().

I'm leaving this issue as-is, though, just in case it can be useful to others. ;-)

If there was a way to know ahead of time what can come from hook_user('view') implementations, then it would have been easier to implement this in a more generic way that's easy to setup, but unfortunately there isn't, and we need to use custom code, so...