Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
To duplicate:
- Create a webform and add a number component
- Select a min and max (my settings have integer checked and step=1)
- Set as a select list
- Set the "Thousands separator" to none
- Save the component and view the form
Other thousands separators like period will save and display. "None" as an option will not save and reverts to commas. This makes a birth year selector rather weird.
Comment | File | Size | Author |
---|---|---|---|
#9 | Skærmbillede 2012-07-31 kl. 3.37.39 PM.png | 93.79 KB | alca11 |
#5 | webform_number_empty_separator.patch | 597 bytes | quicksketch |
#4 | webform_thousands_sep-d6-1504786.patch | 608 bytes | ao5357 |
#3 | webform_thousands_sep-d6-1504786.patch | 0 bytes | ao5357 |
Comments
Comment #1
ao5357 CreditAttribution: ao5357 commentedFirst theory: includes/webform.components.inc on line 620:
Would this revert the empty string value and save the field as the default [comma]?
Comment #2
quicksketchI think you've found the problem indeed. To work-around it, perhaps we can simply make the value "none" instead of an empty string.
Comment #3
ao5357 CreditAttribution: ao5357 commentedPatch included. Instead of setting the separator value in number.inc to something other than an empty string, I've added a condition to the above-mentioned webform.components.inc cleanup code. It checks to see if the from component allows an empty string as an #options value before deleting it.
I think this is a decent solution, since number_format defaults to commas if NULL is passed as the fourth parameter. The number component workaround would require _webform_format_number() to rewrite the option value (say, 'none') as an empty string to pass to number_format.
This patch requires testing, as I've only tried it in the limited context of the form I created. If array_key_exists acts like isset and returns false rather than erroring if the passed array doesn't exist, chances are this will work just fine. Otherwise, isset might be better.
I'm not sure if there's an analogous circumstance for empty attribute values (lines 628-635 of webform.components.inc), so I didn't mess with its conditional.
Comment #4
ao5357 CreditAttribution: ao5357 commentedThat was dumb. Real patch this time.
Comment #5
quicksketchThanks @ao5357! I switched it to isset() because I'm more comfortable with its behavior over array_key_exists(). Since it's unlikely that we'd have a NULL value anyway, it should have the same effect as array_key_exists() without the worry about PHP notices.
I've committed this patch to both 3.x branches.
Comment #7
bendev CreditAttribution: bendev commentedsame issue with D7 .. patch works... thanks
Comment #8
bgm CreditAttribution: bgm commentedMarked #1468586: Thousand separator does not save as duplicate.
Comment #9
alca11 CreditAttribution: alca11 commentedI'm a new user to Drupal. I am creating a contact form that needs to have more options, than the one that comes with Drupal core.
Now, one of the fields is "zip code", which obviously shouldn't be formatted with a thousands separator.
I can't figure out how to install a patch. I really think it is extremely hard for a beginner, to correct such a basic thing, as a wrong space in an input field.
Why can't one apply a patch simply by copying its URL the same way that you install a module? You have to be a week and know terminal syntax and what not :S
I could find out how to update the module to the version 3.x version for Drupal 7.
My site tells me it it's this version: 7.x-3.18+14-dev
So when I read "I've committed this patch to both 3.x branches." (#5), I understand it as if those versions have the problem fixed.
However, after updating the plug-in, I still have the same seperator fucking issue. Why does this have to be so hard?
Comment #10
dsrikanth CreditAttribution: dsrikanth commentedEdit:
Turns out the issue is fixed in the Webform but the Form Builder is still carrying the bug.
Quick question:
I see that this patch made it into the module code (7.x) and the UI is behaving as expected. However, the results and the token values still have the Thousands separator. Was that not addressed? (or should that be a new issue?)
Comment #11
michiellucas CreditAttribution: michiellucas commentedI still have this issue with form_builder and webform combined
Comment #12
vensires CreditAttribution: vensires commentedThis issue is still a problem in Webform-7.x-4.17. In webform-7.x-4.x-dev though it is fixed. I suspect that in 7.x-4.18 it will be fixed.