New block to show info on page author

I really like this. Thank you!

I haven't had time to try the patch yet (though I will try to do so as time permits), but +1 on the concept. This would be really useful to me on one of my main sites. Giving more visible credit to contributors is IMO a Very Good Thing, because it subtly encourages more such contributions.

Just one question: Would it be feasible to implement this as a module that hooks the block, user, and node APIs, rather than as a patch to user.module? It would decouple the code, keep user.module smaller and easier to maintain, and eliminate the need to persuade the core team to accept this into core.

Thanks for a great idea, and I look forward to trying out the code soon.

Scott ("syscrusher")

Looks like a nice patch worth including into core. Some suggestions:

1. theme_item_list() takes an optional $title. No need to emit a title yourself. Even better to use node_title_list(). Take a look at forum_block().

2. Often the signature won't be as nice a real bio. I fear that this patch will lead to weird signatures, or, weird bios. I don't know but it might be a good idea to introduce an about field to complement the signature, and to use that instead.

3. $output .= $links; looks like dead code.

4. if ($account->contact) does not guarantuee that the contact module is enabled. It can be (temporary) disabled.

nedjo wrote:

But I'm thinking this may be a common enough desire - on a par with the existing user.module blocks (who's online, who's new) - to justify core inclusion.
[...]
I hear you. In my case, it's more than a year, many hours of coding, and 10 or so patches later and I've yet to see one make it into the core. Not quite sure why I keep trying, but I guess I keep thinking maybe some day I'll get lucky!

Given Dries' comments, I think you just did. :-) If Dries thinks this belongs in core, that's good enough for me. I certainly will use it, so no complaints from here if it comes bundled with Drupal core.

Great work!

Scott ("syscrusher")

You probably want to add a link to the user page (user/x) using format_user(). Actually, from the user page, you can both contact the author or track his contributions. Take a look at how Blogger does this: http://www.evhead.com/2005/04/sara-mosaic.asp. They hired some of the best usability experts for that so why not learn from them? Less links is better IMO. Every Drupal page already has plenty of links as it stands.

I think definitely the best option is to allow the site admin to select from among the custom profile fields. It's easy to determine if profile.module is installed, and since that module is now part of core, it's reasonable to assume that it most often will be. Use of the profile fields also can "fall back gracefully" to just the minimal data, if profile.module happens to be disabled.

FWIW, I agree with the person who suggested that the "recent posts" might be a little too much for within the block. How about offering an option for that info: (1) list of posts in the block, (2) link to the user's existing recent posts page (from user.module), (3) none of the above. A three-way selection rather than a checkbox would accomplish this.

Great work, btw!

Quick thought: on most websites, the author information block is shown below the article. It is probably worth keeping this in mind as people will most certainly ask for that.

Dries: please do not pre-suppose your own ideas of how "most" websites are built. Drupal blocks are going to be the primary way that non-technical users are going to access this type of feature.

What I would suggest, is that the content of this block is also made available through a theme call. Then, advanced users can re-use it wherever they want.

I got the following warning when visiting 'node/x' with the "Author info" block enabled:
Warning: in_array() [function.in-array]: Wrong datatype for second argument in drupal-cvs/modules/profile.module on line 233

Can we make that "author" block or "author information" block? We try to avoid abbrevations like 'info'.

Either way, I fixed that problem by writing:
$use_fields = variable_get('profile_block_author_fields', array());
insted of:
$use_fields = variable_get('profile_block_author_fields', null);

Even though I have some profile fields setup, I couldn't configure the block's fields. I had to look at the code to figure out that the fields' visibility must be configured as "Public field, content shown on profile page and on member list pages" in order for the fields to show up. Why not let me configure all public fields? I was also surprised that such fields were automatically shown even though none of the fields were checked or activcated, they were shown in the author block. Is that a bug?

To conclude, the behavior of that block wasn't predicatable. It was confused at first because I couldn't get public fields to show up. Later, when I got it to work (i.e. by making them public on listings too), I was surprised because the behavior did not match my expectation (i.e. the fields where automatically shown). To fix, (i) I'd allow the user to select from all public fields, and (ii) I'd make sure public fields are not automatically shown. Also, (iii) I'd document the behavior and the interaction with the profile module on the "author" block configuration screen (in laymen terms, that is).

I'm not finished testing yet -- I want to see how it behaves with avatars. I'll report back on that later. I'm not too excited with the current look of the block, but more about that later.

Also, I think we should use the new user permission to protect access to that block, not the 'access content' permission.

For now, I think I'm favor of removing the nodeapi integration. We might get that for free after the theme regions patch (as Boris hinted).

Committed to HEAD, though I rewrote part of the patch to improve the themability of the block, as well as its default look. I also left out the 'Recent posts' for now and shuffled some code around.