Skip to:

Opened 8 years ago

Last modified 8 years ago

#7287 new defect (bug)

xProfile multi select box output: Include option IDs

Reported by: henrywright's profile henry.wright Owned by:
Milestone: Awaiting Contributions Priority: normal
Severity: normal Version:
Component: Extended Profile Keywords:


Hi guys,

Here's a snippet of front-end output when using the multi select box xProfile field type:

<select id="field_436[]" name="field_436[]" multiple="multiple">
    <option value="Afrikaans">Afrikaans</option>
    <option value="Albanian">Albanian</option>
    <option value="Arabic">Arabic</option>
    <option value="Azerbaijani">Azerbaijani</option>
    // More

Is there any chance we can output option IDs too? Something like:

<select id="field_436[]" name="field_436[]" multiple="multiple">
    <option value="Afrikaans" id="6583">Afrikaans</option>
    <option value="Albanian" id="6584">Albanian</option>
    <option value="Arabic" id="6585">Arabic</option>
    <option value="Azerbaijani" id="6586">Azerbaijani</option>
    // More

Note checkbox output already has option IDs.

Change History (9)

#1 @slaFFik
8 years ago

I think yes, and in general all profile field options should have some sort of ID in DOM.
That includes select, select_multiple, checkbox, radio etc

Last edited 8 years ago by slaFFik (previous) (diff)

#2 @slaFFik
8 years ago

  • Milestone changed from Awaiting Review to Future Release

#3 @johnjamesjacoby
8 years ago

Check the commit history to make sure this exact thing wasn't already removed.

There used to be a problem with duplicate field IDs on the page. If we put them back in, they should probably be prefixed – numbers alone don't help target them any differently than pages or posts.

Last edited 8 years ago by johnjamesjacoby (previous) (diff)

#4 @slaFFik
8 years ago

Sure, I checked checkboxes before answering. They are prefixed like field_8_2. And just numbers as ids won't work in some situations (don't remember exactly why), so they definitely need to be prefixed. And as they are stored in one table, we can easily reuse the same naming pattern.

Last edited 8 years ago by slaFFik (previous) (diff)

#5 @hnla
8 years ago

Remember an ID token cannot begin with a numeral!

Why are thse required/useful?

Consider using classes in preference to IDs they can begin with a numeral.

Is this a hook, for JS perhaps?
Consider using data-*="" attributes instead/as well as?

#6 @slaFFik
8 years ago

I believe it's useful for js, when conditionally hiding some options based on other fields options or data. Data attributes are slower than selecting by Id. And it's also semantics - data attr are for extra none identifier values. While ids are self explanatory - unique. Anyway, we already have that for checkboxes, changing there is not good for BC. So I think we just need to unify everything.

Last edited 8 years ago by slaFFik (previous) (diff)

#7 @henry.wright
8 years ago


You're right about needing it for JavaScript.


Conditional profile fields is exactly my use case.

With reference to the most appropriate attribute to use, so far we've suggested data-*, class and id.

There's also the issue of prefixing.

If I'm not mistaken, field_6815_1 is the format currently used for the checkbox field type and id is the attribute used. If merely to be consistent, shall we keep it like that?

#8 @hnla
8 years ago

whatever decided can we please ensure we DON'T user Caps or underscores in tokens it's wrong and a shame they have occurred historically.

I would suggest perhaps id="field-option-6815" or field-436-option-6815 ?

data attr in this context wasn't an appropriate suggestion we're not passing data over

#9 @henry.wright
8 years ago

For the record radio buttons use id="option_6815".

Last edited 8 years ago by henry.wright (previous) (diff)
Note: See TracTickets for help on using tickets.