Custom Profile Field names

[psylenced]

Is there any way of avoiding the sequential naming of custom profile fields?

I need to use them in my application, and they work perfectly for drop downs, radio, text and full text.

Only issue is the sequential naming.. eg field5, field6, field7, field8, etc. They will easily conflict with other applications and never will be the same name.

Is there a way of naming these better?

eg. field_plugin_abc_firstname, field_plugin_abc_lastname, etc..

[Marco van Herwaarden]

No, they will always be numbered like this.

[Opserty]

Why not create some vBulletin Options that will enable you to set them? So you'd have

PHP Code:

$user[$vbulletin->options['firstfield']] 


. Might be a little messy but it is an easy solution.

[psylenced]

Just had a look through the code and they are pretty much hard coded.

eg.. 'field' + profilefieldid + '_blah';

I think it'd help a lot of mod devs if they were able to name these whatever they like (keeping the same naming system as a default) so there wouldnt be any conflicts and can add as many as they like.

[Reeve of shinra]

In the product, add a SQL query to add [name-of-field] to the userfield table. Then you can use $post[name-of-field] or $bbuserinfo[name-of-field] wherever vb calls profile fields.

[GameWizard]

Pardon my ignorance on this topic, but in case you haven't already tried. Try to find mods that already offer similar functionality and see how they worked around this problem, assuming a solution is even there.

[psylenced]

The issue is for my mod i need 20-30 profile fields, all diff types (text, full text, radio and drop down), all user-editable. I can approach it one of 3 main ways.

1 - Leave it using numbered profile fields which requires a lot of messing around and makes it possibly conflict with existing mods and hard to configure/install (if i decide to release it for other people).

2 - Edit the profile system to allow named fields. This affects a few different places and will require updating the core code every vb update which will probably more work than the former.

3 - Create my own database table/fields. This has no conflicts, except i'm duplicating all the existing profile field code which is exactly suited to what i need (groups, types, values, etc).

There isn't really an elegant way. Best case scenario would be for vb to update their code and support named fields officially. This would be perfect as mod authors can then use these fields very easily throughout their plugins and have no conflicts at all. Cant see a negative for that one.

Not sure of any other ways as i've only been developing for vb for a little over a week lol. Still trying to get my head around the code and way it goes about things after deciding to move to this platform.

[Opserty]

If you are using 20-30 profile fields either extend the user table or create your own table which would include the fields & a userid reference.

I think the Custom profile fields are only really intended enable people with little understanding of PHP & MySQL to be able to create extra information fields without messing up their entire board.

However if you are going to add 20+ fields you will be better off creating another table (or extending the user one) and then using a JOIN to fetch the data. (I think there is a hook in fetch_userinfo, but don't quote me on it)

[psylenced]

I managed to get passed my specific issue (not the general question though), by going about it a different way.

My main problem was that i had profile field categories on my page, but they werent ajax editable (except in about me), but i wanted them separate.

I managed to change the code to allow this, but the issue was that there werent any hooks that would allow me to change this without modifying vb code. I needed to change the prepare_output function in ProfileFields.

I solved this by adding the following code to the member_build_blocks_start hook:

PHP Code:

class vb_ProfileBlock_ProfileFields2 extends vB_ProfileBlock_ProfileFields
{
    function prepare_output($id = '', $options = array()) 
   {
         // new code
   }
} 


Then re-running the profile block code to inherit the new class instead:

PHP Code:

foreach ($profileblock->locations AS $profilecategoryid => $location)
{
    if ($location)
    {
        $blocklist["profile_cat$profilecategoryid"] = array(
            'class'         => 'ProfileFields2', 


So my main problem was solved. Starting to get the hang of this too which is good, as i'm generally not a php coder.