Issue status update for http://drupal.org/node/20115 Project: Drupal Version: cvs Component: user.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: nedjo Updated by: samo Status: patch I really like this. Thank you! samo 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.

Issue status update for http://drupal.org/node/20115 Project: Drupal Version: cvs Component: user.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: nedjo Updated by: nedjo Status: patch 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 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")

Issue status update for http://drupal.org/node/20115 Project: Drupal Version: cvs Component: user.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: nedjo Updated by: syscrusher Status: patch 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") syscrusher Previous comments: ------------------------------------------------------------------------ April 7, 2005 - 00: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 - 10:08 : samo I really like this. Thank you! ------------------------------------------------------------------------ April 7, 2005 - 11: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 - 01: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 - 02: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.

Issue status update for http://drupal.org/node/20115 Project: Drupal Version: cvs Component: user.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: nedjo Updated by: nedjo Status: patch 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? 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.

Issue status update for http://drupal.org/node/20115 Project: Drupal Version: cvs Component: user.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: nedjo Updated by: Dries Status: patch 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 Previous comments: ------------------------------------------------------------------------ April 7, 2005 - 07: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 - 17:08 : samo I really like this. Thank you! ------------------------------------------------------------------------ April 7, 2005 - 18: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 - 08: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 - 09: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 - 14: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 - 19: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 9, 2005 - 05: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 - 15: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!

Issue status update for http://drupal.org/node/20115 Project: Drupal Version: cvs -Component: user.module +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-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).) 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.

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).