When I change the setting in a Profile Builder form to Multiselect, it enters 

a:0:{}

into the options field.  I don't know what that means and have just used the convention that I saw elsewhere, ie

name=Name
licensenumber=License Number

Is this correct?  Do I need to be careful that I do not use the same lowercase/left side name in 2 forms?  Can I use an _ as in

license_number=License Number

Is there anything else I should know about this? 

Update:  I tried the above and it did not work.  The fields did show up in the form but the results do not save and do not output when I view the profile (although the other form items do).

and also, I changed the name of the Description box in the Profile Member Basic profile form to Profile Summary and now the results do not stay when saved, although they did before I and that change (and some others).  If you need to login I will email you a username password.

It seems like something's funny in your installation — I will log in and check it out.

Here's how it generally works.

When you enter values into a Select or Multiselect field for the first time, you just in type the values you want there (e.g. "Name, Address"). However, you can also type in the pairs in ready — it will be recognized as such. (I have just done both successfully on WWB.)

When you save, they will be converted to key/value pairs like you see in the existing fields. You can use underscores and spaces if you want, but preferred practice (for me anyway) is to keep keys in lower case only as a matter of distinguishing the two.

I have now logged in, but couldn't see anything out of the ordinary. Which form did you try to edit?

I have tested this at your site by creating a new Multiselect field in the Feedback form. Everything worked as expected, as in the screenshots above.

When does the a:0:{} appear — when you first create a new field, or when you save it? I gather it happens when you first click to create a new field into your profile.

This might be related with a browser quirk (at least based on this odd report — not the easiest keyword to search for!) — there's nothing in the code that would explain this Does this happen in Safari@Mac? Has anyone else seen this happen?

---

Edit: Oops — I was in the Form Builder, you were in the Profile Builder — they use the same basic codebase, and the same rules apply. I have now done the same in Profile Builder under Member Basic Profile — worked as expected.

---

N.B. There's a "Level" dropdown you see when click "New" for a new field, that's absent in the saved fields you see. Field control by userlevel is a feature that hasn't been activated yet, so never mind it — you can comment it out in admin_skin_site.php under $skin['admin']['form_unit_blank'] if you wish, like it's commented out in the template for saved fields.

There was also an earlier question on what entries like LIST:noyes_01 mean in a Select or Multiselect box — seen in place of the usual option lists shown above.

LIST: is connected with $list associative arrays in the language files. You can use it to invoke one of the key/value lists there. For example, LIST:us_state_list would pick all US states from lang_countries.php / $list['us_state_list'].

The "LIST:noyes_01" is simply a shorthand for typing "No and Yes" with values 0 and 1 respectively, also taken from a list. (Yes I am lazy!)

If you have longer option sets, it may be easier to add them into a list in one of your language files, and just include a reference to the list. You'd then make a list like this:

$list['my_options'] = array('eliphants'=>'Eliphants', 'monkies'=>'Big Fat Monkies', 'tigers' => 'Dangerous Tigers');

And you could call it into a select or multiselect field by writing in simply LIST:my_options. This is especially handy if you use the same lists in several profiles/forms, and want to be able to edit them all at once.

Thanks,

The a:0:{} shows up in the Options box when I first select the Multiselect option.  This happened when I did it in Safari.  I have not tested it in other browsers but Safari has not done wierd stuff to date.

When I did it, I typed in, for example:

test=Test

test 2=Test 2

and that gave me the result I shared, that is, that it did show up as an option for a user to select from, the results did not display when viewing that person's profile, although all other fields display.

I did re-do it with the options as:

Test

Test 2

and that worked.

But - the results that display in the user's profile are lower case, inlcuding the sample you did on my site.  For example, using the fields you entered, if one selects One Thing and Two Things, they display in the actual profile for that user as one thing, two things.  Can you tell me how to fix this?

I will poke around this with Safari to see what's up — it looks like blank serialized data there, need to see if I can trigger it to appear somehow. If it appears before the form is saved, I'm pretty sure it's a harmless quirk in either case, and shouldn't affect your end result.

Yes indeed, if you select just one option, it displays the expected value, but when you select multiple options, it displays the values. Tagged as confirmed bug.

To fix, go to /modules/members/members_class.php, and find (#625):

else $data['fdata_content'] = str_replace("|", ", ", $data['fdata_content']);

Replace with the following:

                else
                {
                    $multi_opt = explode("|", $data['fdata_content']);
                    $opt_buffer = array();
                    foreach ($multi_opt as $val)
                        $opt_buffer[] = $options[$val];
                   
                    $data['fdata_content'] = implode(", ", $opt_buffer);
                }

This will sort it out for you. Fix entered into next build. Todo: Do the same for Form Builder and test.

Thanks.  That fixed the lower to upper case.  Perrrrfect.

Excellent — so we're all clear with the profiles then. In case you want to fix this for the form builder, it's the same deal under /core/class_custom_forms.php / function get_custom_form().

Thank you Markus.

I would like to fix it in the form builder but could not nail down exactly what to swap out with what in the /class_custom_forms.php file.  Would you be willing to provide more detail?

Thanks,

Sure thing. It's actually a somewhat different fix for the same issue in a different context, now that I look into the code, because it's parsed for e-mail.

In /core/class_custom_forms.php, in function validate_form_details(), find the following at line #45 :

if (is_array($_POST[$d['field_ident']])) $_POST[$d['field_ident']] = implode(", ", $_POST[$d['field_ident']]);

Replace with the following:

if (is_array($_POST[$d['field_ident']]))
{
    $f_options = unserialize($d['field_options']);
    $buffer = array();
   
    foreach ($_POST[$d['field_ident']] as $key=>$val)
        $buffer[] = $f_options[$val];

    $_POST[$d['field_ident']] = implode(", ", $buffer);
}

This will have the options selected in a multi-select field match the actual names, not the keys, just like with custom profiles.