[drupal-devel] [feature] New block to show info on page author
nedjo
drupal-devel at drupal.org
Sun Apr 17 19:15:53 UTC 2005
Issue status update for http://drupal.org/node/20115
Project: Drupal
Version: cvs
Component: profile.module
Category: feature requests
Priority: normal
Assigned to: Anonymous
Reported by: nedjo
Updated by: nedjo
Status: patch
Attachment: http://drupal.org/files/issues/profile-content-author-block2.patch (5.21 KB)
Thanks for the review. Here's a new patch addressing issues and
suggestions.
* uses suggested fix for array error
* displays all profile fields in block config, but hides private fields
from users without appropriate permissions in block
* includes better documentation of behaviour in block config
* uses 'access user profiles' permission
* removes counterintuitive display of all fields if none were selected
* removes nodeapi use
* uses 'information' instead of 'info'
I agree that better presentation would be nice, and welcome suggestions
or reworkings.
nedjo
Previous comments:
------------------------------------------------------------------------
April 7, 2005 - 01:34 : nedjo
Attachment: http://drupal.org/files/issues/user_content_author_block.patch (2.62 KB)
It would be nice to have a quick way to display information about page
author/posters. The attached patch creates a new 'Author info' block
for the user module, which (if enabled) displays only when a node is
being viewed, showing the user name (as block title), picture,
signature, a list of up to four recent posts (plus 'more' link, if
tracker module is enabled, and user has posted more than four times)
and link to contact author (if contact module is enabled and user is
set to accept contacts). The general idea: get a feel for the author
at a glance, without having to load the full user page.
------------------------------------------------------------------------
April 7, 2005 - 11:08 : samo
I really like this. Thank you!
------------------------------------------------------------------------
April 7, 2005 - 12:15 : syscrusher
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")
------------------------------------------------------------------------
April 8, 2005 - 02:17 : nedjo
Thanks for the comments.
"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?
"
Yes, thanks to Drupal's modularity and good set of hooks, this addition
would be possible as a stand-alone module. 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. In any case, I
don't favour a separate module for each tiny bit of functionality (and
I already have enough modules on my hands!). If there isn't support
for core inclusion, I suppose the option would be rolling this into
another user-related module; perhaps Bèr's userposts [1] would be a
candidate.
"It would ... eliminate the need to persuade the core team to accept
this into core.
"
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!
[1] http://drupal.org/node/10593
------------------------------------------------------------------------
April 8, 2005 - 03:14 : Dries
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.
------------------------------------------------------------------------
April 8, 2005 - 08:46 : syscrusher
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")
------------------------------------------------------------------------
April 8, 2005 - 13:12 : Dries
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.
------------------------------------------------------------------------
April 8, 2005 - 23:38 : nedjo
Thanks for the tips and suggestions.
I agree that too many links are clutter, and a single "view my profile"
would do in most cases. Still, e.g., a quick list of recent posts might
be useful here.
I also agree that use of the signature here would be problematic. One
option would be a separate patch to add an "about" field (and maybe
also a "full name" one) to user.module.
Another option would be to use the custom profile fields here. I'm
thinking of an approach that would have a set of block configuration
checkboxes for elements to display in the block--the ones I've included
(picture, recent posts, etc.) and then each of the defined profile
fields. That way, the user info displayed could be easily customized.
Of course, this would depend on admins installing profile.module and
adding profile fields.
Thoughts on which of these two approaches would be better?
------------------------------------------------------------------------
April 9, 2005 - 09:13 : syscrusher
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!
------------------------------------------------------------------------
April 12, 2005 - 15:34 : Dries
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.
------------------------------------------------------------------------
April 12, 2005 - 19:54 : Boris Mann
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.
------------------------------------------------------------------------
April 14, 2005 - 13:23 : nedjo
Attachment: http://drupal.org/files/issues/profile-content-author-block.patch (5.72 KB)
Here's a new version that addresses suggestions. I've moved the patch
to profile module, since it's not of much use unless there are custom
profile fields defined. Features:
* Makes fields to display configurable (through block configuration)
* Adds ability to display info on node pages (through nodeapi--content
type specific setting)
So the block can be used either as a block or as part of node pages.
(Note: I changed function theme_profile_profile() to accept an
additional optional argument, $field_titles (defaults to false), to
display profile field titles in the block (needed for clarity).)
------------------------------------------------------------------------
April 17, 2005 - 11:54 : Dries
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).
More information about the drupal-devel
mailing list