To duplicate:

  1. Create a webform and add a number component
  2. Select a min and max (my settings have integer checked and step=1)
  3. Set as a select list
  4. Set the "Thousands separator" to none
  5. 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.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

ao5357’s picture

First theory: includes/webform.components.inc on line 620:

  // Remove empty extra values.
  if (isset($form_state['values']['extra'])) {
    foreach ($form_state['values']['extra'] as $key => $value) {
      if ($value  === '') {
        unset($form_state['values']['extra'][$key]);
      }
    }
  }

Would this revert the empty string value and save the field as the default [comma]?

quicksketch’s picture

I think you've found the problem indeed. To work-around it, perhaps we can simply make the value "none" instead of an empty string.

ao5357’s picture

Assigned: Unassigned » ao5357
Status: Active » Needs review
FileSize
0 bytes

Patch 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.

ao5357’s picture

That was dumb. Real patch this time.

quicksketch’s picture

Priority: Normal » Minor
Status: Needs review » Fixed
FileSize
597 bytes

Thanks @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.

Status: Fixed » Closed (fixed)

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

bendev’s picture

same issue with D7 .. patch works... thanks

bgm’s picture

alca11’s picture

I'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?

dsrikanth’s picture

Edit:
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?)

michiellucas’s picture

Issue summary: View changes

I still have this issue with form_builder and webform combined

vensires’s picture

This 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.