Checkbox profile fields front end show labels in cp

Question

I have some custom profile fields saved on registration in the front end. They are checkboxes and only submit on front end reg when they are set as an array. eg:

<div class="checkbox">
    <label>
        <input type="hidden" name="fields[phoneOptIn]" value="">

        {% set chbox = craft.fields.getFieldByHandle('phoneOptIn').getFieldType.options %}

        {% for option in chbox %}
            <input type="checkbox" name="fields[phoneOptIn][]" value="{{ option.value }}"  tabindex="29">
            {{ option.label }}
        {% endfor %}
    </label>
</div>

"fields[phoneOptIn][]" only works to save with "[]" in name.

The problem in the CP user display is that when configuring to show the check box fields in the CP, the values of the checkboxes are not shown. What is displayed instead is the labels. eg:

Is this a bug? Really want to see values in backend not labels.

Answer 1

This is the expected behaviour. It makes perfect sense to display the human-friendly checkbox label on an admin screen, rather than the (potentially obtuse) checkbox value.

To confirm that this isn't simply an issue with your form, I did the following:

1. Created a test checkbox field with three options.
2. Added the test checkbox field to the custom user fields.
3. Set the checkbox field to display on the users list page.
4. Edited a user via the control panel, and selected some of the checkbox items.
5. Returned to the users list page to view the results.

As expected, the users list page displayed the labels of the selected items.

The only difference appears to be that in my installation the selected items are displayed in a single column, as a comma-delimited list, whereas in your example each checkbox item receives its own column.

Here's a screenshot:

It's also worth mentioning that you are correct in stating that the checkbox option fields need to include the [] in the name. That's exactly how the admin forms work too.

Answer 2

Stephen's answer is correct in that it's the default behavior.

You could also write a simple plugin that supplied it's own Checkbox field type that extended Craft's default implementation. It could override the getTableAttributeHtml() method to return the values instead of the labels for element index pages.