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

Bèr Kessels berdrupal at tiscali.be
Fri May 27 10:02:25 UTC 2005

We have been doing the exact same thing :)

Here is what i did:

theme_user_profile() now gets an associative array where a key is a  'category 
name' and a value is a hunk of HTML

That is un-theme-friendly. So i made it:
theme_user_profile() gets a n associative array where a key is a  'category 
name' and value is another array where key is fieldname and value is the 
value. Simple and it just wotrks.

IMO an admin UI interface for profiles is overkill: a simple 
user_profile.tpl.php /by default/ in phptemplate will do the trick. You can 
use that now, but you need to hop trough some hoops, like add template.php 
and functions in there. Not very hard, but too hard for Joe User. That 
userpofile ten gets the data as the abovementioned array, but also as a a few 
simple variables: $field_name = $value

Patches for this are in the pipeline, but i want to do some better testing, 
for example with duplicated fields and oddly named categories.

And while we are at it, can we not rename categories into "form groups" 
categories is already in use for taxonomy, and this causes confusion.


Op donderdag 26 mei 2005 22:28, schreef Moshe Weitzman:
> 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.
 [ Bèr Kessels | Drupal services www.webschuur.com ]

More information about the drupal-devel mailing list