For the 'list selection' field types you are supposed to enter the options one per line, the help line below the textarea reads:
'A list of all options. Put each option on a separate line. Example options are "red", "blue", "green", etc.'

When the options are parsed, the coma is also used as a separator.

If some of the options have comas in their text they end up broken.

The fix is trivial, just removed the coma from the regular expression in profile_form_profile, line 396. The problem is that some people may have relied on the coma, and after the fix they will end up with unexpected dropdown options.

Two solutions for that:
1. Though luck, they should have respected the instructions and put options one per line.
2. Provide an update function that grabs these values and splits them at comas.

This should really be fixed, very simple, and I would suggestion option 1 above. Without a fix it is impossible to use comas in option values.

CommentFileSizeAuthor
#1 comma.patch704 bytesmariuss
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

mariuss’s picture

Title: select options separators includes coma » select options separators includes comma
FileSize
704 bytes

Patch against DRUPAL-6 branch, really trivial.

Gábor Hojtsy’s picture

Version: 6.5 » 7.x-dev
Priority: Critical » Normal
Status: Active » Needs review

Indeed, the 'list' type is what allows commas, and the 'selection' type is what expects each value on its own line. The patch seems to make sense but is hardly critical. Putting in the Drupal 7 queue for review.

Status: Needs review » Needs work

The last submitted patch failed testing.

mariuss’s picture

Version: 7.x-dev » 6.8
Priority: Normal » Critical

The patch was sent for Drupal 6. It is not clear against what version was it tested (actually the detailed results are totally useless IMHO, could not get any kind of info from there).

This is a critical issue in Drupal 6 for sure, you cannot use options with commas in the text, that is a bug and there is no workaround. The fix is also trivial.

Why do we have to now wait for another year and another Drupal version for such a simple and obvious fix?

Gábor Hojtsy’s picture

Version: 6.8 » 7.x-dev
Status: Needs work » Needs review

We don't need to wait for another year/release, but bugs are fixed in Drupal 7 and backported to Drupal 6. This ensures that it will not happen that Drupal 6 gets it fixed, but 7 does not. So the latest release is always the best as well. Let's get this simple patch reviewed and committed in Drupal 7 first!

mariuss’s picture

Sorry, I did not know that this is how it works. Thanks for clarifying.

Dries’s picture

Version: 7.x-dev » 6.x-dev

I back-ported this patch to CVS HEAD and committed to CVS HEAD. Thanks mariuss. Setting version to 6.x now for Gabor. :-)

Gábor Hojtsy’s picture

Version: 6.x-dev » 5.x-dev
Status: Needs review » Reviewed & tested by the community

Committed to Drupal 6, moving down to Drupal 5.

drumm’s picture

Status: Reviewed & tested by the community » Fixed

Committed to 5.x.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.