Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.The provided patch makes it possible to optionally define keys to the entries in the "list selection" field options. The key and the displayed value must be separated by double pipes (||), like "BR||Brazil" or "UK||United Kingdom". The keys are stored in the database, while the display values are visible in the select list.
It doesn't break the current behavior of the lists, where you can define the options without keys, like "red", "blue", "green", etc.
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | profile_27.patch | 1.54 KB | FredCK |
| profile_26.patch | 1.55 KB | FredCK |
Comments
Comment #1
FredCK commentedSorry... here is the patch again, created from the Drupal root directory instead, as specified in the how-to documentation (http://drupal.org/patch). Sorry, but I'm still entering in the Drupal world.
Comment #2
gerhard killesreiter commentednew features go into the cvs version.
Comment #3
webchickInteresting idea. The double-pipe thing is a bit awkward, but it looks like it doesn't require any database changes.
However, it doesn't seem to work, or at least not the way I'd expect. I created a field called "Gender" and put:
F||Female
M||Male
While under user/1/edit/foo, the list selection shows Female and Male as expected; however, on my user/1 profile page, it shows "F" which is weird.
It also seems like it'd be cleaner if the backend was normalized, but I'm not sure if that's even possible with profile module. :\
Comment #4
birdmanx35 commentedFeature requests go to 7.x-dev.
Comment #5
johnhanley commentedI applied this small patch to my local dev version of profile.module and it suits my needs nicely. My user profile only consists of a few fields. I needed key/label pair support for "list selection" fields without resorting to the bloat of userprofile & CCK. I opted to use a single pipe delimiter though. I'm not a proponent of modifying the core, but sometimes it's unavoidable for a very specific need that's not possible by any other means (i.e. hooks, theme, etc.) This feature seems very fundamental to me and should have been included in profile.module from the beginning.
As for webchick's comment, this is the expected behavior as the key value is stored in the profile_values table.
Comment #6
Jaza commentedNo new features for profile.module - let's get rid of profile.module!