XProfile 1.1 field functions and filters

[johnjamesjacoby]

(5:00:04 PM) jjj: If I can put in a request, it would be awesome if profile fields could define functions that they call, etc...
(5:00:19 PM) jjj: Custom hookes and filters per field and what-not.
(5:00:24 PM) jjj: hooks
^{(5:01:31 PM) jjj: Or at least a drop down of approved hooks and filters, maybe loaded via other plugins into an array.
(5:01:59 PM) apeatling: is there not a filter on each profile field output?
(5:02:55 PM) jjj: Mm not that I remember seeing, not in a way that let each field have a name or type or distinction apart from a normal old textbox or listbox or loaded from a csv.
(5:04:04 PM) apeatling: I'm getting rid of the pre-built field stuff for now
(5:04:07 PM) apeatling: its not good
(5:04:16 PM) jjj: Agreed.
(5:04:21 PM) apeatling: I didn't write it :)
(5:04:24 PM) jjj: :X
(5:04:45 PM) apeatling: if I added a filter to each lik
(5:05:23 PM) apeatling: apply_filters( 'xprofile_field_' . $field->type )
(5:05:27 PM) apeatling: is that what you mean
(5:05:36 PM) jjj: No not exactly...
(5:09:42 PM) jjj: I'm thinking more along the lines of when you are creating the field, that there's like a textbox or a drop down to say, the name of a registered function to know that a textbox is an email address, or if it's a twitter name, or a youtube account link, or if I want to take a check box and run a custom function when the form is submitted, but be able to define that filter/function when I'm building the field, and not through code.
(5:11:23 PM) jjj: Say I activate a plugin, that lets a user enter their twitter name and will import some tweets. Rather than have it be a whole new page in the members area to setup a name and password and then another page for the tweets, why not just make some profile fields that can be text boxes, with a max length of 50, that on submit call bp_filter_twitter_name and bp_filter_twitter_password...
(5:11:42 PM) jjj: Then when someone views my profile, bp_filter_twitter_name will automatically create the link to my twitter account.
(5:14:13 PM) jjj: Or lets make this more native, and say Burt's BPC plugin wants to make a profile field that will filter a specific textarea for comma separated phrases and create tags out of them. Rather than being a whole other tag page that won't show up in their profile area, just create a field, text area, max length 500, hook bpc_xprofile_create_tags to it.
(5:14:21 PM) apeatling: reading..
(5:15:25 PM) jjj: That means his plugin would come with all the functionality that it would normally come with, plus some additional hooks that get added to an array for textarea filtering... Site admin creates the field, and has a list of premade filters he can choose for it to do...
(5:16:49 PM) jjj: That also means you can open this up to allow profile fields to hook into functions on registration... They create gender fields, and on form submission they are automatically joined into a group for buys or girls...
(5:17:06 PM) jjj: Then they have access to only boys and girls forums... And the site admin didn't need to touch any code...
(5:17:47 PM) apeatling: seems like a solid idea
(5:18:20 PM) apeatling: could provide some default functions to run
(5:18:34 PM) apeatling: can you add this to an enhancement ticket so it's not lost?
(5:18:39 PM) jjj: You bet.
(5:18:47 PM) jjj: Copy and paste fine?
(5:19:00 PM) apeatling: yep}

[r-a-y]

re: Andy's comment of getting rid of the prebuilt fields... I actually find them very useful for those of us that use a large amount of fields like Country, State, etc.

But back to the topic at hand, I like the general idea of allowing filters on xprofile fields!

[developmentnow]

I like this idea. We added something similar to let us provide custom display & validation for arbitrary form fields.

One thing we didn't do (which I really like from jj's suggestion) is the idea of providing a list of custom field types of field-related functions that site admins can select from when creating profile fields.

[developmentnow]

Replying to developmentnow:

I like this idea. We added something similar to let us provide custom display & validation for arbitrary form fields.

Er I mean xprofile fields.

[johnjamesjacoby]

Thinking more about this, fields and callbacks should be in plugins and code, both so they are version controlled and to keep strict separation between code and data.

Closing as wontfix.