Ticket #784 (closed enhancement: wontfix)
function bb_profile_data should have an action hook
| Reported by: |
|
Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | 1.1 |
| Component: | Back-end | Version: | |
| Severity: | normal | Keywords: | |
| Cc: |
Description
There are several plugins that want to add info on the profile page. To do this, they require the user to edit the profile template.
It would be nice if users didn't have to edit the profile template and plugin authors could just add_action 'do_bb_profile_data' or something like that.
Technically the get_profile_info_keys can be used but some objects like avatars can't be done that way.
Change History
Is the 'extra_profile_info' action of no use? Would you prefer something within the same table as the other form elements?
To give an example of the current problem, as I see it:
- I want to add a user setting, that display whatever on the forum when that user is logged in.
- $user->whatever is a really convenient place to store that data. Remember this is a user setting, not a forum-wide setting.
- I can add "whatever" via add_filter('get_profile_info_keys', 'function_that_adds_whatever').
- Whatever will then appear on the profile and profile edit screen, in with all the other data.
- Unfortunately, I need to be able to: (a) assign it as a checkbox, not a text field, (b) add a text note to explain to the user what the whatever tickbox does, (c) assign it to a separate fieldset - perhaps called "Settings", (d) stop the data displaying on the public profile view.
- The current user data structure is not reliable enough (explained below) to hold all that extra detail. So I create my own lookup data structure.
- Now since bb_profile_data is in the core, and more-or-less needs to be re-written to support the extra data structure associated with whatever, I cannot use it.
- I write my own custom functions to re-create the profile screens, which are called from my template.
- This is unhealthy, since changes to core profile code will get overlooked.
The extra_profile_info hooks seems to simply be a place to drop a heap of entirely new code, that doesn't replace anything that would otherwise appear in the profile. Further bb_profile_data-type action hooks would help, but would not entirely solve the inflexibility of the current "you're only really supposed to enter a name and email" user information.
I need to be able to specify the data type (tickboxes, textareas, selects and radios with options), group sets of profile entries into blocks (including groups of groups), alter the way data is displayed on the public profile (including display to owner-member, all-members, public, hide), help/explanation, class for formatting, and probably a few other things that I don't even know I need yet (so an inherently flexible method).
Perhaps this needs to be re-thought: For example, we're seeing slow feature-creep in the existing user array, such as the addition of optional vcard names... but the data structure is horrible: The vcards are are referred to as label[2]. So I can hack my own data onto the end of the array, but a reference to label[3] is clearly setting myself up for disaster at a later date.
- Milestone changed from 1.0 to 1.5
I agree that this area needs some work, but it will have to wail for now.
comment:9
johnjamesjacoby — 5 months ago
- Status changed from new to closed
- Resolution set to wontfix
- Milestone changed from Future Release to 1.1
No patch and no traction since 2 years ago. Closing as won't fix.