1. Create a new field on the Article node type (I created a Decimal field).
2. Create a new article node.
3. View the node, and hit refresh once or twice.
4. See output like http://img.skitch.com/20090920-c2k67sdtq5g1st7cn46p8ffhh4.jpg
It looks to me like in field_default_view(), $instance['display'][$build_mode]['settings'] is empty but that is what is being put into $element['#settings']. In theme_field_formatter_number(), it is looking for $element['settings'] to contain field settings. Or maybe number.module now supports display-time scale/precision settings separate from the field storage scale/precision settings, which would be fine (maybe you want to display less data than you have), but then something between field_default_view() and theme_field_formatter_number() is confused.
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | number-default-formatter-582754-2.patch | 2.05 KB | bjaspan |
Comments
Comment #1
yched commentedYes, the default formatter has a separate 'scale' setting so that the displayed output can be adjusted independently of the storage precision.
In theme_field_formatter_number(),
$settings = $element['#settings'];refers to the formatter settings: It seems like the code only looks for actual, valid formatter settings in there. There should be code in field_create_instance() and _field_info_prepare_field() (function names from mermory) to ensure all existing settings get at leat populated with their default value to avoid those kind of notices...Comment #2
bjaspan commentedI figured out what is going wrong here.
number.module defines three formatters: default, decimal, and unformatted. default and decimal both use theme_field_formatter_number, via hook_theme_registry_alter(), which is the formatter that supports prefix, suffix, thousands separator, etc. unformatted just outputs the number as a string.
The bug is that number's field types define their default formatter to be number_integer, but there is no formatter named number_integer. Through some mechanism I have not figured out, Field API is figuring out to call theme_field_formatter_number for the non-existent formatter number_integer, but then the formatter does not have the settings that theme_field_formatter_number expects.
The attached patch sets the default formatter for type number_integer to be number_default, and for type number_float and number_decimal to be number_decimal. Both of these formatters (as I said above) end up calling theme_field_formatter_number(), but with correct formatter settings.
I sure would love yched's review of this, though. ;-)
Comment #3
yched commented"Through some mechanism I have not figured out, Field API is figuring out to call theme_field_formatter_number for the non-existent formatter number_integer" : that's because number_theme_registry_alter() 'created' the theme hook for theme_field_formatter_integer, routing it to theme_field_formatter_number(). But the patch is correct, of course. Doh.
Comment #4
dries commentedCommitted to CVS HEAD.
We should probably have tests for this so updating the issue as such.