A well wrestled-with Drupal problem you are sure to come across at some stage is that of theming your user profiles. Profile support in the core is available, but it is not very well architected and your options to theme profiles are clumsy and fairly limited. I'll list them, in order of my preference:
- Theming: You can capture and redirect the profile theming function in your template.php file and rebuild it the way you want it in a template file. This is well documented on Drupal.org, but the approach does not respect the architecture of Drupal and could cause you headaches down the line as well as being time consuming, because you effectively rebuild the Profile module's output from scratch. And if you change your theme, you lose all your changes.
- Usernode: This module works by exposing profile data within a wrapper node called the Usernode. It represents a different mechanism for exposing profile data which is more akin to the way PHPTemplate expects content to be exposed to it, but isn't amazingly flexible and the user profile content is exposed as one entity. As such, injecting anything within it is impossible achieve without being back at square one, re-coding the theming functions (and other hacks) from scratch. Usernode is useful, in conjunction with Views, for creating user list pages, etc. but it isn't hugely helpful for this problem.
- Module: This approach is not really documented at all, but you can write a module which, using hook_menu and callback functions, builds replacement dynamic user pages - again, you are effectively re-writing the output of the Profile module, but at least it will be portable and reusable. If you change your theme, your profile pages remain, because the code is in a module and not in the templating layer. If you adopt a similar approach to Usernode, including the PHPTemplate over-rides, this is probably the most architecturally respectful approach which offers both flexibility and architectural benefits.
I don't like any of these approaches. They all require a bunch of work and the first two require me to do this work every time I hit on the usecase with a new client. Sure, I'll get good at it, copy and paste whole chunks of code and it will get quicker each time I do it, but there's another problem. If my client wants to move some blocks of content around I can hardly expect them to start hacking at my module/template files. They'll have to call me, and pay me, and they won't like that because they've paid for a content management system.
I was just about resigned to taking the third approach and explaining the limitations to clients, when some research born out of my discovery of Panels the other week turned me on to Advanced Profile (See this thread on Drupal.org if you want to read the background.) User profiles as Panel pages? Awesome!
Because it is my general policy to stick to supported point releases when selecting modules, I ignored Panels 2 when I installed it, however Advanced Profile requires Panels 2 and is in an early state itself. I discussed the pros and cons of using a Beta module on a production site with my client and he decided to accept the risk, especially since the developer of Advanced Profile, Michelle, was of the opinion that both modules are bug-free and effectively production-ready, although not formal point releases.
We've never looked back.
Advanced Profile, as Michelle pointed out to me, is really just the "glue" between a few modules which exposes an automatically generated, ready to use Panel page specifically for over-riding the user profile pages with Panels-driven content. It needs Panels 2 because this version of Panels actually supports arguments in the URL, a concept borrowed from Views allowing for dynamic URLs. Panels 1.3 could only have panels with static URLs which is no good for something like user profile pages.
The other really cool thing about Panels 2 is the flexible layout option, which allows you to specify an infinite number of regions on the page in rows and columns, as well as merging columns as you can with HTML tables, for truly flexible page layouts. And all this has an AJAX-driven, drag and drop interface for your clients.
So, if you have user profile layout requirements and you're breaking your brain for a way to do this with the minimum of fuss and provide your clients with a mechanism to manage the layouts themselves, look no further.
One word of warning. When you install Advanced Profile and Panels 2, Advanced Profile exposes a Latest Comments block provided by Panels 2 by default on the new User Profile Panel page. This results in an ugly PHP warning when you first load the page, if you are not using the core Comments module (there are numerous good reasons why this may be the case). The cause is Panels 2 assumes you are using core Comments and not an alternative, such as Node Comments. It doesn't check if Comments is installed and handle it gracefully. Instead it just bullishly attempts to load the comments directly from the Comments module's schema, regardless. Delete this block from the default user page and the warnings are gone. =)
Just by way of a note, Panels is the brain-child of the Angry Donuts developer who goes by the name of Merlin, a slightly cantankerous individual cut from classic developer cloth (RTFM, etc.) but provider of probably the single two most useful Drupal modules ever: Panels and Views. So in my book, he's a genius.