profile module with mutiple selection field type
joehudson - August 29, 2005 - 01:23
| Project: | Drupal |
| Version: | 7.x-dev |
| Component: | profile.module |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | won't fix |
Description
Hi,
I found a need to add a multiple selection menu to user profiles (so they can select different skills they can contribute to projects or events). However this way not possible so I added a new field type 'mutliselect' to the profile.module. I've tested it and it does the job fine for me. You create it just like you would a list selection field but users can select multiple values from the list!
help yourselves to the patch.
ta,
Joe
| Attachment | Size | Status | Test result | Operations |
|---|---|---|---|---|
| profile_3.module | 24.4 KB | Ignored | None | None |
#1
That's not a patch. Please provide a proper patch for HEAD.
#2
I think you are asking for the same thing I did here http://drupal.org/node/28089.
#3
So is there a patch for this anywhere, or is it just the revised module as listed in the top post?
I'd like to try a patch.
#4
Here is a patch on cvs that adds multiselect to the profile field choices.
Selections are saved in a serialized form (as opposed to comma-delimited as per the original submission).
#5
Can we avoid serialized data? Figuring out everyone who made a certain selection isn't fast or fun with string parsing from serialized data in SQL.
#6
Well, the previous version had comma separation rather than serialization. I changed it because I couldn't be sure I wouldn't have commas. What is the preferred method?
#7
Add a new table if necessary. If there is older data which is being changed to serialized, that would need a database update to convert.
#8
Nice patch! thanks.
But found strange error: word 'Array' displayed instead items in profile.
Corrected after some changes in profile_view_field function:
case 'multiselect':$values = split("[,\n\r]", $value);
Changed to
case 'multiselect':$values = $value;
One more thing. Remove multifield in profile browser is not correct, I think. I made exeption therefore. In
function profile_browse code
$result = db_query('SELECT name, title, type, weight FROM {profile_fields} WHERE fid != %d AND visibility = %d ORDER BY weight', $field->fid, PROFILE_PUBLIC_LISTINGS);changed to
$result = db_query('SELECT name, title, type, weight FROM {profile_fields} WHERE fid != %d AND visibility = %d ORDER BY weight', $field->type=='multiselect' ? 99 : $field->fid, PROFILE_PUBLIC_LISTINGS);#9
Used patch submited by sime on May 15, 2006 - 09:50
#10
@drumm
So the comma separated is not ideal either. OK, I will look at the extra table idea. I would also like to change the date type so that it is stored as a stamp, but that would require extra care for upgrades methinks. Maybe there are also potential issues with date range of a unix timestamp...
@ignas
Are you in a position to create a new patch so that I can modify drumm's suggestion on top? No dramas if not.
#11
ABOUT THE SERIALIZED ISSUE:
I don't understand why people think it's more difficult to deal with PHP serialized data, especially in SQL; if anything it's actually easier to avoid false positives and issues with delimiters being used in the fields.
- You can do string searches directly on the serialized data or serialize your search term;
- As long as your data is short, the serialize is very lightweight;
- you could even do funky things like search for all 7 letter string starting with 'sh', even if the data is a serialized array or object.
ADDING NEW TABLES IS A BIT MUCH:
I disagree that adding a new table is required for a particular case of a particular field type of a particular module. I know the weight isn't much for a small table but it clouds the tablespace.
Not to push my own **** too much but I did a serialized solution, that includes controls for choosing multiple selects or checkboxes (radios too) and adds vocabulary/taxonomy based fields (see include.)
The code is about as clean as the original but required too many changes for a simple patch. Man would I ever like to rewrite this module to abstract the field stuff into more modular code (can you imagine how much cleaner it would be.)
#12
There are very few situations where a multi-select list is needed. Usually this choice should be replaced with check boxes Having a user select his skills in a form should be handled with check boxes, using a multi-select is a bad idea IMO.
http://alistapart.com/articles/sensibleforms
http://www.siteexperts.com/tips/html/ts16/page1.asp
#13
Feature request, moving to cvs.
#14
I absolutely need multiselect in my profiles, and for a very legitimate reason: users are supposed to select the languages they speak, the music styles they like, the interests they have from a pre-defined list (to keep it translateable) and I'm not going to create hundreds upon hundreds of checkboxes for that. So my heartfelt thanks to those who have worked on a solution here!
One more issue: with the patch I applied, i18n_profile can't translate the items from a multiselect selectbox anymore. I need to retain that functionality. Is anybody up to patching i18n_profile for this functionality? I can offer a small compensation, contact me.
#15
Yes, a multi select field in profiles would be useful. I am using Drupal 6.x and would like to be able to use such a field on a site. Any suggestions of how to do this would be appreciated. Thanks,
Izzy
#16
Straight port of #4, with the fix in #8. This applies cleanly to Drupal 6.3.
Problems:
Doesn't allow browsing by valuehttp://lug.wsu.edu/~ben/drupal_multiselect_profile_D6.patch
#17
Sorry where/How I add the patch
#18
This will no longer be relevant with fields in core integrated with profiles. And since feature requests are never backported, I'm closing this issue as won't fix.