In the text for the select profile field it says to put options on a new line, but commers split the options as well.
Either the text should be changed or commers shouldn't make a new option (at the moment, commers can't be in an option).
This patch does the latter.
| Comment | File | Size | Author |
|---|---|---|---|
| #9 | profile-split-field-90221-9.patch | 738 bytes | cburschka |
| profile.patch_1.txt | 494 bytes | sym |
Comments
Comment #1
edmund.kwok commentedhttp://drupal.org/node/89459 is an example of why this would be a problem. That issue is marked duplicate in favor of patch submitted in this issue. Please generate patch from Drupal root, thanks.
Comment #2
edmund.kwok commentedImproving the title.
Comment #3
drummWe should also update the database so any existing commas become newlines. This will keep the selection options consistent.
Comment #4
edmund.kwok commented@drumm
I think the patch changes it so that comma won't equal a new option. So there is no need for exiting commas to be new lines.
Comment #5
skippy13 commentedThe change to the split() command works for Drupal 5 as well; but the location is on line 672.
Comment #6
drummThe current state of the user's site needs to be preserved. If we remove commas being an option splitter, then any option lists containing commas are effectively changed without asking or notifying the user.
Comment #7
foo commentedI'm in favor of separating on newlines only - commas are often useful when making descriptive, usable form options. Several times I've wanted to use commas, and had to get creative with other, less readable separators.
Comment #8
keenan83 commentedHas this been solved yet?
Comment #9
cburschkaHasn't. The patch still applies, but with a huge offset; here's a re-roll.
Comment #10
drummMy comments from #6 are still valid. Existing commas must be converted to newlines to avoid changing the user's site.
And I would like to see this changed in the development version first and then backported as necessary. It will get more reviewers in the development version anyway.
Comment #11
cburschkaIf we change this in multiple branches, where would the user data be changed? profile_update_1?
Comment #12
Jaza commentedHopefully profile.module will be removed in D8 in favour of Field API. So we don't need this patch that changes the storage behaviour of profile.module's internal mechanisms.