Multiple "Undefined index" notices in modules/field/modules/number/number.module

I cannot reproduce this when I add a content type and an integer field. On what page do the notices occur?

If it helps I got this error in the following situation with :
1. go to Manage Display and change from Default to Unformatted under Format.
2. save
3. change back to default and the error disappearers.

Notice : Undefined index: scale dans number_field_formatter_settings_summary() (ligne 265 dans /var/www/vhosts/myrmecofourmis.com/httpdocs/site/modules/field/modules/number/number.module).
Notice : Undefined index: decimal_separator dans number_field_formatter_settings_summary() (ligne 265 dans /var/www/vhosts/myrmecofourmis.com/httpdocs/site/modules/field/modules/number/number.module).
Notice : Undefined index: thousand_separator dans number_field_formatter_settings_summary() (ligne 265 dans /var/www/vhosts/myrmecofourmis.com/httpdocs/site/modules/field/modules/number/number.module).
Notice : Undefined index: prefix_suffix dans number_field_formatter_settings_summary() (ligne 266 dans /var/www/vhosts/myrmecofourmis.com/httpdocs/site/modules/field/modules/number/number.module).

The 'Unformatted' formatter doesn't have any settings and therefore shouldn't return any 'settings summary'.

The correct fix is to wrap a if ($display['type'] == 'number_decimal' || $display['type'] == 'number_float') { check around the following lines in number_field_formatter_settings_summary() :

  $summary[] = number_format(1234.1234567890, $settings['scale'], $settings['decimal_separator'], $settings['thousand_separator']);
  if ($settings['prefix_suffix']) {
    $summary[] = t('Display with prefix and suffix.');
  }

Additionally, the same if ($display['type'] == ... check already exists in number_field_formatter_settings_form() but it needs to be moved just above the $options = array( line.

I'm not where I can roll a patch right now. Anyone ?

#7: number.module.patch queued for re-testing.

For D7 that helped:

from (line: 264, number.module):

$summary[] = number_format(1234.1234567890, $settings['scale'], $settings['decimal_separator'], $settings['thousand_separator']);

  if ($settings['prefix_suffix']) {
    $summary[] = t('Display with prefix and suffix.');
  }

to:

  if (isset($settings['scale']) && isset($settings['decimal_separator']) && isset($settings['thousand_separator'])) {
    $summary[] = number_format(1234.1234567890, $settings['scale'], $settings['decimal_separator'], $settings['thousand_separator']);
  }
  
  if (isset($settings['prefix_suffix'])) {
    $summary[] = t('Display with prefix and suffix.');
  }

#19 woked perfectly in D7

- I don't favor the introduction of the number_settings_defaults() helper function.
- This function happily mixes field settings ('scale'...) and formatter settings ('thousands separator'), and adds settings that do not make sense ('scale' for integer fields ?)

I think #17 outlines the correct fixes, which are quite simple.

@pillardotsnet : sorry for #23 sounding a bit harsh, I typed it quickly from my phone browser. Thanks for keeping up pounding on this issue.

Actually there's another error in number_field_formatter_settings_[form|summary]() : they reason on formatter being either 'number_decimal' or 'number_float' - and the latter doesn't exist, it should be 'number_integer' instead.
Attached patch is the same as #24, plus this additional fix.

Those fixes are the correct ones for me, and with those applied I haven't been able to reproduce the errors/warnings @linclark mentions in #18 while displaying an integer field in Views - nor do I see where they would come from. So, until @linclark or someone else provides more info on those, I'll stick to that approach.

I cannot RTBC this myself anymore, though :-/

So in your proposed fix, $element['decimal_separator'] and $element['scale'] are only defined for type 'number_decimal':

No, 'decimal_separator' and 'scale' settings are defined for the 'number_integer' formatter too (see number_field_formatter_info()), they just have no UI in the form, so they will be present with their default values. Thus, referencing them will generate no warnings, they exist, just not changeable (at least not in the UI). I reckon this is not exactly intuitive, but this allows the formatter_view() and formatter_summary() code to be the same regardless of the field type (integer, decimal, float).

If 'number_float' doesn't exist, there is certainly a lot of cruft that needs cleaning up.

You're mixing field types and formatters. The 'number_float' field type exists, but there is no formatter named 'number_float'. float fields use the 'number_decimal' formatter.

So yes, the patch is correct. Updated patch just adds a comment in number_field_formatter_info() to make that a little clearer.

The 'formatter settings' UI is not easily testable currently. That's because it is triggered by an image button, and those do not play well with our testing framework.

I guess this could be tested by programmatically creating a integer field and instance with the number_integer formatter, and just displaying the "Manage display" page (the test will pass by just triggering no warnings), but to be honest, I'm not sure a test is worth it.

Getting back at this after a couple weeks away from my coding env.

Thanks for the tests ! Just slightly adjusted those (explicitly test setting the formatter to 'number_integer', so that the test does not depend on it being the default formatter).

@pillarsdotet validated the code, I validate the tests (with the minor adjustment above), so I guess this is RTBC.

I guess so too :)

Committed and pushed to 8.x and 7.x. Thanks!

I am still seeing this error flooding watchdog. Has there been a regression somewhere?