Closed (fixed)
Project:
Drupal core
Version:
8.0.x-dev
Component:
profile.module
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
19 Oct 2006 at 23:19 UTC
Updated:
29 Jul 2014 at 17:33 UTC
Jump to comment: Most recent file
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.