[drupal-devel] More flexible user profile page - blocks to the rescue

Moshe Weitzman weitzman at tejasa.com
Thu May 26 20:28:41 UTC 2005

So I'm looking at how to make the user profile page prettier and more 
useful. I'm using the various social networking sites for ideas. Here 
are 3 sample pages in case you are curious:


The user profile page is actually quite simple. The rendering function 
[theme_user_profile()] accepts an associative array where a key is a 
'category name' and a value is a hunk of HTML. The categories are 
defined by the modules which are active. The order of the categories is 
defined by alphabetical order of module names. Note that any module can 
inject content onto the profile page, not just profile.module. This is good.

In order to make this more flexible, we want to give the admin the 
choice of which items to show and where to show them. And perhaps give 
the user the ability to customize his profile page. It turns out that we 
already have a great system for managing this - blocks.

Ideally, I think we could reuse the block admin page for profile page 
admin. There, admin will decide which 'categories' appear where, and 
even reuse logic like whether a category may be enabled/disabled by a 
user. We would not use the feature of blocks to turn on and off by path 
since the profile page only has one path.

I'm interested in your thoughts about how this could be implemented from 
a UI perspective. My inclination is to add a new page for profile admin 
which reuses code from block.module. I'm not inclined to move block code 
into a block.inc, especially because block.module is required. I'd like 
to reuse the blocks table.

I'm not sure how this fits into the 'block regions' work in progress. It 
would be nice to have more regions than left/right. Even without more 
regions, this would be useful than our current 'single column' model. 
Perhaps chx or nedjo could comment on this.

Also, I'm not sure that grouping profile items into 'categories' is 
useful in this model. We might be better off copying hook_block() and 
letting modules declare their own blocks instead of fitting their items 
into arbitrary categories.

Lastly, there is a chance that all this work inhibits sites which 
implement their own theme_user_profile(). They are currently able to do 
whatever they want with categories but I'm not so sure we can preserve 
this using the block paradigm.

Feedback welcome. I'm not planning on starting code on this immediately. 
In fact, I'd be pleased if someone else wanted to run with this.

More information about the drupal-devel mailing list