tplify user module

Thinking about it further, drupal_render should be used from the .tpl file with some good documentation. That's the direction it was taking originally. Will try to clean it up a bit.

Is there a reason for theme_user_signature() ? It never gets called.. all coded into comment.tpl.php. Since it's only used for comments, I'll remove that function.

And what's with user_comment()? It seems to do nothing.

function user_comment($comment, $op) {
  // Validate signature.
  if ($op == 'view') {
    if (variable_get('user_signatures', 0) && !empty($comment->signature)) {
      $comment->signature = check_markup($comment->signature, $comment->format);
    }
    else {
      $comment->signature = '';
    }
  }
}

Nothing is returned.

Patch will be up later today.

Here it is. theme_user_profile now has 2 parameters. $account & $profile. It was originally just $account with all the profile information attached as an object as $account->content done from "user_view". I did this so themers don't have to access all the fields with $account->content[foo][bar], Now it's just $profile[foo][bar]. Might not be a big deal but I think it helps simplify the template a bit and it shouldn't affect anything else.

On another note, I was trying to figure out a way to create dynamic variables for the template files so theming didn't require accessing multi-dimentional arrays.

Instead of:
print drupal_render($profile['profile_CATEGORY']['profile_SUBCATEGORY']['profile_ITEM']);

We would have:
print drupal_render($profile[$profile_ITEM]);

$profile_ITEM just being an array of keys that point to ['profile_CATEGORY']['profile_SUBCATEGORY']['profile_ITEM']. I'm not even sure it's possible but if it is, it would be a lot simpler since $profile_ITEM would just be the name of the profile the site has configured.

Anything in between can also be progressively rendered since $profile is independent of these keyed variables.

I forgot to mention theme_user_signature() is intact. Searched around and found it's part of Webchicks sig patch that was postponed.

I stuck with categories since the same terminology is used when configuring profiles in the admin pages.

Also changed items to fields to match for the same reason.

Function name was changed from *user_profile_item to *user_profile_field for more consistency but this means that the profile patch needs to be applied also. It's called once from there.

http://drupal.org/node/162134

More documentation. I hope it's more clear.

Minor doc changes to remove any mention of items.

Ack! I'm having second thought about exposing drupal_render() inside user-profile.tpl.php.

I made this note in there:

/**
 * @file user-profile.tpl.php
 * Default theme implementation to present user profile fields and categories
 * (field groups).
 *
 * This template is used when viewing a registered member's profile page,
 * e.g., example.com/user/123. 123 being the users ID.
 *
 * In order to customize, replace the HTML below with your own wrapper and use
 * drupal_render($profile['foo']) or drupal_render($profile['foo']['bar']) to
 * print them out where you want each piece of the data to appear. Replace the
 * 'foo' and 'bar' in the example above with the desired element, e.g.,
 * drupal_render($profile['contact']['profile_phone']). Each key will
 * correspond to profile categories and fields configured for the site.
 *
 * In the above example, the first key of 'contact' is the category. This
 * value would be configured by a site administrator.
 * @see user-profile-category.tpl.php where the html is handled for the group.
 *
 * The 'profile_phone' key is the child of the 'contact' group. In this
 * example, it would contain the value of a textfield the user has entered for
 * their phone number.
 * @see user-profile-field.tpl.php where the html is handled for the field.
 *
 * drupal_render() will keep track of what has been rendered. After printing
 * out all the specific groups or fields, make sure to call
 * drupal_render($profile) one last time so it can output all the other groups
 * and fields that were not specifically called.
 *
 * Also keep in mind when targeting specific fields with drupal_render(), the
 * template for rendering categories will not be used.
 * user-profile-category.tpl.php and user-profile-field.tpl.php contain html
 * markup which are dependent to one another. <dl> inside categories and <dt>
 * & <dd> for the fields. Make sure a matching parent tag is used as a wrapper
 * in this template when directly rendering fields.
 * ...

So, invoking something like drupal_render($profile['category']['profile_field']) would result in a few complications.

'profile_field' renders the field only. The markup from 'category' is ignored. user-profile-category.tpl.php contains the title for the category and a tag for containing definition lists. But what happens when calling drupal_render($profile) to spit everything else out? That category template gets rendered and if it doesn't contain anymore fields (due to targeting all fields within the category) the junk from user-profile-category.tpl.php prints out completely misplaced.

Dries, Merlinofchaos, anyone..? This this is acceptable?

I have another idea. Can't explain it yet since I'm not sure about it but I'll post it in a bit.

Okay.. here is another version.

drupal_render is done from template_preprocess now. Each category is keyed so it can be printed directly. I think this is a lot simpler. I don't think there's a need to access individual items directly from user-profile.tpl.php. The order of each field can be changed with weights.

user-profile-field was changed back to user-profile-item.. sigh.

Parameters for *user_profile() changed back into a single parameter. user_build_content($account) automatically added $account->content with the array ready for drupal_render.

Those "raw" arrays didn't have much value to theming so I removed the docs on them. It's still there since it's automatically passed along. Tweaked the rest of the docs a bit more too. Please review.